WebLogic Integration (WLI) consists of many application components, including a B2B application that manages business-to-business contracts during software conversation. To support the B2B application, WLI has a business process management (BPM) application for connecting business processes together. This used to be marketed as a discrete product, WebLogic Process Integrator (WLPI).

The BPM application's ADK requires the application developer to understand the architecture of the BPM application. The ADK has a number of components whose use depends on the state of the workflow and the operation that's required. Interaction with the BPM ADK's components and objects leads to an application developer coding to a low level interface.

This article outlines the design of a simple facade to the BPM ADK, providing a clean object interface that is, by intent, easy to use. It simplifies interaction with the BPM engine and ensures that changes in the underlying BPM implementation won't affect the ADK adversely. Access to the BPM application is solely via the publicized WLPI interface.

Using the Simplified ADK
In creating this ADK I wanted to produce a simple object model that could be used within either a Java client or a JSP. Due to the nature of the BPM application there are many state objects. For example, an InstanceInfo object describes a running workflow and a TaskInfo object describes a task. These state objects have no direct association with each other, but have a relationship based on the underlying RDBMS.

Programming to the BPM ADK led to code that, while meeting the application requirements, was both difficult to read and hid my intent in low-level detail. When I programmed to the BPM ADK directly, there was a tendency to parse XML documents frequently and a lot of interaction with EJB components that didn't appear, at first glance, to have any direct responsibility for the operation I required. For example, the Admin EJB is responsible for finding out what tasks are available in a workflow and the Worklist EJB is responsible for executing the task in the workflow.

In the WLI ADK, interaction with the workflow is indirect, with the workflow described by an InstanceInfo object. The InstanceInfo attributes are used in interactions with the Worklist component or the Admin component to effect a change in the workflow state. This led to code that was often difficult for a reader new to the BPM interface to understand, which caused me concern over the long-term maintenance of the code base.

Using the facade design pattern, I produced a simplified ADK to the BPM application. The first step was to understand the main use cases and key entities that most BPM applications have. The use cases in many BPM clients are:

• Find out what workflows the user could start and then start one of them
• Execute a task (or mark it as done)
• Set or get a workflow variable's value
• Stop a workflow

ADK Key Concepts
In most applications the key entities for interaction with the BPM interface were often found to be User, Workflow, Task, and Variable, as workflows are inherently stateful (see Figure 1).

IUser
The IUser is a simple interface. Its contract states that the user should be identifiable and have an organization. As I show below, the WLIUser class is the entry point to the BPM ADK.

IWorkflowController
The IWorkflowController is a simple interface with two main overloaded methods, getAvailableWorkflows and getRunningWorkflows. I defined an available workflow as one that the user can start and a running workflow as one that has been started. I intended to make the controller an intelligent factory, removing the need to create a workflow instance directly. If the underlying BPM application changes, with this mechanism the ADK's clients would then be decoupled from the change.

IWorkflow
The IWorkflow interface says that a workflow can be started and stopped, variables set and read, and a set of tasks (ITask) can be accessed. It doesn't expose all the information that a WLI workflow can contain. It does, however, capture what I felt was the general essence of the workflow that I felt sufficient when exploring the ADK's design. Future implementations of the interface may expose more information.

In this ADK a workflow can have three main states: defined, running, and stopped. A defined workflow is defined within the BPM studio. It has tasks and may have workflow variables defined. Defined workflows can have instances created if the permissions of the workflow allow it. A workflow instance is a running workflow. Running workflows can have tasks waiting to be executed and may have workflow variables to set. A stopped workflow is a workflow instance that's been stopped. In this stopped state Workflow variables can be read, but their values can't be set.

Variables
A workflow variable can have many types, from Java objects to XML documents. These are defined in the WLI documentation. This ADK is designed to work with most forms; however, only the XML variables are currently implemented. The problem was how to get variables into WLI. As a Java variable could have many classes, in addition to BPM applications having different or changing ways of setting a workflow variable, there was a design challenge. By applying the Mediator pattern it became simple to define a variable formatter to overcome the system boundary (see Figure 2).

Tasks
A workflow task is defined within the BPM studio. The Task is a collection of actions. This ADK does not interface with the actions directly, as this is the domain of the BPM application. My intent is to delegate the process logic to the BPM engine rather than have it hard-coded. The task interface defines operations to query the state of the task and to execute the task.

Use-Case Model
The process I adopted for this development was to implement the ADK in a use case­driven manner, the use cases providing the impetus to understanding how the ADK could be used. The application I produced was a simple command line interface to the workflow system. The command line application would be able to start and stop workflows, execute tasks in a workflow, and set and get workflow variables. The simple use-case model is shown in Figure 3.

Use-Case Realizations
I use a single use-case realization to describe the ADK design.

Starting A Workflow With Variable
In this use case we need to start a workflow for a user see Figure 4. The workflow should have a value passed to it before starting. In WLI BPM this is where a workflow that has a mandatory input variable is defined.

The IWorkflowController creates a list of IWorkflow objects depending on whether the client requires a new workflow started or an existing workflow. Creation of WLIWorkflow objects is only via the IWorkflowController interface and the class WLIWorkflowController, shown in Figure 5, realizes this interface. The workflow controller is responsible for generating lists of workflows based on the user's permissions. How the permissions affect the starting of a workflow is dependent on the underlying workflow engine. A WLI user can belong to multiple organizations with one organization specified as the user's default organization. For this iteration of the ADK I decided that the WLIWorkflowController would only access workflows in the user's default organization.

An instance of WLIWorkflowController is normally created with a WLIUser object specified. The WLIUser class acts as a facade to the underlying WLIPrincipal remote interface and UserInfo class. It creates an association to the underlying UserInfo object. I decided to keep the IUser interface simple since it focuses on the use cases described above.

ADK Code Walk
To illustrate how the ADK can be used, we'll walk through the pseudo code in Listing 1.

In line 1 a WLIUser object is created and the J2EE connection information is supplied, along with the organization that the user will belong to for this interaction. The J2EE connection information object is a data structure for holding all properties required to open the JNDI initial context. At line 2 the WLIWorkflowController is created for the user. Line 3 illustrates the use of the workflow controller to get the workflows that are available to the user. Lines 4 through 7 are interactions with the user. In line 8 I create a WorkflowVariable that's an instance of XMLWfVar (XML Workflow Variable) and in line 9 a value for the variable is set. Line 10 introduces the concept of the VariableFormatter, discussed below. The workflow variable is associated with the workflow in line 12. Finally, the workflow is started.

WLI Implementation
In this section I'll discuss the design of the ADK with regard to the underlying WLI implementation.

WLIUser
The class WLIUser aggregates a reference to the WLPIPrincipal EJB, which is responsible for accessing the security principal of the caller. The call

theUserInfo = principal.getUserInfo(userId);

returns a state object of class UserInfo. The WLIUser object caches this state, and maintains the reference to the WLPIPrincipal. Access to the WLPIPrincipal cache is available to other classes in the Java package.

WLIWorkflowController
The WLIWorkflowController uses a reference to the Worklist EJB. For a call to WLIWorkflowController.getAvailableWorkflows(), the code in Listing 2 shows that the workflow list is first configured for the caller's organization. The call to Worklist::getStartableWorkflows returns a list of TemplateInfo objects that are used to create WLIWorkflows.

The WLIWorkflowController passes a reference to the BPM's Admin EJB to the WLIWorkflow on construction of the WLIWorkflow. This EJB is used to control access to the workflow variables.

To access running WLI workflows the client would use the method WLIWorkflowController.getRunningWorkflows(). The code snippet below shows the mechanism used within the ADK. Access to running workflows in the WLI ADK is not via the Worklist EJB, but rather by the Admin EJB.

instanceList =
admin.getTemplateInstances(wf.getId(),
user.getOrganisation().getId(),
true,from,to,0,0);

To find a running workflow, the ADK must first find workflows that the user can start. Once the list of workflows that can be started is created, the ADK queries the Admin EJB to find out which workflow templates have running instances. The simplified ADK hides the client from this complexity.

WLIWorkflow
The WLIWorkflow object is created with a reference to the Admin and Worklist EJBs. These EJBs are the main access route for workflows into the BPM application. If the Workflow is being created for a workflow that has not yet been started (i.e. in a defined state), the WLIWorkflow object must be created with a reference to the com.bea.wlpi.common.TemplateInfo object for the workflow. The BPM's TemplateInfo class is responsible for encapsulating simple information about a template's instance. The Worklist EJB in the WLIWorkflowController returns the TemplateInfo object.

Should the workflow be running, the WLIWorkflow object must be created with a reference to a com.bea.wlpi.common.InstanceInfo object. This contains state information about the workflow and is used by the WLIWorkflow object to access task information.

Starting a workflow in WLI is achieved in one of two ways. The mechanism depends on if the workflow has had variables associated with it. I wanted to hide this from my ADK's clients.

If we have a workflow in a defined (nonstarted) state, the WLIWorkflow object starts the workflow as follows:

wList.instantiateWorkflow(
wList.getActiveOrganization(),
wfTemplate.getId());

The instantiateWorkflow() method in com.bea.wlpi.server.worklist.Worklist is used, and has the organization and the template identifier passed to it. To me, this mechanism doesn't manipulate workflows; rather, it relies on the client to track template identifiers and organizations. I wanted to hide this level of detail from the ADK's clients; treating the Workflow as an entity in the design allowed me to use the facade pattern to abstract the client away from the underlying WLI complexity. The importance of this is further underlined when setting variables in running workflows or manipulating tasks.

If the workflow has variables to be passed to it before starting, the ADK's clients need to have invoked setVariable on the WLIWorkflow object. The workflow object caches the variables in a HashMap, which is then passed to the overloaded instantiateWorkflow() method defined in com.bea.wlpi.server.worklist.Worklist.

Variables
The ADK's concept of Workflow Variables has already been introduced above. In Figure 2 I showed the class diagram for the workflow variables and variable formatters. A key design consideration was to decouple the ADK's clients from the underlying variable structure that a BPM engine required. In WLI's BPM application the variables are passed to the workflow instance via either the com.bea.wlpi.server.admin.Admin EJB or the com.bea.wlpi.server.worklist.Worklist EJB. The Worklist EJB is used if the workflow is to be started in the same call. If the workflow has already started, the Admin EJB is used.

In the Worklist EJB, passing a hashmap of the variable objects to the instantiateWorkflow() method sets the input variables. The keys to the hash map are used for the variable names; the object in the hash map is used for the variable value.

In the Admin interface, the method below can be used:

admin.setInstanceVariable
(instanceInfo.getTemplateDefinitionId(),
instanceInfo.getId(),
var.getName(),
var.getFormatter().getObjectFormattedVariable());

I wanted the clients to be abstracted from the complexity required to support multiple variable formats. The Mediator pattern was an excellent solution for this required decoupling. Now the client can set a workflow variable on a workflow and the client doesn't need to be aware of the underlying mechanism that the BPM requires, or the format of the workflow variable. The client needs only to associate the correct variable formatter with the variable.

Tasks
In the WLI BPM, application tasks are where operations are performed. These may be manual actions that a user must undertake, or a programmatic action that allows the BPM to integrate existing application processes. If a task is accessed within a Java application, then the application is interrogating the state of the task to either monitor the progress of the workflow or use the task as an indicator that the application is required to undertake some manual action. If this isn't the case, then it's probably that there are better mechanisms to achieve the requirement, such as using JMS signals from the BPM.

In the ADK, tasks can have one of the following states: started, completed, or inactive. WLI has an overdue state which isn't currently supported. An inactive task is one that's defined in the BPM, but the preconditions for its starting haven't yet been met. A started task is one where all of its preconditions are met and the automatic processing of the task's actions has started. A completed task has completed all of its actions and been marked done. Marking a task as done can trigger additional processing within the task. For this reason, we execute a task within the ADK. This signifies that there may be processing yet to be done. Once the task is executed (all actions are performed) then the task is completed.

Access to a WLI workflow's tasks is via the com.bea.wlpi.server.admin.Admin EJB using the method:

List lst = admin.getInstanceTasks(instanceInfo.getId());

This method returns a list of com.bea.wlpi.common.TaskInfo objects. As a workflow has tasks, I did not want to expose the Admin EJB to the ADK's clients. Using the IWorkflow::getTasks() method, the client can access tasks directly from the workflow object. This method will return a list of ITask objects. Once the client has the task object it can manipulate the task without having any dependency on the Admin EJB.

Executing the task requires an interaction with the com.bea.wlpi.server.worklist.Worklist EJB. The method used within the simple ADK is shown below:

wList.taskExecute(taskInf.getTemplateDefinitionId(),
taskInf.getInstanceId(),
taskInf.getTaskId());

Currently, the WLITask doesn't have any method for waiting for task completion. The WLI BPM application is designed to support tasks that are very long running, spanning days or months. I've stayed away from specifying this behavior in the task interface. Should ADK clients require this functionality, then I believe they should be aware of the implications!

Conclusion
I've outlined the design of a simple facade ADK to the WLI BPM application. The WLI BPM, while not very complex, requires that the developer be aware of the BPM architecture. This facade uses the key concepts of User, Workflow, Task, and Variable to make the processing of workflows independent of the BPM application. As the BPM application matures, the need for a façade like this may decrease. For now, this facade provides an abstraction from the underlying middleware.