| products | dev2dev | support | askBEA
 Download Docs   Site Map   Glossary 

Learning to Use BPM

 Previous Next Contents View as PDF  

Introduction to Business Process Management and the Sample Workflows

The example workflows documented in this tutorial, which are contained in the Tutorial.jar file provided in the SAMPLES_HOME/integration/samples/bpm_tutorial folder, illustrate many of the most commonly-used business process management (BPM) features of WebLogic Integration. They do not represent a real-world implementation, but present a highly simplified scenario that allows you to gain experience running the two client applications provided for business process management: the Studio (design environment) and the Worklist (run-time environment).

Note: The Worklist client application is being deprecated as of this release of WebLogic Integration. For information about the features that are replacing it, see the BEA WebLogic Integration Release Notes.

This overview provides the context for the example workflows so that you can gain a picture of the entire puzzle before you begin to piece it together in the remaining sections of the tutorial. Specifically, this section includes the following:


Overview of the Scenario

Our example workflows are loosely based on a generic Web-based sales order scenario. Once the order has been received, the workflows control the processing and fulfillment of the order, as it passes through the stages of approval, inventory checking, shipping, and invoicing. The following narrative describes the processes and data that make up the scenario:

  1. A customer submits an order for goods to CDExpress, a music retailer, through an online mechanism such as a browser-based order form. The customer supplies his or her name, the appropriate e-mail address, the state to which the order will be shipped, the desired items (IDs and names), and the requested quantities.

  2. The order is received by a processing system, which reads the data and appends an ID number to the order.

  3. The order is forwarded to a customer service representative, who checks the customer's credit information.

  4. If the credit check fails, the customer service representative is assigned the task of notifying the customer to obtain correct credit information, and the process becomes manual from this point on.

  5. If the credit check passes, the system checks a database for the current inventory of the ordered item, according to the item ID, and it compares the quantity of items available with the quantity requested.

  6. If the amount of stock is not sufficient to accommodate the order, the order is placed on hold until new inventory arrives. When the system receives notice of new incoming inventory, it repeats step 5 until it can verify that the inventory is sufficient to process the order.

  7. If the inventory is sufficient, the order is forwarded simultaneously to a shipping agent who arranges shipment, and an accounting agent who instructs the system to generate an invoice for the order.

  8. If the system encounters an error in processing the input necessary to calculate the total price for the invoice, including state sales tax, the accounting agent who initiated the billing process is notified and prompted to provide the correct information.

  9. The system calculates the total price of the order.

  10. The system confirms that the order has been shipped and notifies the customer via e-mail.

  11. At any point in the transaction before shipping, the order can be cancelled by notification from the customer.

To get an idea of what our workflow will look like, we can sketch out a preliminary flowchart, as shown in the following figure. The numbered sections correspond to the steps in the preceding procedure.

Figure 1-1 Sales Order Scenario



Overview of the BPM Environment

Although you can use a Studio workflow to perform certain business processes directly—such as sending e-mail to a client, or assigning a manual task to a Worklist user—mostly you design workflows to integrate external software components, while the workflow definition serves to control the sequence in which these external program modules are invoked. Thus, before you can begin to draw a workflow, you should identify the external components, such as Enterprise JavaBeans, Java classes, or other applications with which you will need to interface.

To help identify the external components that we will need for our scenario, let us first review the role of WebLogic Integration in relation to WebLogic Server and the middle tier of a Java 2 Enterprise Edition (J2EE) model-view-controller multitier application. The following figure locates the WebLogic Integration server in relation to the other components needed to implement our scenario in a distributed J2EE/WebLogic Server application.

Figure 1-2 WebLogic Integration BPM Environment


As the figure shows, BPM operates at the business-logic layer of the J2EE framework. This means that a workflow directly integrates business objects, such as Java classes and Enterprise JavaBeans (EJBs), while for communication with other components or applications, it exchanges eXtensible Markup Language (XML) messages via the intermediary of the Java Message Service (JMS).

In fact, the entire front-end application, which receives and formats input from an external client, is not represented in a BPM workflow. Rather, it is at the point where the Web components need to interact with the EJB layer that the workflow takes control of processing. Thus, a common way for a workflow to be started is to be triggered by an external event, namely the arrival of the appropriate XML document on a JMS topic, as pictured in the figure.

According to this framework, the order-placement process of our scenario is not normally captured in a BPM workflow. It is, however, simulated for the purposes of this tutorial. (See Working with the Sample Workflows for more information.) Rather, the start of the workflow would be the point at which the order is passed on for processing, as depicted in the following figure.

Figure 1-3 Sales Order Scenario: Start Mechanism


Let us redraw our scenario flowchart, then, so it shows, more accurately, the starting point of the workflow and the extra step that is needed to intercept a cancellation notice.

Figure 1-4 Sales Order Scenario: Start and Finish



Modeling the Scenario in WebLogic Integration

Having defined the scenario and reviewed the WebLogic Integration BPM environment, we now need to determine how we will map the real-world processes and entities in the scenario to the workflow modeling constructs provided by the WebLogic Integration Studio. To do so, we must identify:

Each of these modeling tasks is discussed in the following sections.

Defining Application Users

Before we actually model the workflows, we first need to define the system in terms of the real-world agents who will interact with it. The Studio provides three constructs to define context of use: organizations, users, and roles. The following sections describe these constructs and explain how they are used in the tutorial scenario.


An organization represents a company or site location. Organizations are business process management-specific constructs which you create in the Studio, and do not correspond to any users or groups defined in WebLogic Server. However, users can be associated with an organization, and roles (see Roles) are defined within one. Workflows may be associated with a single, or with multiple organizations.

The organization for our scenario is CDExpress, which has been predefined for you.


These are users of the Studio and Worklist client applications, and are defined in a WebLogic Server security realm. Users may be created in the Studio, and should be associated with at least one default organization. Although users can access workflows associated with any organizations, they can only execute workflows within the organization(s) to which they have been assigned. Users may also be associated with roles (see Roles).

Our organization, CDExpress, includes three of the default users that are shipped with the Studio: joe, mary, and admin.

For complete information about users and permissions, see "Maintaining Users" in Administering Data in Using the WebLogic Integration Studio.


A role represents the generic business function that a user may perform, independent of his or her individual user account. For example, a role may be a department, or a job description or title. In our scenario, roles correspond to the customer service representative, accounting, and shipping roles.

Roles are contained within an organization, so that each organization has a unique set. Roles must be mapped to groups that have been configured on WebLogic Server, although you can automatically create a WebLogic Server group when you create a role in the Studio.

Finally, roles can have one-to-one, one-to-many, or many-to-one associations with users. That is, one user might take on several roles, while one role may be filled by several users.

The CDExpress organization contains the following roles, mappings, and member users, all of which have been predefined for you.

Table 1-1 Default CDExpress Roles, Groups, and Member Users


Maps to WebLogic Server Group

Member Users













For complete information about roles and permissions, see "Maintaining Roles" in Administering Data in Using the WebLogic Integration Studio.

Identifying External Components

In the case of our scenario, we can identify the following Web and back-end components which we need to integrate in our workflow to accomplish the work we want to perform:

Without explaining the details of how a workflow interfaces with external components for now (which is discussed in Defining Workflow Interfaces), the following figure locates the points in our preliminary workflow at which external components are required.

Figure 1-5 Sales Order Scenario: External Components


In the example workflows, only the EJB-level components identified in the above figure are implemented and provided, although interfaces to the other components are defined in the workflows. Thus, external components are represented in the sample workflows as follows:

  1. The front-end client application or servlet that would start the entire process are not provided. Rather, this module is simulated by a separate workflow, described in Working with the Sample Workflows.

  2. For the method that checks inventory, a session EJB, POBean.jar, is provided in the lib directory of your WebLogic Integration installation. Although in real-world applications, the EJB would query a database, in the examples, the database of item IDs is simulated by an array of values hard-coded into a Bean class.

    Note: The POBean EJB is automatically deployed on WebLogic Server when the WebLogic Integration server is started.

  3. No actual application is used for inventory reporting, but an interface to one is created in the sample workflow. For details, see Creating an Event: Defining the Wait for New Inventory Event.

  4. The method that calculates the total price is provided in the POBean.jar session EJB. Although in a real-world application the EJB would query a database, in the sample, the database of U.S. states is simulated by an array of values hard-coded in a bean class.

  5. No component is provided for the order cancellation process, but an interface to such a component is created in the sample workflow. For details, see Creating an Event: Defining the Watch for Cancellation Event.

Defining Workflow Objects

Having identified the external components we will use in our application, we can now begin to model our scenario processes by defining the objects that our workflow requires. The following sections provide an introduction to workflow objects, and examples of the functions that each object serves in the sample workflows.

Nodes and Connections

Nodes are the major building blocks with which you construct your workflow and demarcate business processes. Connections form the transitions between nodes. Seven types of nodes can be used to capture the different requirements of a business scenario, as described in the following table.

Table 1-2 WebLogic Integration Studio Nodes

Functional Requirement

Typically Modeled by

Studio Shape

Specify work to be performed by humans or software.

Task node

Delimit the boundaries of a process.

Start node

Done node

Specify the order in which work is to be performed: in sequence or parallel.


AND node

OR node

Specify a repeated course of action or a backtrack to a previous step (looping).


Specify an alternative course of action as the result of a decision.

Decision node

Specify an alternative course of action as the result of an external or ad hoc event.

Event node


Normally the completion of one node causes the successor nodes to be activated in a sequential manner, unless the flow is overridden by a particular action (see Actions for a description).

Events represent a special type of node in that they function as wait states within a workflow. Although an event is activated by the completion of a predecessor node, it is triggered asynchronously by the arrival of an XML document for which the event has been configured to listen. XML messages may be received from external applications via an external JMS queue, or from other workflows via an internal JMS queue.

Note: Event nodes can also be triggered by plug-in-defined events, which can use a mechanism other than XML on JMS. For more information about programming plug-ins, see Programming BPM Plug-Ins for WebLogic Integration.

In our sample workflows, in addition to the required start, task, and done nodes, we also use:

Thus, our scenario can be represented as shown in the following figure.

Figure 1-6 Sales Order Scenario: Studio Workflow


In the example workflows provided, this single workflow has been split into two: a main workflow and a sub-workflow, as shown in the following figure.

Figure 1-7 Sales Order Scenario: Main Workflow and Sub-Workflow


As the figure shows, an additional node is used in the main workflow to call the sub-workflow.

We draw nodes in Creating a Workflow, and define them in Defining Workflow Nodes.


An action is the basic unit of work that you use to construct a workflow. The Studio provides 28 types of actions which perform different operations, ranging from assigning manual tasks to Worklist users, to controlling the overall program flow, and integrating and communicating with external components.

Note: The default catalog of actions can be extended through the use of a plug-in. For more information about programming plug-ins, see Programming BPM Plug-Ins for WebLogic Integration.

Actions are not represented visually within the workflow, but are specified within a node—usually a task node, although actions can be specified in starts, decisions, events, exception handlers (see Exception Handlers), and even other actions.

Some of the actions used in the sample workflows include:

We work extensively with actions throughout this tutorial.


A variable is a container in which a workflow can store a value, whether it is text, numbers, dates, or even references to Java objects and EJBs. When you define a workflow template, you can create any number of variables. Over a workflow's lifetime, the value of any variable can change.

Typically, variables represent real-world data items that are gathered by the workflow at run time. They are populated by values that can be returned by business operations (see Defining Workflow Interfaces), extracted from XML documents, or explicitly set by workflow actions. Variables can also be used for several purposes by a workflow, such as evaluating a condition in a decision node, or storing the result of a Worklist user response to an XML message.

In the sample workflows we use variables for various functions, including the following:

We create variables throughout Creating a Workflow.

Exception Handlers

WebLogic Integration provides a system exception handler that it uses by default for all workflow instances, or running workflows. In cases where an exception occurs at run time, the system exception handler rolls back the active transaction and rethrows the exception.

You can also set up custom exception handlers for a workflow, in which you define specific actions for the exception handler to perform upon rolling back or committing the transaction.

We define and invoke an exception handler that can handle the possibility of invalid data being passed to the calculate() method of the POBean in Using a Custom Exception Handler.

Defining Workflow Interfaces

Our scenario and workflow design call for our workflow to interface with the following hypothetical and actual components and applications:

The following figure shows the various means by which a workflow interfaces with external components.

Figure 1-8 Interfacing with External Components and Applications


The following sections describe these interfaces in more detail.

Business Operations

To call a Java class or Enterprise JavaBean method from a workflow, you create a business operation. When you perform a business operation, you can pass workflow variable values as input parameters to EJB or Java object methods, which can then return values back to the workflow variables.

In the sample workflows we use business operations to:

We will define and perform a business operation in Creating a Workflow.

XML Documents

To interact, in an asynchronous fashion, with other types of server-side components such as servlets or back-end applications, a WebLogic Integration workflow shares data via XML documents that are published to JMS topics or queues and received from JMS queues.

In fact, even to exchange information between multiple workflows in an asynchronous fashion, the WebLogic Integration server uses XML documents posted to an internal topic. And although communication between the workflow and the Worklist client is accomplished via the WebLogic Integration Application Programming Interface (API), in many cases requests and responses take the form of an XML document.

Note: For information about the WebLogic Integration API, see Programming BPM Client Applications and the BEA WebLogic Integration Javadoc.

Thus, to communicate with many of the external and even internal components in our workflows, we will need to compose and send XML messages to either a Worklist client user, or an external or internal topic or queue. XML elements and attributes correspond to workflow variables for which values are provided at run time. We use outgoing XML documents in the sample workflows for the following purposes:

XML documents may be embedded within specific workflows, depending on the action that you use to reference them. However, you can also export and import them to and from the XML repository, which stores XML documents, document type definitions (DTDs), and other XML entities outside of a workflow definition, so that you can access documents created in one workflow for reuse by another. We will compose, export, and import XML documents to and from the repository in Using the XML Repository: Exporting the Neworder XML Document and Defining XPath Statements.

Event Keys

When you define a workflow event to listen for incoming XML documents, you specify the document type or root element of the document that the event is expecting. To filter incoming XML documents so that only those containing particular element or attribute values can trigger the event, you can specify an event key. The event key identifies the document type and element value that is to be extracted from the XML document via an XPath expression. The event key is stored in a table so that at run time, the server's event processor compares the value returned from the XML document with the value of a key specified by the event node; if a match is found, the event is triggered. The mechanism is explained in more detail in Creating an Event: Defining the Wait for New Inventory Event.

Examples of event keys used in our workflows include event keys for recognizing an XML message sent to:

We define event keys and XPath expressions throughout Creating a Workflow.


Working with the Sample Workflows

In the sample workflows provided for business process management, our scenario is implemented as three workflows: a main workflow, a sub-workflow, and a trigger workflow that is included for use with the tutorial. While the same scenario may be implemented, just as easily, as a single workflow, the division of the processes into two separate workflows illustrates a strategy you may want to use for structuring long and complex workflows.

The following figure shows the relationship among the three sample workflows.

Figure 1-9 Relationship Among Three Sample Workflows


Each of the workflows is described in more detail in a separate section of the tutorial; however, a high-level overview of each workflow is provided here:

Complete, ready-to-use versions of the three workflows described in this tutorial are available in the Tutorial.jar package in the SAMPLES_HOME/integration/samples/bpm_tutorial folder of your installation. This package includes the templates, template definitions, business operations, and event keys required to run the workflows.

While we encourage you to follow the procedures in this tutorial, if you simply want to run the workflows as a demonstration without following the tutorial, you will need to do the following:

  1. Log on to the Studio by following the procedure in Starting the WebLogic Integration Studio.

  2. Import the complete Tutorial.jar workflow package, and activate the workflows. Choose option 1 of step 5 in the procedure given in Importing Workflow Objects: Importing the Tutorial Package File.

  3. Follow the procedures for logging on to the Worklist and running the workflows in Executing and Monitoring the Example Workflows.


Using the Tutorial

This tutorial is organized to help you learn to use many of the common features of the Studio and Worklist applications. Each of the first four sections uses one example workflow to highlight different aspects of the Studio and workflow design, while the final section shows the completed workflows in action.

In Getting Started with the WebLogic Integration Studio, you log on to the Studio and import the Order Processing Trigger and Order Fulfillment workflows to explore various aspects of the Studio interface. Topics covered in this section include:

In Understanding Workflow Objects and Properties, you use the Order Processing Trigger workflow to explore the properties of a workflow, and to edit an XML message embedded in a workflow. Topics covered in this section are:

In Creating a Workflow, you create the Order Processing workflow from scratch by doing the following:

In Defining Workflow Nodes, you define the nodes of the Order Processing workflow by adding and defining variables, actions and other workflow objects. Topics covered in this section are:

Using a Custom Exception Handler, uses the Order Fulfillment workflow to look at the WebLogic Integration exception-handling facility and an additional Worklist user interaction.

Finally, in Executing and Monitoring the Example Workflows, you log on to the Worklist application and run the example workflows, while simultaneously monitoring them in the Studio.

Studio functions that are not demonstrated in this tutorial include:

For information about these functions, see Using the WebLogic Integration Studio.


Back to Top Previous Next