Processing More Jobs With ReportCaster Workload Distribution By Gerry Snyder

Enterprise applications frequently generate large volumes of reports and have large distribution requirements. In WebFOCUS 7.7, to increase the throughput of scheduled jobs, ReportCaster introduced a feature called Workload Distribution. This feature provides the ability to add Distribution Servers to an application and therefore increase the number of jobs that can be simultaneously processed.

When Workload Distribution is enabled, one Distribution Server is designated as the primary and functions as the manager. One or more additional Distribution Servers are designated as workers. The manager polls the ReportCaster repository at the configured reader interval and retrieves jobs scheduled to execute at a particular time. The manager also receives requests for on-demand jobs. The manager then dispatches the jobs to the configured workers. The workers execute the jobs, distribute the output and update the ReportCaster logs with the results of the execution.

Workload Distribution works in conjunction with the Failover feature. The designated failover server is a backup for the primary and becomes the manager in the event that the primary becomes unavailable.

The process of setting up Workload Distribution is documented in Chapter 6 of the WebFOCUS and ReportCaster Installation and Configuration manuals for Windows and Unix.

The steps involved in setting up Workload Distribution are as follows:

1. Install and configure WebFOCUS and ReportCaster with one Distribution Server and verify your installation. This is the Primary Distribution Server. When this is complete, open the ReportCaster configuration tool.

2. Configure ReportCaster with the list of host names and corresponding port numbers that you will be using for the worker Distribution Servers and, optionally, the failover Distribution Server.

3. Install a ReportCaster Distribution Server on each of the host machines in your list of failover and worker servers.

4. Copy the ReportCaster configuration file (dserver.xmls) from the configuration directory of the primary Distribution Server (ibi\WebFOCUS77\ReportCaster\cfg on Windows) to the configuration directory of each of the worker servers and the configuration directory of the failover server if you are configuring failover.

5. Start the primary Distribution Server, the failover Distribution Server and each of the worker Distribution Servers.

Screen 1 shows the ReportCaster configuration tool from an installation that has both failover and Workload Distribution configured.

Screen 1

• The Primary Distribution server is installed on HOST1 and is listening on port 8200.

• The Failover Distribution server is installed on HOST2 and is listening on port 8201.

• There are two worker Distribution Servers installed on HOST3 and HOST4 and listening on ports 8202 and 8203, respectively.

Screen 2 shows the Server Status page from the ReportCaster Administration interface after all servers have been started.

Screen 2

Each configured server is listed along with the operating mode, the number of scheduled jobs and on-demand jobs that are running and queued, and the status of the services operating on each server.

Screen 3 shows some of the Server and Job Status pages of the ReportCaster Administration interface when scheduled jobs have been retrieved from the repository and on-demand jobs have been submitted. For these examples the Max Threads setting has been lowered to two (as shown above in the ReportCaster configuration tool). The Max Threads setting is the number of simultaneous running jobs. It has been set to two for demonstration purposes so that even with some jobs, it will remain in the queue with a small number of jobs.

First, two jobs are scheduled to execute at the same time. The manager retrieves them from the ReportCaster repository and dispatches the jobs to two workers. The following screens show the Server Status page after the two scheduled jobs have been dispatched

Screen 3

• The Primary Server indicates that two scheduled jobs are running.

• One of the two scheduled jobs has been dispatched to the server Worker 1.

• The other scheduled job has been dispatched to the server Worker 2.

Screen 4 is the Job Status page showing the two scheduled jobs running. Each job is shown along with the status of the job and the server it is located on.

Screen 4

Next, two on-demand jobs are submitted. The manager receives the two on-demand requests and dispatches the jobs to the two workers. Screen 5 is the Server Status page after the two on-demand jobs are dispatched. The scheduled jobs from the previous example are still running.

Screen 5

• The Primary Server now indicates that two on-demand jobs are running along with the two scheduled jobs that are still running.

• One of the two on-demand jobs has been dispatched to the server Worker 1.

• The other on-demand job has been dispatched to the server Worker 2.

Screen 6 is the Job Status page showing the two on demand jobs running and the two scheduled jobs that are still running.

Screen 6

Subsequently, two additional jobs have been scheduled to execute at the same time. The manager retrieves the two jobs from the ReportCaster repository and dispatches the jobs to

the two workers. Screen 7 is the Server Status page after the two new scheduled jobs have been dispatched. The scheduled and on-demand jobs from the previous example are still running.

Screen 7

• The primary server now indicates four scheduled jobs are running and two on-demand jobs are running. Because the jobs have been dispatched, the primary considers the jobs to be running.

• One of the two scheduled jobs has been dispatched to the server Worker 1. Because Max Threads is set to two, this job remains in the queue of the worker.

• The other scheduled job has been dispatched to Worker 2. Because Max Threads is set to two, this job remains in the queue of the worker.

Screen 8 shows the Job Status page showing the two scheduled jobs that are still running, the two on-demand jobs that are still running and the two new scheduled jobs now in the queue.

Screen 8

Finally, two more on-demand jobs are submitted. The manager receives the two on-demand requests and dispatches the jobs to the two workers. Screen 9 shows the Server Status page after the two on-demand jobs are dispatched. The scheduled and on-demand jobs from the previous example are still running and in the queue.

Screen 9

• The Primary Server now indicates that four scheduled jobs are running and four on-demand jobs are running. Because the Primary has dispatched the jobs they are considered to be running.

• One of the two new on-demand jobs has been dispatched to the server Worker 1. Because Max Threads is set to two, this job remains in the queue of the worker.

• The other new on-demand job has been dispatched to the server Worker 2. Because Max Threads is set to two, this job remains in the queue of the worker.

Screen 10 is the Job Status page showing the two scheduled jobs that are still running, the two on-demand jobs that are still running, the two scheduled jobs that are still in the queue and the two new on-demand jobs that are now in the queue.

Screen 10

With Workload Distribution enabled, applications can achieve scalability by simply adding new Distribution servers as needed. The manager maintains the ReportCaster configuration by pushing the latest configuration settings to the other servers when the system is restarted.

With Recovery set to ON, scheduled jobs running on one worker are resubmitted to another worker in the event the first worker stops before the running jobs are completed. The Workload Distribution feature safely eliminates the bottlenecks that can occur when applications experience periods of peak demand.

Slicers: A New WebFOCUS Feature By Josette Dumont-Smith

In WebFOCUS 7.7.02, InfoAssist has a new feature called Slicers that replaces WebFOCUS OLAP and enhances InfoAssist as well as its component InfoMini.

Users access the feature through a tab that appears between the Data and Layout tabs, which has three groups to define a slicer: Options, Record Limit and a Slicer Group (Screen 1).

Screen 1

The Options group allows you to create new groups, clear slicers and update a preview. A new group that is three slicers wide can be created from the Options group or by right-clicking the menu option from a field in the field list area. To delete an unwanted slicer, use the “clear slicers” option.

An “update preview” can be performed during creation, or set to occur automatically. There is a Record Limit group that has a setting for preview and runtime. In preview, you can set all records to be displayed during design time, or 1 through 10,000. The default is 500. In runtime, you can set records for retrieval as all or up through 50,000 records. The default is all.

A slicer can be created when a new report, chart or document is created. Create a slicer by dragging a field from the field list to the ribbon or by right-clicking on a field from the field list. You also have the ability to add a slicer to an existing group or create a new group. When a slicer is created, it has a name label and field type.

A slicer created with an alphanumeric field type has two choices of operation: equal to and not equal to.

A slicer created with a decimal field type has the following options: equal to, not equal to, in range, not in range, greater than, less than, greater than or equal and less than or equal.

Slicers may be edited via a dialog launched by clicking this icon: It appears at the bottom of every slicer group. The active section of the dialog is set by which slicer cluster was used. There are general properties for the Edit Slicers dialog that currently has a title bar with the following options to control the window: maximize/minimize and close, and at the bottom you have OK, cancel and apply.

There is also a content area made up of two sections. The left-side section lists all slicer groups on the ribbon and the section on the right has group-specific options as shown on Screen 2.

Screen 2

The General label corresponds to the Options group displayed on the ribbon and manages that group. It has the following controls: Show Options and Auto Update Preview. The function of the Auto Update Preview is that when checked, the preview is automatically updated when a slicer value is chosen.

For the Group Order label, clicking a row selects that whole row. Items can be arranged using the following control buttons:

• Move Up, which is disabled when the first row is selected.

• Move Down, which is disabled when the last row is selected.

• Delete, which removes from the list whichever item or group is highlighted.

There is also a Record Limit group that, when chosen, can be turned off in its entirety as well as set values in the following dialog on Screen 3.

Screen 3

The default is checked with the Show Record Limit group label. When unchecked, the whole cluster does not appear on the ribbon and the next two checkboxes are disabled. The Preview label has a dropdown list of values. This corresponds to the same Record Limit on the Home Tab in the Design group.

Stay tuned for more information about this topic in future editions of the WebFOCUS Newsletter.

FOCUS Functions Now in the Synonym By Noreen Redden

Every application has unique needs. Hopefully FOCUS or WebFOCUS meet most of them, though some gaps can happen. Some of those needs are resolved by functions such as EDIT, TRIM and FTOA, but sometimes there is a need that FOCUS does not completely address.

An application may require specific functions, perhaps because of business rules or simply as a result of the nature of what is required. Certainly, since the very early days, customers have had the option of writing their own functions in a 3GL language, such as COBOL or C, and referring to that compiled function. However, the coding and debugging of these functions requires specialized knowledge of that language.

FOCUS functions and functions built using the FOCUS language have been part of FOCUS and WEBFOCUS for many years. However, to use them in a request, the FOCEXEC containing the DEFINE FUNCTION code first must have been executed before a DEFINE utilizing it could be executed. Certainly, maintaining the DEFINE FUNCTION code in a single procedure means that it can be used against any file and any field, as well as in DEFINEs, COMPUTEs, WHERE and –SET commands. If a change to the logic is required, it need only be changed in one place and affect all uses of that function.

However, until 7.7, this also required that the actual definition of the function be executed prior to its use, generally in a PROFILE of some type. This might be a user profile, an application profile, or EDASPROF, FOCPROF, etc. Customers identified a need: how to specify a DEFINE or COMPUTE in the Master File Description that uses a function, and execute the DEFINE FUNCTION first if needed.

So, we introduced a new feature in 7.7 – dynamically issued DEFINE FUNCTIONs.

To see how this works, I have a fairly simple file – so simple it is actually a sequential file – that contains four pertinent fields: Order Date and Time and Ship Date and Time.

FILENAME=MYORDERS, SUFFIX=FIX , $

SEGMENT=MYORDERS, SEGTYPE=S1, $

FIELDNAME=ORDER_NO, ALIAS=E01, USAGE=I9L, ACTUAL=A09, $

FIELDNAME=ORDER_DATE, ALIAS=E02, USAGE=YMD, ACTUAL=A06, $

FIELDNAME=ORDER_TIME, ALIAS=E03, USAGE=I6, ACTUAL=A06, $

FIELDNAME=SHIP_DATE, ALIAS=E04, USAGE=YMD, ACTUAL=A06, $

FIELDNAME=SHIP_TIME, ALIAS=E05, USAGE=I6, ACTUAL=A06, $

We want to gauge the difference in time between when an order is entered and the actual ship time. We want to see this difference not only for the individual order, but also the difference on average.

There are several functions available already to assist in that, namely HDIFF, which will subtract two date-time stamps and return the difference in minutes, seconds, etc. The first function we’ll use is HINPUT, to convert the separate date and time fields into single date-time stamps (a requirement of HDIFF) and then calculate HDIFF. So, the Master File Description now becomes:

FILENAME=MYORDERS, SUFFIX=FIX , $

SEGMENT=MYORDERS, SEGTYPE=S1, $

FIELDNAME=ORDER_NO, ALIAS=E01, USAGE=I9L, ACTUAL=A09, $

FIELDNAME=ORDER_DATE, ALIAS=E02, USAGE=YMD, ACTUAL=A06, $

FIELDNAME=ORDER_TIME, ALIAS=E03, USAGE=I6, ACTUAL=A06, $

FIELDNAME=SHIP_DATE, ALIAS=E04, USAGE=YMD, ACTUAL=A06, $

FIELDNAME=SHIP_TIME, ALIAS=E05, USAGE=I6, ACTUAL=A06, $

DEFINE ORDTA/A8YYMD = ORDER_DATE;,$

DEFINE TIMA/A8 = EDIT(ORDER_TIME);,$

DEFINE STARTT/HYYMDSA = HINPUT(16,

(ORDTA | TIMA),8,'HYYMDSA');,$

DEFINE SHIPA/A8YYMD = SHIP_DATE;,$

DEFINE ENDTT/HYYMDSA = HINPUT(14,

(SHIPA | EDIT(SHIP_TIME)),8,'HYYMDSA');,$

DEFINE HDIFF/D12 = HDIFF (ENDTT,STARTT,'SECONDS','D12');

Of course, if the date and time of order and shipment were already date-time fields – only HDIFF would be a required DEFINE. And so the output, showing both the difference for individual records, as well as the overall average is as follows:

TABLE FILE MYORDERS

PRINT

STARTT ENDTT HDIFF AS 'DIFF.,IN SEC.'

BY ORDER_NO NOPRINT

ON TABLE SUBFOOT WITHIN

"MINIMUM DIFFERENCE IS <MIN.HDIFF "

"MAXIMUM DIFFERENCE IS <MAX.HDIFF "

"AVERAGE DIFFERENCE IS <AVE.HDIFF "

END

PAGE 1

DIFF.

STARTT ENDTT IN SEC.

------ ----- --------

2011/07/05 9:48:19AM 2011/07/05 9:55:16AM 417

2011/07/01 10:59:30AM 2011/07/05 3:50:00PM 363,030

2011/07/01 11:03:24AM 2011/07/05 4:46:11PM 366,167

2011/07/01 10:08:59AM 2011/07/06 7:23:26PM 465,267

2011/07/01 11:27:21AM 2011/07/06 12:30:21PM 435,780

2011/07/01 1:45:11PM 2011/07/01 3:20:48PM 5,737

2011/07/01 1:54:39PM 2011/07/01 2:20:47PM 1,568

2011/07/01 1:55:55PM 2011/07/01 5:34:45PM 13,130

2011/07/01 9:47:59AM 2011/07/06 3:41:09PM 453,190

2011/07/01 9:07:01AM 2011/07/06 7:03:35PM 467,794

MINIMUM DIFFERENCE IS 417

MAXIMUM DIFFERENCE IS 467,794

AVERAGE DIFFERENCE IS 257,208

This request can all be done using WEBFOCUS tools, and because the DEFINEs are in the Master File Description, the casual user need not know the parameters for the functions HINPUT and HDIFF, or even that HINPUT is required because of the data structure.

The problem is that it is truly ugly to show a difference in seconds. What is 363,030 seconds – a day, a couple of hours, a millennium? We need to translate those seconds into a display that will show days in hours:minutes:seconds, and be able to do that translation not only for the detail-level difference, but also the minimum, maximum and average.

So, let’s build the function outside of the master first, make sure it works and then incorporate it into our synonym.

What are the steps: 60 seconds / minute

60 minutes / hour

24 hours / day

So, first divide the difference by 24 * 60 * 60 to get the integer number of days. Then divide the remainder by 60 * 60 (or 3600) to get the integer number of hours. Next, divide the remainder by 60 to get the integer number of minutes. The remainder is the number of seconds.

Put them into an alpha field for display,

DEFINE FUNCTION SCTOA/A12 (DIFF/D12)

DAYS/I2S= DIFF / (24 * 60 * 60);

HOURS/I2 = (DIFF - (DAYS * 24 * 60 * 60)) / (60*60);

MINUTES/I2 = (DIFF - (DAYS *24 *3600) - (HOURS*3600)) / 60;

SCONDS/I2 = DIFF - (DAYS * 24 * 3600) - (HOURS * 3600) –

(MINUTES * 60) ;

SCTOA/A12 = FPRINT(DAYS,'I2S','A2') | ' ' | EDIT(HOURS) |

':' | EDIT(MINUTES) | ':' | EDIT(SCONDS);

END

Works fine: I put it into a FOCEXEC called TIMDISP

EX TIMDISP

DEFINE FILE MYORDERS

HDIFFA/A12=SCTOA(HDIFF);

END

And print HDIFFA correctly translates.

Now, to add the use of the function to the master, I’ll add both a DEFINE and several COMPUTEs to the MASTER, as the same function can be used multiple times. With a multi-verbset, I can then get overall totals, minimum, maximum and average, and then translate those differences as well, so long as I use COMPUTE statements to follow the result of the summing, averaging, etc.

DEFINE MYDIFF/A12= DF.TIMDISP.SCTOA(HDIFF);,$

COMPUTE MDIFF/A12 = DF.TIMDISP.SCTOA(MIN.HDIFF);,$

COMPUTE MXDIFF/A12 = DF.TIMDISP.SCTOA(MAX.HDIFF);,$

COMPUTE ADIFF/A12 = DF.TIMDISP.SCTOA(AVE.HDIFF);,$

COMPUTE TDIFF/A12 = DF.TIMDISP.SCTOA(HDIFF);,$

Here is the request:

SET DEFCENT = 20

TABLE FILE MYORDERS

SUM COMPUTE TDIFF; NOPRINT

COMPUTE MDIFF; NOPRINT COMPUTE MXDIFF; NOPRINT

COMPUTE ADIFF; NOPRINT

PRINT

STARTT ENDTT MYDIFF

BY ORDER_NO NOPRINT

ON TABLE SUBFOOT

"TOTAL TIME IS <TDIFF "

"MINIMUM DIFFERENCE IS <MDIFF "

"MAXIMUM DIFFERENCE IS <MXDIFF "

"AVERAGE DIFFERENCE IS <ADIFF "

END

Gives:

STARTT ENDTT MYDIFF

------ ----- ------

2011/07/05 9:48:19AM 2011/07/05 9:55:16AM 00:06:57

2011/07/01 10:59:30AM 2011/07/05 3:50:00PM 4 04:50:30

2011/07/01 11:03:24AM 2011/07/05 4:46:11PM 4 05:42:47

2011/07/01 10:08:59AM 2011/07/06 7:23:26PM 5 09:14:27

2011/07/01 11:27:21AM 2011/07/06 12:30:21PM 5 01:03:00

2011/07/01 1:45:11PM 2011/07/01 3:20:48PM 01:35:37

2011/07/01 1:54:39PM 2011/07/01 2:20:47PM 00:26:08

2011/07/01 1:55:55PM 2011/07/01 5:34:45PM 03:38:50

2011/07/01 9:47:59AM 2011/07/06 3:41:09PM 5 05:53:10

2011/07/01 9:07:01AM 2011/07/06 7:03:35PM 5 09:56:34

TOTAL TIME IS 29 18:28:00

MINIMUM DIFFERENCE IS 00:06:57

MAXIMUM DIFFERENCE IS 5 09:56:34

AVERAGE DIFFERENCE IS 2 23:26:48

PMF: What is a Scorecard? What is a Dashboard? By Bob Ferrante

Information Builders Performance Management Framework (PMF) is a purpose-built WebFOCUS application that enables you to deploy Scorecards to many different stakeholders in your organization. PMF is also a world-class Dashboard design, deployment and management solution.

Any time you offer something powerful and new, you end up getting questions about the intent. “Why was the software designed this way?” We frequently get two questions during PMF engagements with customers:

“What is a Scorecard, and why is it useful?”

“Dashboard – Isn’t that the same thing as a Scorecard?”

Like many “why is it?” questions, the answers allow us a moment of illumination. And what’s better, the answers are not as obvious as they might seem. Let’s answer the first question first.

What Is a Scorecard, and Why Is It Useful?

Simply, a Scorecard is a collection of metrics for a particular person or group. Much like a school report card, it displays the performance of an individual or group at doing a particular set of tasks. A well-designed Scorecard provides a holistic view of the processes to be done, the causes involved in doing the tasks, and the effects the tasks have on the organization as a whole.

We don’t want to belabor the report card metaphor. But just as a school report card shows grades (metrics) specific to the various courses you took in school; a work Scorecard would contain metrics about items and processes that are concerned with your work activities. Typically these measure items over which you have direct control, those that affect your ability to work, and those that display the high-level outcomes for your work.

If you work in sales, your Scorecard could contain metrics unique to your job. You would have metrics about your sales volume in money, your prospecting activities, and about the overall impact your sales activity has on the organization, such as cost of sales and profitability.

Your organization would probably want to have many Scorecards, because many individuals or groups of people in your organization do activities.

For example, if you have a peer at your organization responsible for a different set of tasks – say, manufacturing – they would have metrics about processes, supply costs, existing quality issues, and on the overall impact of their activities on the making of your products.

What’s more, there would be some overlap between activities, so you’d also have common metrics – measuring days or hours worked, work expenses and – most usefully – metrics that measure the total impact each of you has on the overall success of your organization.

And your various managers would also have manager Scorecards with metrics – probably aggregating the measures for all staff for which they are responsible, and adding in metrics that measure your overall success as a manager – such as employee turnover or attrition, overall employee satisfaction, and finally of course metrics about their productivity.

Confusion With “Balanced Scorecard”

The biggest challenge in the way of understanding this is that quite often, people confuse the fact PMF deploys “Scorecards” with the notion that there is a practice and methodology called Balanced Scorecard.

Balanced Scorecard is a particular type of arrangement of metrics that has to do with categories that affect your work outcomes, and how they affect your organization’s goals. Although the methodology has some flexibility, it’s what is known as a “strategy-based” approach to metrics, rather than a pure KPI-based approach.

PMF supports the Balanced Scorecard methodology purely by choice; it is in fact certified compliant with the Balanced Scorecard collective, but PMF does not require a Balanced

Scorecard practice to be effective. In that sense, PMF is “methodology-agnostic.” Enough said about that!

Dashboard – Isn’t that the Same Thing as a Scorecard?

People occasionally also confuse the terms “Dashboard” and “Scorecard.” This probably happens because some managers see a “Scorecard” as a particular report. It’s probably not the same report in each case, but for some reason they have a particular report in mind when they conceptualize “Scorecard.”

Typically the “Scorecard” will be a report that lays out their metrics in a grid with ratings to the right, and they call that their Scorecard:

What is this thing, then? It’s a Dashboard, or at least a component on a Dashboard.

Putting it Together > (Scorecard + Dashboard) = (Flexibility + Power)

Here’s a full example of a Dashboard as you might see it in PMF:

The top-left grid of this Dashboard shows something that some managers might consider to be a “Scorecard.” Actually, the entire Dashboard is showing the metrics from a particular Scorecard in PMF. Remember, a Scorecard is just a “collection of metrics of interest to a particular group of people.” In this case, the Sales group of people.

And, yes, this Dashboard uses WebFOCUS charts and reports; it could just as easily use Flex charts, Web 2.0 components, etc.

Anyway, you can actually switch the Scorecard that’s being used, and view it through the same Dashboard.

The result is as follows:

You’re seeing some of the same metrics the previous Scorecard had, and some different. That’s because the manufacturing group of people at Century Corp tracks sales, just as the sales group does. But because they make the products, they’re also interested in tracking costs (to monitor their profitability basis) and returns (to monitor customer responses to product quality level).

To summarize the two Scorecards by the metrics they show:

Sales Card Manufacturing Card

Margins Product Mix Score

Sales COGS

Customer renewals Sales

Customer visits Product returns

Staff proficiency rate Claims

Staff Attrition rate Assembly time

Employee Training Hours Accidents

Defects

Staff Attrition rate

Staff proficiency rate

Sales Card Manufacturing Card

Employee Training Hours

As you can see by glancing at this list, there is indeed some metrics overlap between these two Scorecards – the Sales, Staff proficiency rate, Staff Attrition rate and Employee Training Hours metrics are repeated for both Scorecards, but a number of metrics are unique to each Scorecard. You should know that the overlapped metrics are loaded and captured identically – they are in fact the same metric, since metrics are pooled across all Scorecards. The application of additional filtering and security, however, might allow a Scorecard a different view of this like-loaded data.

A few more points about Dashboards in PMF:

They are more of a set of Information Design structures and practices than a set of specific views of a particular set of metrics or Scorecards. For example, there are PMF Dashboards designed to allow analysis and drill, and will do so regardless of the Scorecards filled with metrics being funneled through them.

They can combine any content in the form of “gadgets,” related to Scorecards and metrics, or any other content. Most typically they will contain “gadgets” that reveal a complete picture of performance to the groups interested.

They remember the preferences of each person viewing them. In each case, the Scorecard provides a full list of the metrics available to a group or context, and the Dashboard preferences of a particular user of the system allow further narrowing down of these lists to specific areas of interest. This is done without requiring the creation of separate FOCEXECs, of course, but rather is handled by the internals of the PMF application.

Summing Up

As you can see, understanding a few items of vocabulary in this case increases the precision of the way you think about things. If you know that a Scorecard contextualizes the grouping of things we measure, and Dashboards provide lenses into ways to analyze these contexts, it makes the specification of our systems easier to think up.

This is the first in a series of articles to expose you to PMF. Hopefully it clarifies a few things, and piques your interest.

HTML Composer: Passing Display Values by Dave Denst

When creating a parameter prompt screen in Developer Studio’s HTML Composer with a display value different from the return value, you can send the display value along with the return value to a procedure.

In this article, we will look at a technique that lets a Web page call a procedure to dynamically create the display and return values for a parameter prompt. When a user picks a particular display value, it will be passed along with the return value for use in a procedure creating a report. However, if you are running the report procedure by itself, it will use the original prompted value instead.

On Screen 1 we selected a division where the display value of the radio button is Central and clicked on the Run button. The display value was passed in a parameter to the procedure creating the report and displayed in the heading. The return value, which has a corresponding value of CE, was used in a WHERE statement. We are reporting from EMPDATA, which can be found in the IBISAMP application.

Screen 1

On Screen 2 we are running the report procedure by itself, and the heading is now displaying the value of CE that was used in the WHERE statement. The rest of this article describes how this is accomplished.

Screen 2

Creating the Return and Display Values

To create the return and display values, get_divname.fex is aggregating DIV from EMPDATA and then computing the corresponding display values.

-* File get_divname.fex

SET HOLDLIST = PRINTONLY

TABLE FILE EMPDATA

SUM

COMPUTE DIVNAME/A12 = DECODE DIV (

'CE' 'Central' 'CORP' 'Corporate'

'NE' 'Northeast' 'SE' 'Southeast'

'WE' 'West' ELSE 'Unknown');

BY DIV

WHERE DIV IN ('CE','CORP','NE','SE','WE');

ON TABLE PCHOLD FORMAT XML

END

It is important to set HOLDLIST to PRINTONLY because an extra column is generated internally as a result of the COMPUTE statement, and we only want the two “visible” values returned via the ON TABLE PCHOLD FORMAT XML statement. If you are building this type of procedure in Report Painter, make sure the destination is to the Web browser as shown on Screen 3.

Screen 3

The Prompt Screen Built With HTML Composer

The Web page emp_list_launch.htm was built with the HTML Composer. The Run button has a hyperlink to a procedure called emp_list.fex (described later), and the output is directed to a frame on the same page. In the Properties and Settings of the prompt for a variable called &DIV, the Web page dynamically calls get_divnames.fex to populate the radio buttons with DIV as the value field and DIVNAME as the display field.

Also note that the Send display value is checked (Screen 4). When this feature is activated, the Web page sends two parameters to the procedure associated with the Run button: &DIV contains the return value field, and &DIV_TEXT contains the display field. When you use the Send display value feature, an extra parameter containing the display value is created with _TEXT appended to the original parameter name.

Screen 4

The Report Procedure

The report procedure emp_list.fex can dynamically use either the return value or display value in the heading:

-* File emp_list.fex

-DEFAULTH &DIV_TEXT = '?'

-SET &DIV_HDR = IF &DIV_TEXT EQ '?'

- THEN &DIV ELSE &DIV_TEXT;

TABLE FILE EMPDATA

PRINT

TITLE AS 'Job Titile'

BY LOWEST DEPT

BY LOWEST LASTNAME AS 'Name'

ON DEPT UNDER-LINE

HEADING

"&DIV_HDR Division Employees"

WHERE DIV EQ '&DIV';

ON TABLE SET PAGE-NUM NOLEAD

ON TABLE NOTOTAL

ON TABLE PCHOLD FORMAT HTML

ON TABLE SET HTMLCSS ON

ON TABLE SET STYLE *

INCLUDE = endeflt,

$

ENDSTYLE

END

The TABLE FILE component was built with Report Painter. The variable &DIV_HDR will contain the value of &DIV if &DIV_TEXT does not exist, but if it does, it will be used instead. We use –DEFAULTH for &DIV_TEXT, so a prompt for it is hidden when a dynamic prompt for &DIV is needed as shown in Screen 2.

Summary

When you use the Send display value feature in HTML Composer, the Web page will pass an additional parameter to the called procedure containing the display value. This additional parameter will have _TEXT appended to the variable name containing the return value.

Dynamic Reference Line on a Graph? InfoAssist Makes It Possible By Vicky Lozovsky

What is a reference line and why would you use it on a graph? A reference line, also known as a base line, is a line drawn across the whole area of the graph to compare, reference, or measure against the plot values.

In the analytical process, it is useful to make comparisons between the actual data and some base line, and a reference line certainly makes these comparisons easier. Some examples of reference lines include goal, target, acceptable/unacceptable ranges, and upper and lower control limits.

There are two types of reference lines: static and dynamic. A static reference line is created by setting a specific value, such as 1,000. A dynamic reference line can be created based on an ad hoc calculation or some type of condition, such as a goal that changes based on the month of the year. Hence, the dynamic approach allows more flexibility and control over the design of the graph.

In WebFOCUS 7.7.03, reference line functionality has been enhanced to accept both static values and field values. The ability to accept field values allows a property to be dynamic. The reference line can change position dynamically on the graph depending on the value of the field that is assigned to it. In previous releases, only static values could be entered for reference lines.

Screen 1 shows the InfoAssist Reference Line dialog box when the Value option is selected.

Screen 1

Screen 2 shows the InfoAssist Reference Line dialog box when the Field option is selected. If you select the Field option, you will be able to select from the available fields listed in the Field drop-down list.

Screen 2

The following image shows units ordered based on date. There is a reference line drawn

on the graph that represents a Goal that needs to be reached. The goal is dynamic and changes based on the month of the year.

Upload Utility: Solution to Limitation When Uploading Large Excel Files By Maria Volant and Dimitris Poulos

There is currently a limitation when uploading large Excel files through the Upload Data File option in Developer Studio. In some cases, increasing the Java heap size may help solve the problem, but in other cases it may not suffice because of available resources on the user’s machine.

We at Information Builders are in the process of enhancing the Developer Studio Upload Data File utility to address this use. In the meantime, users may take advantage of a new adapter option introduced in Release 7.7.03 of the WebFOCUS Reporting Server that allows you to upload large files.

Based on workbench tests performed, the Developer Studio Upload Data File utility allows you to upload Excel files of about 5MG if the maximum Java heap size is set to 2GB, and the user’s machine has about 1.7GB of free physical memory. When uploading 4MB files, the user’s machine would need to have about 1.4GB of free physical memory. Files of larger size can be uploaded using the Create Synonym tool in Developer Studio, after configuring the new Excel (via direct retrieval) adapter introduced in Reporting Server 7.7.03.

To upload a large Excel file using the Developer Studio Create Synonym tool, perform the following steps:

1. Start Developer Studio and navigate to an application folder.

2. Right-click on the application folder and select New, Synonym.

3. Select the Excel (via direct retrieval) adapter under Adapters, Configured and click OK. Note: If the adapter is not yet configured proceed with step 4; otherwise, proceed with step 6.

4. If the adapter is not configured, expand Available, Sequential and Indexed, Excel (via direct retrieval), and click Configure.

5. Click OK on the Confirm dialog, and then click on the Create Synonym button.

6. Select Local machine from the File Location dropdown.

7. Click on the eclipse button to navigate to and select the Excel file, as shown on Screen 1, and then click the Upload button.

Screen 1

Place a checkmark on the checkbox next to the default synonym name, and click the Create Synonym button, followed by the Close button.

There is a known issue when uploading the Excel file using the Excel (via direct retrieval) adapter in the Developer Studio Create Synonym tool, which is that if the Excel file being selected resides in a network drive, an error may occur after selecting the file and clicking on the Upload button. This will be addressed in a future release. If the Excel file resides in a network drive, you may use the WebFOCUS Reporting Server Console to upload the file.

To upload an Excel file using the Reporting Server Web Console:

1. Log into the WebFOCUS Reporting Server Console.

2. Click on the Adapters tab.

3. Under Configured, then double click on Excel (via direct retrieval).

4. Note: If the adapter is not yet configured proceed with step 4; otherwise, proceed with step 7.

5. If the adapter is not configured, expand Available, Sequential and Indexed, Excel (via direct retrieval), and double click on Excel (via direct retrieval).

6. Click Ok on the message that pops up.

7. Click the Create Synonym button.

8. Select Local machine from the File Location dropdown.

9. Click the Browse button next to the Upload file edit box to navigate to and select the Excel file.

10. Click the Upload button.

11. Place a checkmark on the checkbox next to the default synonym name, and click the Create Synonym button.

The Master File is created and displayed on the left side of the tree in the WebFOCUS Reporting Server Console, as shown in Screen 2.

Screen 2

Whether we upload the Excel file through the WebFOCUS Reporting Server Console or through the Create Synonym tool in Developer Studio, the Master File is created along with its access file under the server application selected by default in the Create Synonym tool (or the application folder specified, if any, during the create synonym process).

The Excel file selected to create the synonym is uploaded in the same application folder where the synonym is created. The Master File will contain SUFFIX=DIREXCEL and a DATASET parameter that would point to the location of the uploaded Excel file (e.g., DATASET=baseapp/Sales_Summary.xls).

It is important to remember that depending on the machine resources, it may be necessary to increase the Java heap size prior to uploading a large file, regardless of the upload utility being used. Below are some limitations when using the WebFOCUS Reporting Server Excel (via direct retrieval) adapter option to upload an Excel file:

• Spaces in the Excel file name is not yet supported with this method.

• Preview sample of the data file is not available during the upload process.

• User is not able to customize field names.

• User is not able to customize data types.

The Developer Studio Upload Data File utility will be enhanced in a future release to utilize the WebFOCUS Reporting 7.7.03 Server Create Synonym technology to address the current limitation when uploading large files. As result, we expect the limitations discussed in this article will not be present in the enhanced Upload Data File utility.

Source Code Management With DataMigrator By Daniel Chang

Source Code Management, also known as Revision Control, Version Control and Source Control, is software that keeps track of all work and changes in a set of files. It improves team communication, collaboration, and coordination with an automated process to manage the development lifecycle more effectively. Source Code Management would particularly interest organizations with multiple developers who need to maintain different versions of the source code without overwriting the original code.

iWay DataMigrator, which consists of a set of fully automated tools that simplify data integration, supports various Source Code Management Systems that use the Microsoft Source

Code Control Application Programming Interface (MS SCC API), including Concurrent Versions System (CVS), IBM Rational ClearCase, and Microsoft Visual SourceSafe (VSS). DataMigrator 7.7 also works with ChangeMan DS, Perforce SCM, and Subversion.

There are plenty of benefits to these various Source Code Management Systems. For instance, CVS and Subversion are open source programs and only require a plug-in from PushOk Software. In addition, we have made further enhancements to the new release of DataMigrator with added security and introduced deployment capabilities through “get latest version” functionality.

Overview of DataMigrator Source Management

Every Source Control Management System consists of a repository that holds the master copy of each file revision. DataMigrator can connect to the Source Code Management Systems through the SCC API plug-in or by invoking a client command line utility. The local working copies of master files are stored in the DataMigrator Server, inside the User Home Directory.

Each developer has a unique User Home Directory with read-write access and other developers cannot access any other directories other than their own. Developers can make changes to DataMigrator synonyms, procedures, and flows and then check in the changes to Source Control Management Systems by exporting ACX, MAS, FEX, and ETG files, respectively.

Once changes are made to a file and checked in, DataMigrator commits the request to the Source Code Management System’s repository to prepare for the next revision. All other functions, such as add, check out, view history, and get latest version, are invoked in a similar way.

The master files reside in a Central Application Directory and only the manager has write privileges to the Central Application Directory. The manager can deploy the latest files from Source Control Management System’s repository to Central Application Directory through the get latest version function.

Screen 1 shows the model of the general workflow:

Screen 1: DataMigrator Source Control Workflow

Screen 2 illustrates how the manager would register new users and assign access roles from Web Console. Note that Developer Dan’s User Home Directory (C:\ibi\homeapps\dan\scctest) allows all permissions, while in Central Application Directory (C:\ibi\apps\scctest), it prohibits write permission.

Screen 2: Register Users and Assign Access Control

Using Source Control System to Manage DataMigrator Procedures and Synonyms

Once you have properly set up DataMigrator Source Control to work with the Source Code Control Management System of your choice, using the Source Code Control functions from DataMigrator is the same for all Source Control Management Systems. The following is the list of Source Code Control functions and their descriptions:

• Add / Check In – If the file is new, add it to the Source Code Control System, else commit changes.

• Check Out – Edit the file but note that before you make any changes to it, you must first check out the file to have exclusive rights.

• Undo Check Out – Do not save the changes and adjourn exclusive rights to the file.

• Get Latest Version – This operation will obtain the latest and greatest version file from Source Code Control System’s repository. However, if the developer invokes this request, the file will be obtained in the developer’s User Home Directory. While in the manager’s request, it will be obtained inside Central Application Directory.

• History – View the history of previous versions of the file.

Screen 3: Source Control Operations

Behavior of Concurrent Check Out of Same File

What happens if two developers try to check out the same file? The developer who does it first has exclusive rights to the file until it is released either by undo check out or check in. If a developer tries to check out a file that has already been checked out by another developer, the following message will prompt this message: “Item was checked out to another user.”

We are continuing to add support for more Source Code Management Systems with DataMigrator. For more information on this topic, please refer to the DataMigrator User’s Guide, which has comprehensive steps in how you can set one up.