The Performance Management Revolution Business Results Through Insight and Action_8 pot

146 BPM Meets BI
– Provide the run-time environment for WebSphere MQWF Web client, WBI
Monitor, WebSphere Portal, and Web services.
– Provide the run-time environment for the Alphablox server-side
components.
Note: In the scenario, DB2 is used to invoke a Web service to retrieve data from
the WBI Monitor. There are other ways of gaining access to this data. The
WebSphere Portal, for example, could invoke the Web service directly to retrieve
the data.
The approach used in the demonstration was chosen to show how Web service
data can be integrated with database-resident data with DB2 data federation
capabilities.
6.1.1 Extending the scenario
The demonstration used in the redbook project shows only a small subset of the
capabilities offered by the IBM BPM Platform. There are several ways this
demonstration could be extended. WebSphere Business Integration Server (WBI
Server) and appropriate WBI Application Adapters, for example, could be
introduced to provide access to packaged applications from vendors like SAP
and Siebel. These adapters can be integrated at a process level using
WebSphere MQWF as shown in Figure 6-2, or at a data level using WebSphere
II (this requires WebSphere MQ and WebSphere II Business Integration
wrapper).
These various options show the flexibility of a service-oriented architecture
(SOA); that is, the ability to interconnect and integrate various components
based on application requirements without the need to build custom
point-to-point connections. It also demonstrates how components can be
integrated at the workplace, process, or data level according to business needs.
Chapter 6. BPM and BI solution demonstration 147
Figure 6-2 Integrating packaged applications into the demonstration environment
6.1.2 Scenario product architecture
Figure 6-3 is an outline of the physical deployment of the products used in the

demonstration.
Microsoft Windows client interfaces for WBI Workbench and WebSphere Studio
Application developer (WSAD) were used during project application
development. A Web browser interface was used to run the demonstration and to
interact with the run-time components of products like WebSphere Portal. All of
the major server systems and databases were run on a single hardware server.
Spreadsheet
Query
Query &
Disseminate
Warehouse
Application
Real-Time
Information
Federated
Access
(Web Service)
Web
Portal
Hybrid
Data Warehouse
(Tables, XML, GBOs)
SAP
Application
Siebel
Application
Silo
Silo
Workflow
FDL

Audit
Info
Audit
Trail
Export
Workflow
WBI
Workbench
(Model)
WBI
Workbench
(Model)
Execute
Workflow
Execute
Collaboration
MQ Workflow
Connector
SAP
Connector
Siebel
Connector
Audit
Info
Monitor
Information
WBI
Monitor
WBI
Monitor

Monitor
DB
MQ
Workflow
Engine
WebSphere
Business
Integration
148 BPM Meets BI
Figure 6-3 Demonstration product architecture
Several of the products shown in Figure 6-3 provide more than one user
interface, for example, Windows desktop, Web browser, or a programmable API.
The purpose of the demonstration was to show the Web interface to products.
We also wanted to demonstrate how a portal can provide users with a complete
and personalized Web interface to the information and applications they need to
do their jobs.
If we consider the enablers of the IBM BPM Platform discussed earlier, we can
see that the demonstration encompasses information analysis and monitoring
(using DB2 and a DB2 Web service, for example), business process (using
WebSphere MQ Workflow and WBI Monitor), and user access to information
(using WebSphere Portal).
6.1.3 Hardware and software configuration
The hardware server we used for the project was an IBM IntelliStation® M Pro,
with a 2.2 GHz Pentium® 4 processor and 1.5 gigabytes of main memory. The
configuration was just sufficient to run all of the various components
simultaneously on one machine. In a production environment, however, it is likely
that key components of the configuration would be installed on multiple hardware
servers. Database services, application services, and presentation services can,
for example, be separated onto different machines. The advanced management
WebSphere

Portal
Desktop
Server Side
DB2
WebSphere
MQ
MQ
Workflow
WebSphere
Application
Server
V5.0 & V5.1
Client Side
WBI
Monitor
MQWF
Web Client
Portal DB
MQWF DB
Monitor DB
WBI
Workbench
WSAD
MQWF
Portlet
Web Browser
Report
Portlet
Warehouse DB
Web Page

Portlet
Alphablox
Monitor
Web
Service
Run-Time
Environment
Development
Environment
Chapter 6. BPM and BI solution demonstration 149
features of WebSphere Studio Application Developer and WebSphere
Application Server make it easy to distribute applications and processing in this
manner.
We used the following software packages during the project:
– Windows 2000 Server with Service Pack 4
– WebSphere MQ V5.3
– WebSphere MQ Workflow V3.5
– WBI Workbench V4.2.4
– WBI Monitor V4.2.4
– DB2 V8.1
– DB2 Alphablox V8.2
– WebSphere Information Integrator V8.2
– WebSphere Studio Application Developer V5.1
– WebSphere Portal Server V5.0
– WebSphere Application Server V5.0 (for hosting the WebSphere Portal,
WBI Monitor, and Web services)
– WebSphere Application Server V5.1 (for hosting DB2 Alphablox)
We installed DB2, WebSphere II, WebSphere MQ, and MQWF after we installed
and made sure the Microsoft Windows operating system was working. Next we
installed two versions of WebSphere Application Server, as well as WebSphere

Studio and WebSphere Portal Server. Finally, we installed WBI Workbench, WBI
Monitor, and DB2 Alphablox.
It is important to note there are version interdependencies between some of the
software packages used. The DB2 Alphablox package is a relatively new addition
to the DB2 product line, and it requires Version 5.1 of WebSphere Application
Server. On the other hand, the versions of WebSphere Portal Server and WBI
Monitor we used required Version 5.0 of WebSphere Application Server. So, for
this particular project, we used two application servers on the same machine. In
a production environment, you would likely use different components of the
system on different machines, and this duplication therefore would not occur.
We installed all of the software components in a Microsoft Windows environment.
Since most of the components are Java applications, we could have used a Linux
or AIX operating environment also.
150 BPM Meets BI
6.2 Implementing the BPM scenario
The implementation of the business scenario demonstration required us to
install, test, and deploy different software and application components. The
objective of the demonstration was to get these various components working
together to support a BPM environment, and to show using a portal as an
interface to the information produced by these products.
We discuss the demonstration scenario in the rest of this chapter. It begins with
the business processes, then we add each enhancement. The scenario consists
of the following:
 Business processes
 Adding BI
 Adding DB2 Alphablox
 Adding WebSphere Portal
In each case, we first discuss specific development considerations, then review
the operation of that part of the demonstration in support of the scenario.
6.2.1 The business processes

This part of the demonstration shows the development and execution of the
workflow process model. Then we gather and display the business process
performance data.
WBI Workbench
The first step in the demonstration is to describe and model (using WBI
Workbench) the business process for the scenario. This model describes the
applications, users, and data involved in the business process, and the business
metrics to measure the performance of the process.
WBI Workbench comes with a set of sample models stored in the samples
directory. The model we used in our scenario is based on the CreditRequest
process. The workflow diagram of this process is shown in Figure 6-4.
Chapter 6. BPM and BI solution demonstration 151
Figure 6-4 CreditRequest process model
We customized the sample CreditRequest process model to support our
business scenario by adding two business metrics (in WBI Modeler terms),
Company Name and Request Approved, to the model so that this information
can be available to WBI Monitor. Figure 6-5 shows how we added the Company
Name metric to the model using WBI Workbench. Note that WBI Workbench
uses the term measure, which is a synonym for metric.
Once we completed the model definition, two outputs were generated by WBI
Workbench for use by other products in the scenario.
1. A Flow Definition Language (FDL) representation of the CreditRequest
process model. This representation was imported into WebSphere MQWF to
create a run-time implementation of the process. FDL is a standard defined
by the Workflow Management Coalition (WfMC). A recent upgrade to WBI
Workbench (V5.1) is also able to generate Business Process Execution
Language (BPEL) representations of the model for use in BPEL-compliant
business process engines.
2. An XML representation of the model for use by WBI Monitor. This
representation contains information required for monitoring the process

(business metrics, costs, and business activity timings), but not required for
152 BPM Meets BI
the run-time execution of the process. The integration of both process data
and business measurement data for managing business performance is
where WBI Monitor and WebSphere MQWF deliver excellent capabilities for
applying technology to business problems.
Figure 6-5 Adding a business metric in WBI Workbench
The process workflow
The execution of the CreditRequest process was handled by WebSphere MQ
Workflow (MQWF), which controls a process as it executes. It handles tasks such
as:
 Users to involve in the process (to allocate work items, for example)
 Applications to invoke for a particular business activity
 Decisions to make based on the data flowing through the model
The CreditRequest model is imported from WBI Workbench using an
FDL-formatted file.
WebSphere MQWF has the ability to generate audit data. This data includes, for
example, information about process start and stop times, and about the users
who perform activities associated with the business process. Summary and
detailed audit data can be written to an audit database, or to a message queue.
Chapter 6. BPM and BI solution demonstration 153
For the project demonstration, audit output from WebSphere MQWF was written
to a set of audit tables (see Figure 6-6). This data is collected by WBI Monitor
and stored in the WBI Monitor repository for analysis.
Figure 6-6 Setting the MQ Workflow audit settings
The workflow audit data, when combined with the WBI Workbench business
metric definitions (contained in the XML export file), enables WBI Monitor to
provide detailed analyses of business performance.
Running the credit request process in WebSphere MQWF
The CreditRequest process allows business users to create, approve, or reject

credit requests. The following list is an example of how a credit request might
flow through WebSphere MQWF.
1. The credit request administrator creates a new credit document and identifies
the company requesting the credit. In the demonstration, we did this using the
WebSphere MQWF portal interface shown in Figure 6-7. This default portal
interface can be tailored using Java Server Pages (JSPs).
154 BPM Meets BI
Figure 6-7 Creating a new request for credit
2. The document is routed by MQWF to the user responsible for collecting and
entering credit information, and the document will then appear as a work item
on that person’s worklist. The user can check the item out from the worklist,
enter the required information into the credit document as shown in
Figure 6-8, and then check the item in again for further processing. This step
corresponds to the CollectCreditInformation step in the process model shown
in Figure 6-4. You will notice in Figure 6-8, that the user has not approved the
credit request (AddApproval=“N”). The reason this has not been approved yet
is because a credit request for a customer with a high risk factor
(RiskFactor=“H”) or a credit request for an amount in excess of $100,000
requires approval by the credit administrator.
3. The credit document is then routed back to the credit administrator for review
and risk assessment (AssessRisk step in the process model). At this point in
the workflow, the administrator can change the Approval field to “Y” and the
credit document is routed for final processing. If the administrator does not
make this change, then the credit request is rejected and routed to a senior
manager for final review (RequestApproval step in the process model).
4. At this point the senior manager can approve or reject the credit request. The
document will be routed for final processing or sent back to the customer as
rejected.
Chapter 6. BPM and BI solution demonstration 155
Figure 6-8 Entering credit request information

Monitoring the workflow
We used WBI Monitor in the demonstration to display the status of all the work
items, who owns them, in what stage of the process they are, the status of
completed work items, and so forth. For WBI Monitor to be able to calculate and
show business metrics for the process performance data imported from MQ
Workflow, the associated process model (containing definitions for the required
metrics) must be imported from WBI Workbench. This step is shown in
Figure 6-9.
Note that once you have implemented the IBM Common Events Infrastructure
(CEI) in the IBM BPM product set, you can use it to route process event data to
WBI Monitor, too.
156 BPM Meets BI
Figure 6-9 Importing the process model XML file into WBI Monitor
WBI Monitor uses a workflow dashboard and a business dashboard to present
information to administrators and users. The workflow dashboard shows the
status of the work items in progress (an example is shown in Figure 6-10). The
business dashboard is the one of interest in our scenario because we can use it
to show the status of credit requests that have completed processing, and this
information has context to the business owners of this process. Specifically they
can see the details about how many of their top tier customers have had credit
refusals, which is exactly what they are trying to prevent.
The Business Dashboard shows summaries of information, and enables further
analysis. As an example, it is possible to drill down on a summary to see the
individual process information. In this example related to credit requests, we can
review the specific reasons that led to the credit rejection.
Chapter 6. BPM and BI solution demonstration 157
Figure 6-10 WBI Monitor Workflow Dashboard
We created the business dashboard to show this information using the form
shown in Figure 6-11. As you can see in the figure, we entered the name of the
process (CreditRequest), the name of the process attribute (RequestApproved),

and the time period for which information is required.
158 BPM Meets BI
Figure 6-11 Creating a WBI Monitor Business Dashboard
The output for the business dashboard defined in Figure 6-11 is shown in
Figure 6-12. Notice that two requests were approved (these were added to the
demonstration to make the report seem more realistic), and one was denied. At
the bottom of the report, the credit requests are listed by date and by the
RequestApproved attribute.
Chapter 6. BPM and BI solution demonstration 159
Figure 6-12 WBI Monitor Business Dashboard
The numbers on the dashboard are also Web hyperlinks. These can be used to
drill into detailed information about the status of a credit request, as depicted in
Figure 6-13.
160 BPM Meets BI
Figure 6-13 Process instance overview from the WBI Monitor Business Dashboard
6.3 Adding BI to the demonstration
So far in the demonstration we have seen how you can use WebSphere to
design, deploy, and monitor the CreditRequest business process. The next step
in the demonstration is to gather metrics about key customers, and correlate the
results with the credit request metrics produced by WBI Monitor. This analysis
puts us in a position to determine the key customers who have had their credit
requests rejected. A key customer is defined as one of the top ten customers.
The three software components that typically would be used to add the BI
analysis of customer and credit request data to the demonstration are IBM
WebSphere Information Integrator, DB2, and Web services. However, in this
particular scenario we used an alternative approach, which is described in
Section 6.3.2, “Federation through DB2 XML Extender” on page 162. In this
scenario, we used DB2 to manage all the BPM data sources in the
demonstration, including the data warehouse database (WHDB) containing
historical customer sales data. We used Web services to gather credit request

data from the WBI Monitor database to correlate with customer data in the data
warehouse. These Web service requests were implemented using a “pull”
methodology, which refreshed the data every time a user refreshed the Portal
page showing the summary of the credit rejections.
The data warehouse database has a company table containing financial
information about customers. This table is an aggregated view defined over
lower-level detailed sales data that has been accumulated in the data
warehouse. We show the schema for the table in Figure 6-14.
Chapter 6. BPM and BI solution demonstration 161
Figure 6-14 WHDB company table
6.3.1 Federation through WebSphere Information Integrator
Typically, WebSphere II would access the data warehouse through the DB2
wrapper, which uses the DRDA protocol to send requests from WebSphere II to
the DB2 data warehouse. However, in this particular scenario we used an
alternative approach as described in Section 6.3.2, “Federation through DB2
XML Extender” on page 162. For completeness, we describe here how the
scenario would work when using WebSphere II.
WBI Monitor 4 does not expose its underlying DB2 database interface for
external access, therefore WebSphere II uses the Web service wrapper to
access the real-time information from WBI monitor. During the configuration of
the Web service wrapper, WebSphere II uses the WSDL file from WBI Monitor to
suggest how the XML response data from the Web service call is mapped to
nicknames. During runtime, application developers would write SQL queries to
access information from those Web service nicknames. WebSphere II then
translates the SQL queries into SOAP requests and sends them to the WBI
source. It automatically transforms the XML result from the SOAP response into
relational structures and returns them as the SQL query result.
162 BPM Meets BI
As a result of this configuration, both sources (DB2 data warehouse and WBI
Monitor) are accessible in WebSphere II through nicknames. Now the

administrator can specify views to integrate the relevant information from the
various nicknames. Those views integrate the data from the various sources and
hide the underlying heterogeneity. As a consequence, the application developer
only needs to submit a single simple query against the view.
Advantages of using WebSphere II as the middleware to integrate historical data
and real-time information include features like an open architecture to support
heterogeneous environments. This enables the extensibility and flexibility to
integrate data from a wide range of data sources. It also enables increased
productivity and time to market because of the reduced development time when
accessing Web services through a wizard-based setup. This configuration aid
eliminates the burden of mapping XML data from the Web service response to
relational structures, and reduces the overhead for the application developer.
6.3.2 Federation through DB2 XML Extender
As an alternative to WebSphere II, the DB2 data warehouse can directly access
the WBI Monitor through DB2 XML Extender and Web services. DB2 is used
both as the data warehouse and, at the same time, as the middleware to
integrate the data warehouse with the WBI Monitor.
Enabling the DB2 XML Extender and Web Services
The DB2 configuration for the WHDB data warehouse database included the
DB2 XML Extender and DB2 Web service consumer functions. An overview of
the definition for the DB2 database is shown below.
 Database name: WHDB
 Database schema: db2xml (default schema used by the XML Extender)
 The DB2 XML extender is enabled using the dxxadm utility, which creates the
following objects:
– The XML Extender user-defined types (UDTs)
– The XML Extender user-defined functions (UDFs)
– The XML Extender DTD reference table, DTD_REF, which stores XML
DTDs, and information about each DTD
– The XML Extender usage table, XML_USAGE, which stores common

information for each table column and collection that is enabled for XML
 The DB2 Web service consumer functions are enabled using the
db2enable_soap_udf utility. These functions are used to invoke a local or
remote Web service provider.
Chapter 6. BPM and BI solution demonstration 163
Using the Web service to access WBI Monitor data
We defined a Web service to retrieve credit request performance data from the
WBI Monitor database and reformat it for use in the demonstration scenario. The
required method for accessing Monitor data is through the WBI Monitor API. In
this test scenario, the Web service was run on WebSphere Application Server to
place it close to the WBI Monitor database. The Web service was invoked from
the DB2 instance containing the WHDB database. Two DB2 user-defined
functions were used to access the Web service.
Although we used only one server in our environment, a Web service can also be
called across the network from other systems. This remote invocation
mechanism makes it easy to distribute processing and data across multiple local
and remote servers.
The SQL DDL statements for the two DB2 user-defined functions are shown in
Example 6-1 and Example 6-2. The statement in Example 6-1 registers a
user-defined function that invokes the DB2-provided Web service consumer
function db2xml.soaphttpc. This consumer function is used to call the Web
service. The consumer function requires three parameters:
 Target URI: This parameter specifies the hostname and port number where
the Web service resides.
 SOAP action: This parameter sometimes is required by gateways or service
providers for routing Web service requests.
 SOAP body: This parameter defines an XML-formatted message to be sent to
the Web service. It specifies the name and parameters of the method to be
invoked. The method in this case is called:
getProcessInstanceByModelNames and it has four parameters:

– dbname: Name of the database where the WBI Monitor data resides.
– userid: Name of the user calling the service.
– password: Password of user calling the service.
– processModelNames: A list of the process model names for which monitor
data is to be returned.
Example 6-1 Creating the user-defined function for accessing the Web service
CREATE FUNCTION db2xml.getProcessData(dbname VARCHAR(255), userid VARCHAR(255),
password VARCHAR(255), procmodel VARCHAR(255)) RETURNS CLOB(1M) RETURN
db2xml.soaphttpc ( 'http://localhost:9080/wbi/servlet/rpcrouter', '',
xml2clob(XMLElement(NAME "ns:getProcessInstanceByModelNames",
XMLAttributes(' />vice' as "xmlns:ns", ' as
"xmlns:SOAP-ENV", ' as
"SOAP-ENV:encodingStyle"), XMLElement(NAME "dbname",
164 BPM Meets BI
XMLAttributes(' as
"SOAP-ENV:encodingStyle", 'xsd:string' AS "xsi:type"), dbname), XMLElement(NAME
"userId", XMLAttributes(' as
"SOAP-ENV:encodingStyle", 'xsd:string' AS "xsi:type"), userid), XMLElement(NAME
"password", XMLAttributes(' as
"SOAP-ENV:encodingStyle", 'xsd:string' AS "xsi:type"), password),
XMLElement(NAME "processModelNames",
XMLAttributes(' as
"SOAP-ENV:encodingStyle", ' as
"xmlns:ns2", 'ns2:Array' AS "xsi:type", 'xsd:string[1]' as "ns2:arrayType"),
XMLElement(NAME "item", XMLAttributes('xsd:string' AS "xsi:type"),
procmodel)))));
The second user-defined function, depicted in Example 6-2, handles the
response received from the Web service. The response is an XML message,
which the function transforms into a relational format. This transformation
process is often called shredding. The version of DB2 used in the demonstration

did not have a facility for parsing XML documents, and so the transformation was
done using a combination of string and XML Extender functions. Note the use of
XPath queries in the user defined function to find the relevant parts of the XML
message. For the demonstration, we are interested in company names and the
status of their credit requests.
Example 6-2 Creating the user defined function for shredding the XML results
CREATE FUNCTION db2xml.shredProcessData(data CLOB(1M)) RETURNS TABLE
(completetime REAL, company VARCHAR(32), approved CHAR(1)) RETURN
WITH s(doc) AS ( SELECT SUBSTR(data, POSSTR(data, '<processModels'),
POSSTR(data, '</return>') - POSSTR(data, '<processModels')) FROM
TABLE(VALUES(1)) t ), t(doc) AS ( SELECT CAST(returnedclob AS db2xml.xmlclob)
FROM s, TABLE(db2xml.extractclobs(CAST(s.doc AS db2xml.xmlclob),
'/processModels/processModel/processInstance')) t ), u(completetime, company,
approved) AS ( SELECT db2xml.extractreal(t.doc, '//PI_COMPLETE_TIME'),
db2xml.extractvarchar(t.doc, '//VARIABLE[@name="Company Name"]'),
db2xml.extractchar(t.doc, '//VARIABLE[@name="Request Approved"]') FROM t
) SELECT * FROM u WHERE SUBSTR(approved,1,1) in ('Y', 'N');
Creating the performance metrics
Now that all definitions have been set up, we can gather information about key
customers, and correlate the results with the credit request metrics produced by
WBI Monitor.
The key customer metric is created using information in the company table,
which resides in the data warehouse database. This table contains information
about companies, including their name and total sales revenue for the year. The
Chapter 6. BPM and BI solution demonstration 165
SQL statement in Example 6-3 produces a metric showing the top 10 companies
(ranked by sales) from the company table.
Example 6-3 Retrieve the top 10 companies ranked by total sales revenue
WITH d AS (
SELECT RANK() OVER (ORDER BY sales DESC) AS rank, SUBSTR(name,1,35) AS name,

INTEGER(sales) AS sales
FROM db2xml.company
)
SELECT * FROM d WHERE rank <= 10;
Data from the WBI Monitor database is retrieved using the SQL statement shown
in Example 6-4. This statement invokes the Web Service that retrieves data from
the WBI Monitor database using the db2xml.getProcessData user-defined
function, which can invoke a process that retrieves the data via the WBI Monitor
API. The results are in a XML format.
Example 6-4 Calling the Web service to retrieve data from WBI Monitor
VALUES SUBSTR(db2xml.getProcessData('CreditRequest','userid','pw'),1,1024);
The XML-formatted data retrieved from the WBI Monitor database can be
shredded into a relational format using the db2xml.shredProcessData
user-defined function. The SQL to do this is shown in Example 6-5.
Example 6-5 Reformatting the XML results into a relational form
SELECT * FROM
TABLE(db2xml.shredProcessData(db2xml.getProcessData('CreditRequest'))) X;
Now that we have demonstrated how to get data out of both the data warehouse
and WBI Monitor, we can create the SQL that will join the data from the data
warehouse with the data from WBI Monitor. The SQL illustrated in Example 6-6
returns the frequency of credit approval and rejection for the top 10 companies
(ranked by sales). This is done using two in-line views: view
p returns the names
of top ten companies from the data warehouse, and view
s calculates the total
number of credit requests approved and rejected for all companies. The join
column is company name and the final result of the query is the names of top ten
companies, and the number of credit requests approved and rejected for those
companies.
Example 6-6 Joining the data warehouse and WBI monitor data

WITH
p AS (
SELECT company,
SUM(CASE approved WHEN 'Y' THEN 1 ELSE 0 END) AS approved,
166 BPM Meets BI
SUM(CASE approved WHEN 'N' THEN 1 ELSE 0 END) AS rejected
FROM TABLE(db2xml.shredProcessData(db2xml.getProcessData
('CreditRequest'))) p
GROUP BY company),
s AS (
SELECT RANK() OVER (ORDER BY sales DESC) AS rank, SUBSTR(name,1,25)
AS name, INTEGER(sales) AS sales
FROM db2xml.company)
SELECT s.rank, s.name AS company, s.sales, p.approved, p.rejected
FROM s, p
WHERE s.name = p.company AND s.rank <= 10
GROUP BY s.rank, s.name, s.sales, p.approved, p.rejected
ORDER BY s.rank;
6.4 Adding DB2 Alphablox to the demonstration
The SQL statements shown in 6.3, “Adding BI to the demonstration” on
page 160, provided low-level SQL access to the WBI Monitor Web service and
the contents of the data warehouse. Business users are not expected to code
these statements, or to even be familiar with SQL. To provide a simpler interface
for creating and displaying performance metrics in the demonstration, we used
DB2 Alphablox.
6.4.1 Configuring the components
DB2 Alphablox provides a set of powerful software components called Blox,
which make data exploration and analysis easier. We now show how Blox
components were tied to the BPM demonstration.
We installed DB2 Alphablox as an enterprise application in WebSphere

Application Server V5.1. It provides its own Web interface for administration tasks
such as defining data sources, applications, and users. We first used the
administrative interface to declare the data warehouse database (WHDB) as an
Alphablox data source. We depict this in Figure 6-15.
Chapter 6. BPM and BI solution demonstration 167
Figure 6-15 Defining the data source to Alphablox
Next we used the Query Builder feature of Alphablox to construct an initial Blox
query definition over the WHDB data source. The Query Builder screen is
depicted in Figure 6-16. The Query Builder makes it easy to create a graphical
rendering of the results of an arbitrary SQL query, like the ones we showed in the
previous section.
168 BPM Meets BI
Figure 6-16 The Alphablox Query Builder
A Blox definition was generated automatically by clicking on the ‘Generate Blox
Tag” button in Query Builder. The result was a fragment of Java Server Page
(JSP) code, as depicted in Figure 6-17.