About Creating Workflows

 

The following sections describe key concepts for using workflows in B2B integration 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. The B2B integration component provides a plug-in that allows you to create such collaborative workflows (also known as public workflows). By using the B2B integration component of WebLogic Integration together with the business process management (BPM) component, 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 B2B integration 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 Integration architecture incorporates the B2B integration plug-in.

 

WebLogic Integration Components

The WebLogic Integration architecture includes the following components to facilitate the creation and execution of collaborative workflows.

Table 1-1 WebLogic Integration Components

Component	Description
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 Integration repository. A workflow instance is created when a workflow template definition is instantiated at run time.
WebLogic Integration Studio	Client application that is used at design time to define workflows and at run time to monitor running workflows.
WebLogic Integration 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 Integration Repository	Database in which the following are stored: Workflow templates and instances. Conversation definition information used by WebLogic Integration at run time, such as information about conversations, parties, conversation roles, and protocol bindings. The repository can reside locally on the trading partner node, or it can reside on a different node that is network accessible to the WebLogic Integration software. The repository can be deployed so that it is accessible to a single trading partner in one organization or to multiple trading partners in different organizations.
B2B Engine	Software that processes and routes messages among trading partners at run time.
WebLogic Integration B2B 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 Integration Plug-In Framework	Component that allows a specific set of BEA software—namely, the B2B integration, data integration, and application integration components of WebLogic Integration, as well as the BEA Java Application-to-Mainframe (JAM) product—and user-written software to extend the functionality of the WebLogic Integration Studio and the process engine.
B2B Integration Plug-In	The B2B integration plug-in that: 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. Integrates the process engine with conversation flow.
Other Plug-Ins	The WebLogic Integration plug-in framework supports the incorporation of additional plug-ins, as explained in the preceding description of the WebLogic Integration Plug-In Framework.

 

For an introduction to the Studio, Worklist, process engine, and plug-in framework components, see Introduction to the WebLogic Integration Studio in Using the WebLogic Integration Studio.

 

---

Key Concepts

This section describes key concepts that you need to understand before using collaborative workflows in B2B integration applications.

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

This section describes the following key business process management (BPM) concepts:

• WebLogic Integration provides a workflow automation tool in the process engine. 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.

• 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. (In the Studio user interface, text that refers to the B2B integration plug-in refers only to the term public workflow. 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 B2B Integration.

• A workflow template is a folder (or a container) in the WebLogic Integration 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 Studio to define the properties that bind a workflow template definition to a role (such as buyer or seller) in a conversation. At run time, the process engine 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 Introduction to the WebLogic Integration Studio in Using the WebLogic Integration Studio.

Conversations and Business Messages

This section defines the following key B2B integration concepts:

• A conversation is a series of business message exchanges between trading partners that is predefined by a conversation definition. 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 B2B Integration.

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 nonbusiness message 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 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 the B2B engine 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 node.

   The collaborative 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 Business 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 B2B integration 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 Integration is installed and configured, as described in Administrative Tasks.

• Workflows are defined and linked to conversation definitions, 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 Integration is configured and running.

• For each trading partner, all relevant workflows are active and stored in the WebLogic Integration repository:

  • 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 collaborative workflows to exchange business messages in WebLogic Integration requires a combination of administrative, design, and programming tasks.

Administrative Tasks

To create collaborative workflows, you must complete the following administrative tasks:

1. Install WebLogic Integration as described in Installing BEA WebLogic Integration

   Note: The Samples realm in WebLogic Integration is preconfigured as described in the following step.

2. Configure WebLogic Integration according to the instructions in Starting, Stopping, and Customizing BEA WebLogic Integration.

   Note: We strongly recommend that you run the WebLogic Integration samples after you install WebLogic Integration. By running the samples, you can verify that the installation has been successful. For more information about running the sample applications, see Learning to Use BEA WebLogic Integration and Running the B2B Integration Samples.

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

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

4. Using the Studio, specify the organizations, users, and roles in the WebLogic Integration repository, as described in Administering Data in Using the WebLogic Integration Studio.

Design Tasks

To create collaborative workflows, complete the following design tasks in the 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 Workflow Templates in Using the WebLogic Integration Studio.

   • Alternatively, you can import workflows created in previous versions of WebLogic Integration, as described in Migrating to BEA WebLogic Integration Release 2.1.

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

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 Integration repository, as described in Linking Templates to Conversations.

   • Optionally, specify other conversation properties, as described in Defining 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 Using Workflow Variables.

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

   • For all collaborative workflows, define the workflow variables that are used to store business messages, as described in About Using Workflow Variables.

   • 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, 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 the intermediary (routing proxy), the intermediary 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 B2B Integration.

   • 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 workflows in the WebLogic Integration environment even if they are not integrated with B2B features. For example, you can run workflows created in the Studio without specifically adapting them to integrate with B2B functionality.

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.