SOA Best Practices: The BPEL Cookbook

Building Rich Internet Applications for Workflow and Process Monitoring
by Doug Todd

Create a real-time workflow and advanced process activity monitoring dashboard by extending Oracle BPEL Process Manager APIs.

 Review complete BPEL Cookbook index

Downloads for this article:
 Oracle BPEL Process Manager

Published November 2005

More and more organizations are automating their key business processes to increase operational effectiveness. However, even automated processes require manual interaction for two important reasons: to advance a process to the next step (workflow), and to provide real-time process visibility for end-users (process monitoring).

Consider a business process for opening a new bank account. First the customer provides necessary details (name, address, SSN, initial deposit) to open the account. Once the process kicks-off, the customer will want to track the status of the request and respond to any additional queries from the bank. This process requires workflow to enable customer participation, and process monitoring so that the customer can track request status.

Oracle BPEL Process Manager facilitates basic workflow capabilities and process activity monitoring. But just as important, by extending its exhaustive API interfaces for interacting with processes, instances, and workflow, it is possible to build a single, rich internet application (RIA) that enables advanced workflow and process activity monitoring. This advanced workflow capability could enable zero-latency communications between user and process, whereas advanced process activity monitoring could transmit real-time process status information to the workflow so that appropriate actions could be taken.

In this installment of "The BPEL Cookbook," I will present a sample business scenario that requires real-time workflow and advanced process activity monitoring capability. You will then explore the architecture of a Macromedia Flash-based RIA that leverages the BPEL Process Manager API to meet those goals, and then learn how the RIA initiates processes and integrates workflow. You will also learn how to visually depict the process paths available as well as those actually taken by the current instance. (This functionality is very valuable when examining processes in retrospect.) Finally, you will get an introduction to audit trail tracking using the API interfaces.

RIA Background

An RIA is a hybrid of Web application and traditional desktop application, typically built using "interactive" technologies including JavaScript, Flash, Java Applets, XML User Interface Markup Language (XUL), Extensible Application Markup Language (XAML), JavaServer Faces, and Swinglets, often using an Asynchronous XML and JavaScript (AJAX) approach. RIAs can potentially improve the usability and effectiveness of online applications as well as increase developer productivity. According to Gartner Research, by 2010, at least 60% of new application development projects will include RIA technology of some kind.

Our example here comprises a BPEL workflow interface and process monitoring console that offers end-users a unified, feature-rich dashboard. Note that it is important to differentiate this application from the Oracle BPEL Console or true Business Activity Monitoring (BAM); although a certain level of functionality overlap exists, the RIA target user community is vastly different than that for the latter two applications. The BPEL Console is more suited for administrators and developers who debug, deploy, and maintain process instances, and BAM appeals to process owners (executives, LOB managers, and so on) and IT managers who want to measure key performance indicators (KPIs) and then take action to refine the process. In contrast, the example RIA application described here is designed with end-users in mind: customers, partners, or suppliers who want to track the status of a specific business interaction and don’t care about KPIs or process improvement.

Sample Process

The sample business process, "New Account Request," is a multi-organization process that creates accounts for a financial service intermediary, its financial partners (insurance companies and their financial advisors), mutual fund companies, and clearinghouses. Here we will focus on the first two steps of this process.

  1. The process accepts the customer’s SSN and then extracts and displays customer information (name, address) from the database.
  2. The customer verifies this data, adds the deposit amount, and clicks on Submit.
Clearly the customer will need a workflow interface to enter the SSN, verify name and address, and input the deposit amount. In addition, they will need the ability to visually monitor the progress of the request.

In the next section, I will offer an overview of the development aspects of building such an application. Later, you will see how the New Account business process executes using this application.

Building the Application

As explained previously, you will design this application with two primary goals:

  • Provide a rich unified user interface for users to track the process status and provide input as and when required (RIA frontend)
  • Offer advanced process monitoring (BPEL Process Manager API backend)

RIA Frontend. The RIA user interface is the "face" of the application; it runs and manages New Account business process. This presentation layer is built using Macromedia Flex technology and the ActionScript scripting language. It accepts the user input and passes it to the BPEL process. It also displays the current status of the process.

Figure 1 below shows the RIA front end for the New Account business process.

figure 1

Figure 1
RIA frontend for New Account process

Let's review its four main components and their key capabilities:

  • Workflow Bar: The Workflow Bar allows the user to view the workflow steps in the New Account process at the business level. Every step in the Workflow Bar is exploded in the BPEL Panel.
  • BPEL Panel: The BPEL Panel offers an exploded view of every step of the New Account process. The panel dynamically reads the process model and the instance audit trail of a given process instance to combine the process paths available with the paths actually taken by the current instance. The panel also polls the audit trail to determine what action is pending, visually delineating where the current process is at that time. Any nodes of the process previously executed can be clicked on to view their respective payload. This functionality gives operations and compliance managers real-time visibility into the past, current, and potentially future state of the current process.
  • Workflow Forms: Workflow Forms correspond to the workflow steps within the New Account BPEL process. This Flex "view stack" communicates with the audit trail of the business process, changing the view stack form to match the context of the BPEL process.
  • Zones: Zones provides alert and feedback to assist the workflow and process activity user perform their respective jobs (not discussed here.)
These panels offer superior usability experience and interact with the BPEL API. Now let's see which backend API functions are leveraged to execute the RIA front end.

BPEL Process Manager API backend. The BPELService class facilitates interaction between the RIA frontend and the process activity monitoring capabilities in the BPEL Process Manager API. As shown in Figure 2 and described in the subsequent table, BPELService uses five interfaces within the BPEL Process Manager API for process, process instances, and tasks to deliver on the promise of workflow-enabled process activity management and monitoring.

figure 2

Figure 2
UI-to- BPELService functionality map

Interface Allows the user to...
IDeliveryService Invoke instances from processes deployed on a BPEL process domain
IBPELProcessHandle Explore a BPEL process deployed on a BPEL process domain
IInstanceHandle Perform operations on an active instance
ITask Interact with a task that has been instantiated in a process domain
IWorklistService Search for and complete tasks that have been instantiated from the process domain

Now that you understand the basic components of RIA and BPELService, let's see how they work together to offer a rich end-user experience.

Running the New Account Process

As explained previously, the customer is first presented with an input screen in the workflow panel to enter the SSN. As soon as the user clicks on Submit, a "New Account Application" XML document is created using ActionScript and passed to the BPELService server-side Java class via Flex's Remote Object Architecture. (This enables Flex to speak directly to Java objects such as BPELService.) The Java component uses an instance of the IDeliveryService interface to initiate the BPEL process. The initiateProcess Java method, shown below, then returns the instance reference-id of the newly created business process instance to the Flex client. This reference-id is used in subsequent operations for targeting the correct business process instance.

/**
* This function initiates an instance of a BPEL PM process based on the
* process name. The function sets the function id and the reference id for
* future use.
*
* @param xmlRequest
*            is the initiating request message for the process
* @param strBusinessProcess
*            the business process name
* @return the initiating response message for the process
*/
public String initiateProcess(Document xmlRequest, String strBusinessProcess) {

System.out.println("Initiate" + strBusinessProcess);
/*
* This interface allows users to invoke instances from processes
* deployed on a BPEL process domain.
*/
IDeliveryService deliveryService = getDeliveryService();
/*
* Construct the normalized message and send to Oracle BPEL process
* manager
*/
NormalizedMessage nm = new NormalizedMessage();
nm.addPart(PAYLOAD, xmlRequest.getDocumentElement());

NormalizedMessage responseNm = null;
try {
responseNm = deliveryService.request(strBusinessProcess, PROCESS,
nm);
} catch (Exception e) {
e.printStackTrace();
throw new RuntimeException("Could not initialize process.");
}
Map payload = responseNm.getPayload();
Document xmlResponse = getXMLDoc(XMLHelper
.elementToString((Element) payload.get(PAYLOAD)));
/*
* Sets the Instance reference ID for interagating active BPEL
* instances.
*/
setInstanceReferenceId(strBusinessProcess, xmlResponse);

return XMLHelper.elementToString(xmlResponse.getDocumentElement());
}
Enabling workflow. As shown in Figure 3, customer data is retrieved from an external system via the BPEL process and presented in the workflow panel. The user then verifies the data, enters the deposit amount, and clicks on OK.

figure 3

Figure 3
Verifying customer data and input deposit amount

The workflow capabilities are based on the ITask and IWorklistService interfaces provided by BPEL Process Manager. The RIA co-relates the tasks in the IWorklistService with the workflow screen needed to complete the given task. When proper form validation has occurred, the user interface makes a remote object call to the completeTask method, shown below, to send the data captured in the UI to the BPEL process for further processing.

/**
* This function gets the use input from workflow zone, relates it to a task
* and completes the task. The function uses instance reference id for
* identifying process instance.
*/

public String completeTask(String strInstanceReferenceID,
String strActivityLabel, Document payload) {
System.out.println("completeTask-" + strInstanceReferenceID + "-"
+ strActivityLabel);
String strStatus = "OK";
try {
IWorklistService worklist = getWorklist();
// get task reference
ITask task = getTask(strInstanceReferenceID, strActivityLabel);

// set task payload
task.setAttachment(payload.getDocumentElement());

worklist.completeTask(task);

} catch (Exception e) {
e.printStackTrace();
strStatus = ERROR_STRING;
}
return strStatus;
}
The code places the task specific data into the task attachment provided by the ITask interface. This interface not only sends the pertinent data back to the BPEL process, but also places that data into the BPEL process audit trail.

Next, I'll introduce the other important aspect of your RIA application: process monitoring.

Monitoring Process Activity

During the first two steps discussed above—initiating the process and enabling the workflow—process states are visually updated via IProcessHandle and IInstanceHandle API interfaces.

Oracle BPEL Console provides a Web-based interface for deploying, managing, administering, and debugging BPEL processes. It’s an administrative tool designed using JSP pages and servlets that call the BPEL Process Manager API. Consequently, you can easily develop your own RIA console using the API to provide a business-level, process-monitoring interface.

This console provides visual feedback for a specific instance of a process and even provides a link into the audit trail data associated with a given step in a process. However, the primary advantage of RIA console lies in its ability to perform actual versus planned analysis. The console displays all the possible steps a process could take during its execution; it also renders the path that was in fact taken during execution. Users can click on any process node to retrieve the BPEL payload and render the payload information in a dialog box.

Thanks to visually demarcated ideal-versus-actual process paths and the ability to drill down at the payload level, end users can analyze the process and identify the trouble spots on their own, without IT intervention. Figure 4 depicts an example of actual-versus-ideal process path analysis; the "actual" path is haloed in green.

figure 4

Figure 4
Actual-versus-ideal process path analysis

Next we'll examine how processes are rendered to enable this analysis and how to retrieve the audit trail data and depict it visually within a RIA application.

Rendering the Process

The Flex BPEL Panel component makes calls to the IProcessHandle interface to retrieve the XML representation of the business model in its entirety. The BPEL Panel uses IInstanceHandle interface to gather the XML representation of the current instances audit trail. The BPEL Panel then compares and merges the two XML representations to create a user interface that can portray the entire model and the path taken.

Flex is particularly adept at such operations by virtue of its native XML capabilities. Flex can easily merge two XML representations by using a combination of Flex repeater controls and ActionScripts. Together, they have the ability to convert XML into an array and then utilize the inherent array handling capabilities to facilitate the merge of the XML.

The Process Model XML actually serves as the basis for the BPEL Panel as it contains all possible nodes. With each step of the Process Model, the Process model ID is compared to the audit trail model ID. When the IDs of the process and audit match, the results of that node are copied from the audit model into the process model. Determining what path was taken is as simple as interrogating which nodes in the model have actual instance data associated with them.

The code snippets below show the getProcessModel and getInstanceAuditTrail methods.

getProcessModel method

/**
* This function gets the debugger XML model of a given BPEL process.
*
* The function returns the xml model.
*
*
* @param strProcessID
*            the business process name.
* @return the xml process model.
*/
public String getProcessModel(String strProcessID) {
        System.out.println("getProcessModel - " + strProcessID);
        String strProcessModel = "";
        try {
                IBPELProcessHandle process = getLocator().lookupProcess(
                                strProcessID);
                // Returns the debugger XML model of this BPEL process.
                strProcessModel = process.getProcessModel();
        } catch (Exception e) {
                e.printStackTrace();
                strProcessModel = ERROR_STRING;
        }
        return strProcessModel;
}
getInstanceAuditTrail method
/**
* This function gets the XML audit trail of a given BPEL process.
*
* The function returns the xml model.
*
*
* @param strProcessID
*            the business process name.
* @return the xml process model.
*/
public String getInstanceAuditTrail(String strInstanceReferenceID) {
        System.out.println("getInstanceAuditTrail - " + strInstanceReferenceID);
        String strResponse = "";
        try {
         IInstanceHandle instance = getInstance(strInstanceReferenceID);
                // Returns the XML representation of the audit trail of this
                // instance.
                strResponse = instance.getAuditTrail();
        } catch (Exception e) {
                e.printStackTrace();
                strResponse = ERROR_STRING;
        }
        return strResponse;
}
Viewing Audit Trail Data

Audit trail data is available to each node of a process that has already executed. This functionality is similar to that in the BPEL Console. The Flex user interface accesses the details data for the node of the process chosen in the user interface (see Figure 5).

figure 5

Figure 5
Viewing payload information

Audit trail data can be extracted using the following ActionScript 2.0 code:

bpelObject.bpelDetails = eventData.event.details.data;
The Flex interface polls for changes in the status of the current business process by tracking activity in the audit trail to visually delineate what step is pending in the business process. When a change is detected, the Flex application requests a new current instance trace using a remoting call to retrieve the audit trail. The instance trace is then used to display data on the input screens associated with each BPEL process user task. Flex client input screens are associated with corresponding BPEL process steps using activity Correlation-IDs.

Conclusion

The value of a business process lies in its ability to offer superior visual depiction of process performance and enable task integration. The application described here offers tremendous aesthetic appeal to end-users.

As I've demonstrated, RIAs can offer a loosely-coupled presentation tier approach for delivering new SOA applications. By combining an RIA frontend with an SOA backend, enterprises can lower the management and deployment costs of internet applications. Doug Todd Doug Todd is CTO of Enterra Solutions in Yardley, Pa. He has more than 20 years of experience in systems architecture, applications architecture, systems integration, and applications integration with major corporations. Todd is responsible for Enterra’s overall IT strategy and tactical implementation, enterprise information architecture, and technology product offerings.

Send us your comments