There are two kinds of processes: public and private. Public processes are developed for B2B transactions and enable the interaction of trading partners in a business-to-business arrangement, whereas private processes are internal to an enterprise and trading partners cannot interact with them directly. The BPM Studio can be used to model, execute, and monitor both types of processes. You can develop these inter-enterprise processes using Studio by installing a B2B plug-in (covered later in the chapter). The messages flowing between these processes must be based on a format that is acceptable to all parties involved. ebXML and RossettaNet are among the message standards that are supported by BPM. Private processes are used for intra-enterprise needs. These processes do not interact with any external entities like business trading partners. For example, when a customer places an order on an e-commerce Web site, a private workflow may be initiated to send email confirmation to the customer when the order items are shipped.

The end-to-end integration sample shipped with Platform 7.0, as discussed in Chapter 33, “Introducing WebLogic Integration (WLI),” has both private and public business processes. In the B2B portal, when the Avitek purchase agent submits a Query for Price and Availability (QPA), an XML representation of the QPA is pushed to a JMS destination, which triggers a private workflow. This private workflow invokes a public workflow, passing it the QPA request XML document. This request is then further packed into an ebXML message based on the trading partners’ (Supplier One and Supplier Two) agreement. The exchange of this ebXML message takes place through a hub that acts as a proxy between the buyer and the partners (see Figure 34.5).

Figure 34.5. Public and private QPA processes in the end-to-end sample.

In the design phase of Business Process Management, the business process is conceptualized and designed using graphical tools such as Studio. The Studio tool helps to graphically describe a process, its inputs, and outputs. Using WebLogic Integration Studio, a process designer can put together a business process without knowing the underlying technical implementations. The designer identifies the process flow using entities called nodes. These nodes are steps in a business, which may represent a decision point or an end of the process. The nodes available in the BPM design tool, Studio, include the following:

Using nodes, a business process is designed and saved as a template definition as part of a template in an associated data store (Oracle, SQL Server, and so on) of the process engine. A template is equivalent to a business process. Just as a business process evolves as business requirements change, a template allows multiple template definitions. This template definition can be re-used and modified for other business processes. In the next phase of Business Process Management, the process engine executes an instance of the designed template definition.

In the execution phase, XML is used for data representation, and JMS is used for messaging between workflows and/or other back-end applications (AI is the recommended way to connect to the back-end applications). A business process execution can be triggered in various ways, as illustrated in Figure 34.2. Typically, multiple instances of a business process are executing at a given time. In the integration sample, the E2E_OrderWorkflow executes when an XML message appears on a configured event queue.

Ongoing monitoring is very important in Business Process Management. Monitoring may be extremely useful when statistical data is collected in real-time. Users can modify running workflows if needed. This monitoring can be done using Studio. In the integration sample described earlier, the E2E_OrderWorkflow simply receives the XML message, takes the data sent, and persists that data into back-end tables. The Studio tool can be used to monitor the scenario. You can monitor the E2E_OrderWorkflow by first starting the server; to do so, run the <WL_HOME>/weblogic700/samples/platform/e2eDomain/starte2e.bat script.

After the server is up, log in as Rachel Adams on the B2C portal and add items to the shopping cart. Then proceed to Step 3, as shown in Figure 34.7. When you click the Submit Order button, an XML representation of the order is placed on a JMS queue, triggering a workflow.

Figure 34.7. WebLogic Platform sample application B2C portal.

This workflow can be monitored using Studio. Figure 34.8 shows the XML order received in the workflow. Studio can also be used to change the running workflow without necessarily interrupting it.

Figure 34.8. Monitoring workflow using Studio.

In our first example, the workflow triggers on an XML event (see the properties of the start node in Figure 34.9). Many workflows can consume the messages placed on the default JMS queue. You can specify a root element for each workflow in the Start Properties dialog box to distinguish between messages it is interested in. In the HelloWorld workflow, the helloworld root element is specified. A driver in the sample source (MyQueueSender.java) sends an XML message to the default queue (com.bea.wlpi.bpm.event), as shown in the following code:

Figure 34.9. Properties of the start node in the HelloWorld workflow.

<?xml version="1.0" encoding="UTF-8" ?>
<helloworld>
</helloworld>

When the XML message is sent to the JMS queue, the workflow is triggered and completes execution. You can use Studio to see that the workflow started and completed (see Figure 34.10).

Figure 34.10. Monitoring the HelloWorld workflow.

You can run Example1 as follows:

Studio is a graphical design tool that allows you to design and monitor workflows. It comes with the following utilities:

Worklist is a swing-based tool that is used to interact with a workflow. It can be used to both start and stop a workflow. Using Worklist, a user can provide specific input to a process. For example, if the inventory is less than a certain amount, the process could be set to get an approval before back-ordering a part. The inventory manager would then need to log on using Worklist and approve or disapprove the order.

This tool is deprecated and will be replaced by a JSP-based tool. Users can also write their own tools using the BPM API.

The second example shows how to start a workflow and then execute a specific task within the workflow by using BPM APIs.

A workflow (called MyWorkFlow) has been created using Studio. This workflow is designed so that it can be started manually (see the manual option in Start Properties dialog in Figure 34.11). After the workflow is started, a task (called MyTask) is activated. Refer to Figure 34.11.

Figure 34.11. Example2: The MyWorkflow workflow.

MyTask is designed to send an XML response to the client including the date and time (see Figure 34.12).

Figure 34.12. Example2: Properties for MyTask.

At this point, a command-line Worklist client has been created; it will start this workflow and execute the task named MyTask.

Now you can establish a connection to the running BPM server and obtain a handle on the WorkList Session Bean, as shown in Listing 34.1.

private static boolean connect(String url, String userId, String password ) {
     Object result;
     try {
        ctx = getInitialContext(url, userId, password);
        result = ctx.lookup(WORKLIST_JNDI);
        WorklistHome wHome = (WorklistHome)
               PortableRemoteObject.narrow(result,WorklistHome.class);
        worklist = wHome.create();
        return true;
      }
      catch(Exception e) {
        System.err.println("Caught Exception:" + e);
      }
      return false;
}

Start the workflow by using Worklist EJB, as shown in Listing 34.2. You can obtain a list of workflows that can be started manually by using the following method:

public java.util.List getStartableWorkflows(java.lang.String orgID)
    throws java.rmi.RemoteException,  WorkflowException

From the list of startable workflows, you can choose and instantiate MyWorkFlow by using the following call:

public java.lang.String instantiateWorkflow(java.lang.String orgID,
                                            java.lang.String templateID,
                                            java.lang.Object requestID)
                             throws java.rmi.RemoteException, WorkflowException

/**
  * Start a workflow
  */
  public static String startWorkflow(String templateName) {
    String instanceId = null;
    try {
        String activeOrgId = worklist.getActiveOrganization();
        List templates;
        templates = worklist.getStartableWorkflows(activeOrgId);
        for(int i = 0; i < templates.size(); i++) {
          TemplateInfo templateInfo = (TemplateInfo)templates.get(i);
          if (templateInfo.getName().equals(templateName) == true) {
             String response = worklist.instantiateWorkflow(activeOrgId,
                                      templateInfo.getId());
             System.out.println("response:
" + response);
             //parse instance id from response
             int j = response.indexOf("<instanceid>");
             int k = response.indexOf("</instanceid>");
             instanceId = response.substring(j + "<instanceid>".length(), k);
          }
        }
   } catch (Exception e) {
       System.err.println("Caught Exception : " + e.getMessage());
   } finally {
       return instanceId;
   }
}

The response you will obtain is shown in the following code:

<wlpiresponse>
  <instanceid>13001</instanceid>
  <templatedefinitionid>9001</templatedefinitionid>
  <root>
    <actionid>1029650142617</actionid>
    <DateOfMyWorkFlow>Sun Aug 18 01:16:34 MDT 2002</DateOfMyWorkFlow>
  </root>
</wlpiresponse>

The response is parsed to get the instanceid. This instanceid is used for executing a task. To execute a task, use the method shown in Listing 34.3.

public TaskInfo getTask(java.lang.String taskName, java.lang.String instanceID)
                 throws java.rmi.RemoteException, WorkflowException


  /**
    *  Execute task of a given workflow
    */

  public static boolean executeTask(String taskName, String instanceId) {

  try {
       TaskInfo taskInfo = worklist.getTask(taskName, instanceId);
       String response =
            worklist.taskExecute (taskInfo.getTemplateDefinitionId(),
                                  taskInfo.getInstanceId(),
                            taskInfo.getTaskId());
       System.out.println("response:
" + response);
       return true;
      } catch (Exception e) {
          return false;
      }
  }

The following is the response you will obtain:

<wlpiresponse>
  <instanceid>15002</instanceid>
  <templatedefinitionid>9001</templatedefinitionid>
</wlpiresponse>

You can then run Example2 as follows:

You can design a workflow that has two or more parallel paths. To make a workflow with parallel paths structured, it is important to have all parallel paths originating from a common node end at the same And node. The parallel paths should have the same entry and exit points to make them structured (see Figure 34.14).

Figure 34.14. Implementing the parallel execution pattern.

In the case that a subset of parallel paths (say, path1 and path2) needs to merge at a different And node, a dummy task node that simply marks itself as done can be placed to create nested parallelism. Figure 34.15 shows how a single entry point is created using a dummy task for two parallel paths that merge at a different And node (see the dotted section in the figure).

Figure 34.15. Single entry and exit points.

It is important not to have any “dangling paths” in a workflow. A path is said to be dangling when it contains a task with no subsequent node.

The Choice of Events pattern is for solutions that have parallel paths, that need to execute in a mutually exclusive manner, and their execution is dependent on the occurrence of one or more events. It is important to have a cancel event in place to achieve this mutual exclusion; that is, after an event that starts an execution path is received, a cancel event action should be used to cancel other possible events, which may trigger other execution paths. All mutually exclusive paths should end at an Or node (see Figure 34.16).

Figure 34.16. Implementing the Choice of Events pattern.

The Event with Timeout pattern represents a workflow where mutually exclusive events can trigger different execution paths within a set time frame. So, there is a deadline in which the events must occur to trigger the respective execution paths. The timeout logic is typically implemented using a Timed Event action or a Set Task Due Date action. The latter is preferred and recommended as it results in a cleaner and easier-to-understand implementation. All the paths except one that has timeout functionality should start with an event node. (All paths except the execution path 3 shown in Figure 34.17 start with an event node.) The execution path 3 starts with a task node, which has a Set Due Date action for timeout. The last sub-action of this node should mark this task as done. After this node, a decision node checks the occurrence of events E1 and E2 with a flag (this flag is set when either E1 or E2 occurs). If the flag is not set, a task node with Cancel Event actions is executed, thereby suppressing other execution paths. All the execution paths should converge at the same Or node.

Figure 34.17. Implementing the Event with Timeout pattern.

The Cancellation via Event pattern represents a workflow where it is required to cancel an execution path if an event occurs. There are two variations to this pattern, depending on whether the execution path can be canceled in the middle of its execution. In the first variation, the cancellation event does not have any effect if the path has already started its execution. The second variation occurs when checks for the cancellation event are made at various points of execution in the workflow, so the cancellation may be effective throughout the execution path. This variation is complex and may require careful coordination of execution and cancellation paths (see Figure 34.18).

Figure 34.18. Implementing the Cancellation via Event pattern.

The cancellation path should start with an event node waiting for a cancel event. The regular execution path should start with a task node, which provides some latency by entering a quiescent state for a short span, allowing the event node to register properly. The cancellation path should set a flag after the event occurs; the event can be checked in the regular execution path after the quiescent state is exited. A decision node after the timeout node should test the value of the flag. After the regular execution path starts, the event node must be prevented from firing. This can be done by a Cancel Event action that cancels the cancellation event. Both of these execution paths must converge to an Or node.

Similar guidelines should also be followed for the second variation. The cancellation path should start with an Event node that waits for the cancellation event. As in the previous variation, start the normal execution path with a Task node that blocks for a short duration. The last action should disable the Event node by canceling the cancellation event through use of a Cancel Event action. Both execution paths should converge to an Or node.

The Execution Timeout pattern is similar to the Cancellation via Event pattern in that a timeout, instead of an event, causes the cancellation of the execution path. A scenario in which a workflow’s execution path must be completed in a certain amount of time fits into this pattern. Some of the guidelines for such a pattern are as follows. The timeout path must contain a task node that contains the timeout action. A task with a Set Task Due Date action is recommended. Both the normal execution path and the timeout path should have a single point of entry and should converge at an Or node. The timeout path must be disabled after the regular execution path has completed. This can be achieved by setting a timeout disabled flag (as shown in Figure 34.19) after the regular execution path has finished execution. A decision node must check this flag before doing any processing in the timeout path.

Figure 34.19. Implementing the Execution Timeout pattern.