About Creating Workflows

 

The following sections describe key concepts for using WebLogic Process Integrator workflows in WebLogic Collaborate applications:

• Architectural Overview

• Key Concepts

• Run-Time Prerequisites

• Summary of Workflow Integration Tasks

 

---

Architectural Overview

A fundamental step in defining a conversation is creating the workflow that executes each role in the conversation. WebLogic Collaborate provides a plug-in into the WebLogic Process Integrator Studio tools that allows you to create such collaborative workflows (also known as public workflows). By using the WebLogic Collaborate software together with WebLogic Process Integrator, you have access to the following:

• A visual design tool for designing workflows (process models), which reduces the time needed to develop business collaborations

• A run-time process engine for executing workflows

• Process monitoring capabilities

Creating workflows using the BEA WebLogic Process Integrator plug-in requires a combination of design and administrative tasks, and optionally a set of programming tasks.

Architectural Components

The following figure shows how the WebLogic Process Integrator architecture incorporates the WebLogic Collaborate plug-in.

 

WebLogic Process Integrator and WebLogic Collaborate Components

The combined architecture of WebLogic Process Integrator and WebLogic Collaborate includes the following components.

Table 1-1 WebLogic Process Integrator and WebLogic Collaborate Components

Component	Description
WebLogic Process Integrator Process Engine	Run-time controller and workflow engine that executes and manages workflows and tracks workflow instances.
Workflow Instance	A running instance of a workflow template definition, which implements a role of a conversation definition that is configured in the WebLogic Collaborate repository. A workflow instance is created when a workflow template definition is instantiated at run time.
WebLogic Process Integrator Studio	Client application that is used at design time to define workflows and at run time to monitor running workflows.
WebLogic Process Integrator Worklist	Client application that is used to view and perform tasks that are currently assigned to a user or to roles to which the user belongs. Examples of such include reassigning tasks to other users, marking tasks as done, unmarking tasks done, viewing a workflow status, manually starting a workflow, and so on.
WebLogic Process Integrator Database	Database in which workflow templates and instances are stored. This database can reside locally on the trading partner node, or it can reside on a different node that is network accessible to the WebLogic Process Integrator software. The database can be deployed so that it is accessible to a single trading partner in one organization or to multiple trading partners in different organizations. WebLogic Process Integrator and WebLogic Collaborate can share the same database.
WebLogic Collaborate	Software that processes and routes messages among trading partners at run time.
WebLogic Collaborate Administration Console	Browser-based component that enables you to create, configure, administer, and monitor collaboration agreements, conversations, delivery channels, document exchanges, trading partners, and more.
WebLogic Collaborate Repository	Database that stores conversation definition information used by WebLogic Collaborate at run time, such as information about conversations, parties, conversation roles, and protocol bindings. WebLogic Process Integrator and WebLogic Collaborate can share the same database.
WebLogic Process Integrator Plug-In Framework	Component that allows a specific set of BEA products—namely, WebLogic Collaborate, WebLogic Transformation Tool, Java Application-to-Mainframe (JAM), and WebLogic Application Integration, as well as user-written plug-ins to extend the functionality of the WebLogic Process Integrator Studio.
WebLogic Collaborate Plug-In	The WebLogic Collaborate plug-in extends the Studio to allow you to specify workflow nodes, actions, events, and other details that are geared toward creating collaborative workflows—that is, workflows that implement individual roles in a conversation definition.
Other Plug-Ins	The WebLogic Process Integrator plug-in framework supports the incorporation of additional plug-ins, as explained in the preceding description of the WebLogic Process Integrator Plug-In Framework.

 

For an introduction to the WebLogic Process Integrator components, see WebLogic Process Integrator Overview in Using the BEA WebLogic Process Integrator Studio.

 

---

Key Concepts

This section describes key concepts that you need to understand before using WebLogic Process Integrator workflows in WebLogic Collaborate applications.

Workflows, Collaborative Workflows, Workflow Templates, and Workflow Template Definitions

This section describes the following key WebLogic Process Integrator concepts:

• WebLogic Process Integrator is a workflow automation tool. A workflow is a business process. Workflow automation is the automation of a business process, in whole or in part, during which information of any type is passed to the right participant at the right time according to a set of intelligent business rules that allow computers to perform most of the work while humans have to deal only with exceptions.

• In the WebLogic Collaborate environment, a collaborative workflow is a workflow that implements the role for a trading partner in a conversation definition. A conversation definition may have two or more roles, each of which is associated with a collaborative workflow.

  Collaborative workflows that implement public processes are often referred to as public workflows. Strictly speaking, a collaborative workflow is a public workflow only if the workflow has not been customized to execute private processes. However, for the sake of simplicity, the terms collaborative workflow and public workflow are considered interchangeable in this document. The WebLogic Collaborate plug-in software refers only to the term public workflows. For example, the action that you define in a parent workflow to start a collaborative workflow is called Start Public Workflow.

  For more details about public and private business processes, see Overview in Introducing BEA WebLogic Collaborate.

• In WebLogic Process Integrator, a workflow template is a folder (or a container) in the WebLogic Process Integrator Studio. This workflow template represents a workflow and is given a meaningful workflow name, such as Order Processing or Billing. The workflow template aggregates various definitions (or versions) of its implementation; these are referred to as workflow template definitions. Further, a workflow template is responsible for controlling which organizations can use the constituent workflow template definitions.

• A workflow template definition is a definition (or version) of the workflow, distinguished by its Effective and Expiry dates. At design time, you use the WebLogic Process Integrator Studio to define the properties that bind a workflow template definition to a role (such as buyer or seller) in a WebLogic Collaborate conversation. At run time, WebLogic Process Integrator starts an instance (or session) of a workflow template definition, selecting the most effective (or current and active) definition.

For detailed information about these concepts, see WebLogic Process Integrator Overview in Using the BEA WebLogic Process Integrator Studio.

Conversations and Business Messages

This section defines the following key WebLogic Collaborate concepts:

• In WebLogic Collaborate, a conversation is a series of business message exchanges between trading partners that is predefined by a collaboration agreement. The receipt of a business message by a trading partner can cause any number of back-end processes to occur.

• A business message is the basic unit of communication in a conversation between trading partners. A business message consists of one or more business documents and, optionally, attachments.

  A business document is the XML-based payload part of a business message. An XML business document is normally associated with a corresponding document definition associated with it.

  One or more attachments may also be included with the business message and may or may not be written in XML; for example, an attachment can be written in binary format.

  To construct outgoing business messages or to process incoming business messages, a workflow uses the Compose Business Message, Extract Business Message Parts, or Manipulate Business Message action, as appropriate.

For detailed information about these concepts, see Introducing BEA WebLogic Collaborate.

Initiators and Participants

A conversation involves an initiator who starts the conversation and participants who participate in the conversation once it has started. Each perspective requires a different kind of collaborative workflow.

Table 1-2 Types of Workflows

Workflow Type	Description
Conversation initiator workflow	Defined to have conversation properties and a WebLogic Process Integrator start property. This type of workflow initiates and terminates the conversation.
Conversation participant workflow	Defined to have conversation properties and a business message start property. This type of workflow can join and exit the conversation but cannot initiate or terminate it.

 

In the context of a conversation, these two types of workflows are interlocking. For example, suppose a buyer wants to obtain bids from various suppliers. The resulting conversation might proceed as shown in the following figure.

Figure 1-1 Sample Business Collaboration with Two Workflows

 

1. In the WebLogic Process Integrator Studio, the buyer (the initiating trading partner) starts a collaborative workflow instance (the business collaboration initiator workflow). This workflow constructs and sends the PriceAndAvailabilityQuote business message (containing a bid request in the form of an XML document) by way of WebLogic Collaborate to one or more qualified sellers (depending on the business protocol) and awaits a reply.

   Note: A workflow can be started in various ways; for example, programmatically or by a separate, local workflow.

2. Each qualified supplier (a participant trading partner) receives the business message, which triggers the start of an instance of a workflow (the conversation participant workflow) on that supplier's WebLogic Collaborate node.

   The collaborate workflow that implements the supplier role processes the incoming bid request, determines whether to submit a bid or not and, if it decides to submit a bid, constructs and sends the PriceAndAvailabilityResponse business message (containing a bid reply in the form of an XML document), and ends the workflow. This workflow instance has a business message start property; that is, this workflow is started when the buyer's PriceAndAvailabilityQuote business message is received at the supplier's node.

   Note: The collaborative workflow that implements the supplier role is defined with conversation properties and a Message Start property.

3. On the buyer's side, the workflow receives bid replies from all qualified suppliers, processes the results of the bid, and then terminates the conversation.

Sending and Receiving Business Messages

When trading partners exchange business messages, both initiator and participant workflows typically send and receive business messages.

It is important to keep in mind which parts of the workflow send business messages and which parts receive them. For example, a buyer might submit a bid request (a business message) to a seller. In this case, the buyer workflow is sending the business message and the seller workflow is receiving it. When the seller replies to the request with a bid (another business message), then the roles are reversed: the seller workflow is the sender and the buyer is the recipient workflow.

The design tasks differ depending on whether the workflow sends or receives business messages. However, in both cases, you must define certain properties in the workflow template definition. The WebLogic Collaborate plug-in offers two means to work with business messages:

• Workflow actions that can compose or extract information from business messages that do not require any user-written application code to manipulate the business messages themselves

• Workflow actions that invoke application code that implements the com.bea.b2b.wlpi.MessageManipulator interface to either compose or extract information from business messages, which may be appropriate in situations where complex message handling is required.

For more information, see Working with Business Messages.

 

---

Run-Time Prerequisites

Before messages can be exchanged at run time, you must make sure the following prerequisites are met:

• WebLogic Process Integrator and WebLogic Collaborate are installed and configured, as described in Administrative Tasks.

• Workflows are defined and linked to WebLogic Collaborate conversations, as described in Design Tasks.

• You have written and tested application code for manipulating messages and for starting the conversation initiator workflow, as described in Programming Tasks.

• For all trading partners, WebLogic Process Integrator is automatically loaded and running upon WebLogic Collaborate startup.

• For each trading partner, all relevant workflows are active and stored in the WebLogic Process Integrator database:

  • For an initiating trading partner, the conversation initiator workflow is active and defined with the nonbusiness message start property. It awaits the invocation of the application that starts the workflow.

  • For all participating trading partners, the conversation participant workflow is active and defined with a Business Message start property. It awaits the receipt of the initial business message in the conversation.

 

---

Summary of Workflow Integration Tasks

Using WebLogic Process Integrator workflows to exchange business messages in WebLogic Collaborate requires a combination of administrative, design, and programming tasks.

Administrative Tasks

To integrate WebLogic Process Integrator workflows, you must complete the following administrative tasks:

1. Install WebLogic Collaborate and WebLogic Process Integrator as described in the following documents:

   • Installing BEA WebLogic Collaborate

   • Installing and Configuring BEA WebLogic Process Integrator

     Note: The Samples realm in WebLogic Collaborate is preconfigured as described in Steps 2 through 4 that follow. However, if you have installed the WebLogic Process Integrator Studio client on another system, or will be deploying WebLogic Collaborate in another domain, you need to complete the procedures described in these steps.

2. Configure WebLogic Process Integrator according to the instructions in Starting, Stopping, and Customizing WebLogic Collaborate in Administering BEA WebLogic Collaborate.

   • Create the tables for the WebLogic Process Integrator database by running the appropriate SQL script for the database management system you will use.

   • Configure the JDBC connection pool for the WebLogic Process Integrator database using the WebLogic Server Administration Console. (You can start the WebLogic Server Administration Console as described in "Starting the WebLogic Server Administration Console" in Starting, Stopping, and Customizing WebLogic Collaborate in Administering BEA WebLogic Collaborate.)

   • Run the Hello Partner program to validate your installation and configuration.

     Note: We strongly recommend that you run the Hello Partner example after you install WebLogic Collaborate and WebLogic Process Integrator. By running this example, you can verify that the installation has been successful. The Hello Partner example is described in Using BEA WebLogic Collaborate Samples.

3. Modify each instance of the file fileRealm.properties in the WebLogic Integration directory hierarchy as described in the following procedure:

   1. Locate each instance of this file. The number of instances depends on the specific WebLogic Integration components you have installed and the realms that you have configured. For example, the fileRealm.properties file might exist in the following locations on a Windows system, where bea_root represents the pathname of the directory in which your BEA software is installed:

      bea_root/wlintegration2.0/collaborate/config/mydomain
      bea_root/wlintegration2.0/collaborate/config/samples
      bea_root/wlintegration2.0/collaborate/config/tempHubDomain
      bea_root/wlintegration2.0/config/integrationdomain
      bea_root/wlintegration2.0/config/mydomain
      bea_root/wlintegration2.0/config/samples

   2. Add the following lines to each instance of the file fileRealm.properties, where user represents the WebLogic Server user name for each person who will use the WebLogic Collaborate plug-in to the Studio:

      acl.access.weblogic.admin.mbean.MBeanHome=user
      acl.lookup.weblogic.admin.mbean.MBeanHome=user

      For example:

      acl.access.weblogic.admin.mbean.MBeanHome=jones
      acl.lookup.weblogic.admin.mbean.MBeanHome=jones

4. Add the file wlc.jar to the CLASSPATH for the Studio. To do this, complete the following steps:

   1. Go to the bin directory where WebLogic Process Integrator is installed.

   2. Using an editor, open the command script that starts the Studio. On Windows systems, this file is named studio.cmd. On UNIX systems, this file is named studio.sh.

   3. In the line that specifies the CLASSPATH, add the location of the file wlc.jar. This file is located in the lib directory where WebLogic Collaborate is installed.

5. Using the WebLogic Collaborate Administration Console, create and configure the necessary entities in the WebLogic Collaborate repository, including collaboration agreements, delivery channels, trading partners, document exchanges, and so on. For more information, see Administering BEA WebLogic Collaborate.

   Note: Every collaborative workflow template definition requires a conversation definition.

6. Using WebLogic Process Integrator Studio, specify the organizations, users, and roles in the WebLogic Process Integrator database, as described in Administering Data in Using the BEA WebLogic Process Integrator Studio.

Design Tasks

To integrate WebLogic Process Integrator workflows, complete the following design tasks in the WebLogic Process Integrator Studio:

1. Create and design collaborative workflows that implement each role in a conversation definition, in one of the following ways:

   • You can create workflows from scratch, as described in Defining and Maintaining Workflows in Using the BEA WebLogic Process Integrator Studio.

   • Alternatively, you can import workflows created in other versions of WebLogic Process Integrator, as described in Migrating BEA WebLogic Collaborate to Release 2.0.

2. In addition to defining the standard workflow properties, you must also define properties that link the workflow to WebLogic Collaborate, which you do via the WebLogic Collaborate plug-in to the Studio. (The remaining tasks in this procedure apply to integrating workflows into WebLogic Collaborate.)

3. For each workflow template, specify conversation properties as follows:

   • Explicitly link the workflow template to a role in a conversation definition in the WebLogic Collaborate repository, as described in Linking Templates to Conversations.

   • Optionally, specify other conversation properties, as described inDefining the Quality of Service for XOCP Message Delivery in the Workflow Template.

4. For each workflow template definition, define start actions depending on the type of workflow:

   • For conversation initiator workflows, define a nonbusiness message start property, as described in Starting a Conversation Initiator Workflow.

   • For conversation participant workflows, define a business message start property, as described in Defining the Start Node for a Conversation Participant Workflow.

5. For each workflow template definition, define how the workflow will end. To do so, add a done shape and define its properties. Conversation initiator workflows typically terminate the conversation in the Done node, as described in Defining the Termination of Conversation Initiator Workflows.

   Note that conversation participant workflows do not have a custom Done node definition.

6. Define any input or output variables used in the workflow, or in applications that interact with the workflow, in the workflow template definition, as described in About Working with WebLogic Process Integrator Variables for Workflows.

7. For each workflow template definition, define how business messages are processed:

   • For all collaborative workflows, define the WebLogic Process Integrator variables that are used to store business messages, as described in About Working with WebLogic Process Integrator Variables for Workflows.

   • For all collaborative workflows, define task nodes that manipulate business messages, either by creating business messages to send or by processing business messages that are received, as described in Working with Business Messages.

   • For workflows that send business messages, define the Send Business Message action, as described in Defining the Workflow to Send Business Messages.

   • For conversation participant workflows, define the Start node as a business message start so that the collaborative workflow is started upon receipt of the initial business message from the conversation initiator workflow, as described in Defining the Start Node for a Conversation Participant Workflow. In addition, you add an associated business message manipulation action to process the incoming business message.

   • For noninitial business messages received by conversation initiator or conversation participant workflows, define an Incoming Business Message Conversation Event, as described in Defining Business Message Receive Events. In addition, you must add an associated manipulate business message action to process the incoming business message.

8. Define how the conversation will terminate. The method of termination is protocol specific:

   • Conversation initiator workflows for XOCP-based conversations typically define a custom Done node that terminates the conversation. When an XOCP-based conversation initiator workflow sends a collaboration termination event to WebLogic Collaborate, WebLogic Collaborate sends a conversation termination event to all conversation participants.

   • RosettaNet-based workflows define their own means to terminate conversations. For more information, see Implementing RosettaNet for BEA WebLogic Collaborate.

   • Conversation participant workflows for XOCP-based conversations may optionally have an event node that listens for an end-of-conversation event, which gives the workflow an opportunity to perform any housekeeping operations before passing control to a Done node. For more information about defining an end-of-conversation listener event node in a conversation participant workflow, see Defining the End of Conversation Participant Workflows.

Note: You can run WebLogic Process Integrator workflows in the WebLogic Integration environment even if they are not integrated with WebLogic Collaborate features. For example, you can run workflows created in WebLogic Process Integrator without specifically adapting them to integrate with WebLogic Collaborate.

Programming Tasks

Programming tasks depend on the specific needs of each application that makes use of a workflow. The following tasks are required:

• For conversation initiator workflows that are not instantiated via the Start Public Workflow action defined for a parent workflow, write an application that starts the workflow. This application uses the com.bea.b2b.wlpi.WorkflowInstance class to pass information about the conversation to which the workflow is bound, such as the following:

  • Conversation definition name and version

  • Conversation role of the initiator

  • The identities of one or more parties that participate in the conversation

    This information allows the workflow to become bound to the unique collaboration agreement required for the conversation. The application can perform other tasks, such as assigning values to workflow variables, but it must, at a minimum, pass information about the conversation to which the workflow is bound. For more information, see Developing Applications that Start Conversation Initiator Workflows.

    Note: For information about starting a workflow as a subworkflow, see Defining the Start Public Workflow Action.

• For both conversation initiator workflows and conversation participant workflows that require complex message handling, write application code that implements the com.bea.b2b.wlpi.MessageManipulator interface. Using this class, applications invoked by the workflow can perform complex manipulation, extraction, receiving, and sending processes on the business messages that a workflow sends and receives. For more information, see Complex Message Manipulation.