Introduction to the WebLogic Integration Studio

WebLogic Integration provides a workflow management system that you use to automate business processes. A business process is a series of interconnected business activities that produce some desired result. A graphical representation of a business process is a workflow. You define and monitor workflows using the WebLogic Integration Studio, a WebLogic Integration client application.

The following sections provide an overview of Studio workflow concepts, modeling constructs, tasks, and work models:

• About Business Process Management in WebLogic Integration

• About the Studio

• Modeling Business Data

• Modeling Business Processes

• Integrating Users, Applications, and Data

• Workflow Design Approaches and Tasks

• Studio Tools

 

---

About Business Process Management in WebLogic Integration

In an e-business world, businesses must perform effectively at a rapid pace. To achieve this level of performance, many companies automate their business processes by using a business process management system: a system that defines, manages, and executes business processes using software. The order in which business activities are executed in the process is driven by a computer representation of the process called a workflow.

A workflow automates a business process by controlling the sequence of activities in the process, and by invoking the appropriate resources required by the various activities in the process. These resources might be software components that perform a required activity, or they might be people who respond to messages generated by the business process.

To achieve this level of workflow automation, a workflow management system provides support in three broad areas:

• Workflow definition and execution—capturing the definition of the workflow, managing the execution of workflow processes in an operational environment, and sequencing the various activities to be performed.

• Data administration—managing the people involved in a workflow, rerouting tasks when needed, and maintaining business calendars that govern the schedule of workflow activities.

• Workflow monitoring—tracking the status of workflow processes, and dynamically configuring the workflow at run time.

WebLogic Integration supports all three areas of workflow management: it supports the execution of workflows using its run-time process engine, and the definition and monitoring of workflows with the WebLogic Integration Studio.

An automated business process does not, however, entirely replace people with computers. People might still be involved in an automated process, either by making discretionary decisions or by handling exceptions or problems as they arise. Thus, WebLogic Integration also includes a Worklist application that end users use to view and execute manual tasks assigned to them. For more information about the Worklist application, see Using the WebLogic Integration Worklist. Alternatively, programmers can develop their own custom worklist applications by using the WebLogic Integration API. For more information, see Programming BPM Client Applications.

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.

 

---

About the Studio

The WebLogic Integration Studio is a client application with a graphical user interface that provides functionality in the three broad areas of workflow design, workflow monitoring, and data administration, as follows:

• Data administration functions

  • Modeling business units and users of the system

  • Configuring levels of permission for users

  • Rerouting tasks from one user to another for a specified period of time

  • Creating business calendars that are used to control the execution of workflows

• Workflow design functions

  • Drawing graphical process flow diagrams

  • Defining variables to store run-time data

  • Defining processes to handle run-time exceptions

  • Defining interfaces to external components

• Workflow monitoring functions

  • Displaying the status of running workflows

  • Modifying the tasks associated with running workflows, such as by reassigning tasks or by forcing work to be redone

  • Displaying the workload status of the system in graphical form

  • Viewing historical data for workflows to identify bottlenecks and inefficiencies

  • Viewing user or role worklists to maintain workflows dynamically

 

---

Modeling Business Data

In the WebLogic Integration Studio, organizational data is subdivided into three categories:

• Organization—an entire company; a division, region, or location within a company; or any other distinction that is relevant to the particular business of a company.

• Role—a common area of responsibility, ability, or authorization level that is shared by a group of individuals who belong to a particular organization.

• User—an individual assigned to a role who has the necessary permission to perform a particular task in the workflow, such as responding to messages generated by a workflow.

Roles allow groups of users to execute manual tasks according to a generic business role within the organization. Roles are defined uniquely within organizations. This allows you to divide your organization into organizational units, and to re-use role names that can have different groups of users attached to them.

Although roles are defined uniquely within organizations, users can belong to one or more organizations, and to one or more roles with those organizations, as the following figure illustrates.

Figure 1-1 Relationship Between Organizations, Users, and Roles

 

In this example, there are two organizations, Engineering and Support Services, each containing their own roles of Engineer, QA Tester, and Manager. The relationships depicted are summarized in the following table:

Table 1-1 Organizations, Roles and Users

Organization	Role	Members
Engineering	Engineer	Tim, Gary
	QA Tester	Ellen
	Manager	Barbara
Support Services	Engineer	Gary
	QA Tester	Ellen, Kim
	Manager	Fran

 

The other business data you can model are business rules, such as schedules and workflow routings. You model working hours and schedules with business calendars that can be associated with organizations, roles, and users. You can also create routing specifications that redirect activities to different users or roles for specified periods of time.

 

---

Modeling Business Processes

In the Studio, business processes are modelled, diagrammed, and saved as workflow templates in a database. These templates can be associated with multiple organizations, and are essentially empty containers for storing different workflow versions. Templates contain template definitions, which serve as different versions of the same workflow, and are distinguished by effective and expiry dates that determine a range of time in which each version may be available for instantiation, that is, placement in the run-time environment.

The template definition is where you represent the business processes you wish to model, by drawing and connecting shapes that make up the flow. Program control is represented visually by nodes and connections, as shown in the following figure.

Figure 1-2 Studio Workflow Template Definition: Design Area

 

In addition, template definitions contain actions and exception handlers that execute different activities at run time and variables that collect, store, and distribute run-time data. Template definition components are discussed in more detail in the following sections.

Nodes

Nodes are geometric shapes that you use to depict a workflow graphically. The Studio provides the following seven nodes:

• Start — represents the beginning of a workflow.

• Task — represents a user-assigned task or a grouping of actions (see Actions) that form a unit of work.

• Event — represents a wait state that can be triggered by the receipt of an XML message. When the event is triggered, the flow proceeds.

• AND Join — represents a merge of multiple workflow paths into a single path such that all the workflow paths linked by the join node must have completed before the flow proceeds.

• OR join — represents a merge of multiple workflow paths into a single path such that only one of the workflow paths linked by the join node must have completed before the flow proceeds.

• Decision — represents a condition (specified in the node) that must be evaluated to either true or false. The result of the evaluation determines the path the workflow follows.

• Done — represents the end of a workflow.

Actions

Actions are, in a sense, the basic building blocks of a workflow because they define the actual behavior of the workflow. An action can be as simple as assigning a task to a user or as complicated as sending XML messages or invoking Enterprise JavaBean (EJB) methods. Actions may be added to all nodes (except Joins), to exception handlers, and even to other actions.

There are several types of actions:

• Task actions — used to assign manual tasks to users and roles, and to control the execution of Task nodes.

• Workflow actions — used to manage an entire workflow, such as stopping the current workflow or starting a sub-workflow.

• Integration actions — used to integrate the workflow with external software components or applications. This can be done by, for example, calling an executable program or sending an XML message to another application. The operations that are carried out by integration actions are discussed in more detail in Integrating Users, Applications, and Data.

• Exception handling actions — used to invoke and exit an exception handler, and to make an exception handler the active one for a workflow.

• Miscellaneous actions — used to perform additional actions, such as sending e-mail, making an audit entry, or canceling a workflow event.

• Custom actions (plug-ins) — actions that are programmed for the WebLogic Integration plug-in framework, and that you access from the Studio. For more information about the plug-in framework, see Programming BPM Plug-Ins for WebLogic Integration.

Variables

Variables hold run-time values and data obtained usually from outside sources, such as Java components and incoming XML documents. They can also be set to constant values by workflow actions. Variables can be used by the workflow for several purposes, such as evaluating a condition in a decision node, creating a label for a template definition, or holding workflow run-time information.

WebLogic Integration supports the following types of variables: Boolean, Date, Double, Entity EJB, Integer, Java Object, Session EJB, String, and XML. Data types can be extended through the use of plug-in types developed for the plug-in framework.

Exception Handlers

Exception handlers are used to generate, trap, and respond to exception conditions that are generated internally or externally. Exceptions can be abnormal conditions that you identify at design time in the workflow that you want to trap, or they can be server exceptions that you trap and respond to accordingly. Workflows can contain custom-defined exception handlers consisting of a series of actions that you specify.

 

---

Integrating Users, Applications, and Data

As the design tool for WebLogic Integration, the Studio goes beyond business process management, and helps to integrate all human and automated operations in the e-business cycle. The Studio provides actions for integrating Web-based and back-end applications, interacting with clients inside and outside of the firewall, and transforming data. For more information about the B2B integration, application integration, and data integration plug-in functionality for BPM, see the following documents:

• Using Application Integration

• Creating Workflows for B2B Integration

• Using the Data Integration Plug-In

The following sections describe some of the integration scenarios offered by basic Studio actions, and the means by which workflows interface with external components, via XML messaging, business operations, and custom-developed plug-ins.

Integrating Users and Client Applications

Workflows interact with system users via the Worklist or a custom client application using the following methods:

• Directly through the Worklist or custom client

• Internal XML/JMS messaging with the Worklist or a custom client application to perform additional operations, such as displaying forms

• E-mail.

Workflows can also interact with users outside the system by e-mail.

The following figure shows the various interactions that be achieved between workflows and client applications and users. Each scenario is described below the figure.

Figure 1-3 Integrating Users and Client Applications

 

1. The workflow is initiated by a Worklist user.

2. Assigning a task to a user sends a notification to a Worklist user to perform a task.

3. Sending XML to client sends an XML message to the Worklist application, instructing it to display a message prompt or form, or call an executable program or custom component on the client. XML messages are sent in response from the Worklist application back to the workflow.

4. Sending e-mail allows the process engine to send e-mail to Worklist users and clients outside the WebLogic Integration system.

Integrating External Components and Applications

Workflows can integrate the following kinds of external software components:

• External systems, including Web components, such as Java Server Pages (JSPs) and servlets

• Enterprise information systems, such as legacy systems, packaged enterprise applications

• Database management systems (DBMSs)

Workflows can then exchange data with these external components using the following methods:

• XML/JMS messaging

• Workflow business operations that represent with EJB or Java class methods.

• Plug-in components consisting of Java classes and EJBs using the plug-in framework

The following figure shows the different means by which workflows can interface with external components. Each scenario is described below the figure.

Figure 1-4 Integrating External Components and Applications

 

1. The workflow is triggered, and data obtained, by the receipt of an XML message on an internal JMS queue from a sending application.

2. Performing a business operation invokes pre-existing Java components or components written specifically for the workflow application, and passes parameters directly from the workflow to the component and back again.

3. Calling a program starts an executable program on the server.

4. An event is triggered, and data obtained, while the workflow is in progress, by the receipt of an XML message on an internal JMS queue from a sending application.

5. Posting an XML message to an external JMS topic or queue sends notification and data to an external application that subscribes to the topic or receives messages from the queue.

6. Performing a plug-in action invokes custom Java code written to integrate other applications or systems.

Integrating Workflows

Workflows can communicate with each other in the following ways:

• By calling each other directly

• Via XML/JMS messaging

The following figure shows the various interactions between workflows. Each scenario is described below the figure.

Figure 1-5 Integrating Workflows

 

1. The workflow is triggered, and data obtained, by the receipt of an XML message on an internal JMS queue from another, sending workflow.

2. The workflow is set up with a called start, and is initiated directly by another workflow, which passes parameters to and from it directly.

3. Posting an XML message to an internal JMS queue sends notification and data to another workflow, triggering its start, or an event within it. (same as 1)

4. An event is triggered, and data obtained, while the workflow is in progress, by the receipt of an XML message on an internal JMS queue from another, sending workflow. (same as 1)

5. Starting a workflow initiates a called workflow and passes parameters to and from it directly. (same as 2)

Integrating Data

In addition to exchanging XML messages, workflows can transform XML documents from one format to another, to be passed out to external applications.

Figure 1-6 Integrating Data

 

In this scenario, the workflow uses an Extensible Stylesheet Language (XSL) template to transform the structure of one XML document into another.

 

---

Workflow Design Approaches and Tasks

Theories of system design suggest that, ideally, systems should be designed using a top-down approach. In reality, systems are designed from both the top down and the bottom up. Both approaches are also used for designing WebLogic Integration workflows, as the following figure shows.

Figure 1-7 Designing Workflows

 

The top-down approach is the one that has been adopted as the organizing principle of this document. However, both top-down and bottom-down approaches are not only valid, but necessary, and you are likely to adopt both in practice. The application of both approaches to specific Studio design tasks and phases is discussed in the following sections.

Top-Down Approach

The Studio graphical user interface favors a top-down approach in which most external component elements have already been developed. In this approach, the workflow definition process involves moving from mapping out a high-level graphical representation of the basic activities and logic that the application fulfills, to drilling down to deeper levels of detailed specifications.

This work model is illustrated in the following flowchart, which summarizes the main tasks you perform when modeling, designing, defining, and testing WebLogic Integration workflows in the Studio. In fact, this is the model that is followed by the structure in this document, and each numbered step, starting with step 3, corresponds to a topic in this document. The figure is explained in detail below. Note that the iterative, circular nature of the design process is not actually represented by loops in the flowchart, for the sake of graphic simplicity.

Figure 1-8 Studio Design Work Model: Top-Down Approach

 

1. The business analysis phase includes identifying your application and data requirements, taking stock of existing components and applications you want to integrate, defining a data model that captures the business rules and structure of your organization, and perhaps even beginning to model a workflow in a third-party design tool. For more information on this phase, see Designing BEA WebLogic Integration Solutions.

2. The resource development phase includes developing Java components such as EJBs and custom Java classes, XML documents and style sheets to be used in outgoing messages from workflows or incoming messages from connecting applications or components, and plug-in components. For more information on this phase, see Designing BEA WebLogic Integration Solutions.

3. In the pre-design phase, you use the Studio to configure business data. The tasks in this phase are discussed in Administering Data. It is assumed that you will only need to perform these tasks once initially, and occasionally when your business rules or personnel change.

4. At this point, you can begin to set up any external resources you have created in step 2, to make them globally accessible to your workflows. The tasks in this phase are discussed in Configuring Workflow Resources. You will likely perform these steps both before and during the design phase, in an iterative fashion, as the particular requirements of your workflows become clearer.

5. You begin the actual design phase by setting up workflow templates and template definitions. You then define a high-level process flow, by adding and connecting nodes to the workflow diagram, creating variables, and defining node properties. These tasks are described in Defining Workflow Templates, and will require some use of workflow expressions, which are discussed in step 8.

6. Once you have created nodes, you begin to add and define actions, as described in Defining Actions. At this stage, you probably need to further configure resources as described in step 4, and flows, node definitions, and variables, as in step 5. Defining actions also involves the tasks described in steps 7, 8, and 9.

7. While defining actions, you may need to import XML documents you have created and configured in steps 2 and 3, or you may need to compose the XML content from within workflow actions. These tasks are described in Working with XML Entities.

8. Throughout the workflow design process, you need to provide data formatted in the workflow expression language, which can contain literals, constants, variables, and built-in functions that supply run-time data. The semantics and syntax of workflow expressions are discussed in Using Workflow Expressions.

9. To add custom exception handlers to the template definition, you define sub-flows of actions to be performed upon the occurrence of run-time exceptions and a method of exiting the exception handler and returning to the main program flow. These tasks are described in Handling Workflow Exceptions. Once you have defined exception handlers, you once again need to add actions to nodes to reference them, as described in step 6.

10. At this point, you can run the workflow and test it. The Studio offers several monitoring features that allow you to view running workflow instances to help identify design errors, and that are described in Monitoring Workflows. Once you identify potential design bugs, you need to repeat the steps in the design process described so far; for example, to re-place actions, re-formulate expressions, and so on.

11. In the post-execution phase, when your workflow has been thoroughly tested and is running correctly, you can export workflows and any resources you have created and configured to Java archive packages for reuse. You can then re-import exported packages to begin the entire process cycle again. Import and export tasks are described in Importing and Exporting Workflow Packages.

Bottom-Up Approach

The bottom-up approach to design tasks in the Studio involves creating a catalog of reusable, exportable design patterns consisting of variables, actions, nodes, and groups of nodes that can be copied or imported into template definitions and incorporated into flows. This approach still requires that you have undertaken the preliminary tasks of analyzing your application needs and developing required resources. However, rather than beginning by outlining a high-level program flow, you begin by mapping the available Studio actions to the common operations that your workflow(s) need to accomplish, and defining the details of those actions. A suggested work model that follows this approach includes these steps:

1. Define any global entities that need to be referenced by actions. This includes business calendars (see Administering Business Calendars) and business operations (see Configuring Business Operations).

2. Create or import a workflow template and template definition. These tasks are described in Working with Templates and Working with Template Definitions.

3. Add and define node archetypes that perform common activities for your workflows. A description of these types, and the actions that comprise them is provided in Understanding Actions.

4. Identify the workflow functions and other expression components that you may need to use to take advantage of features such as addressed messaging, event-triggered processing, communication between workflows, and so on. A description of functions is provided in Using Functions in Using Workflow Expressions.

5. Define common variables that actions need to reference, such as instance variables for business operations, XML variables to contain XML documents, input and output variables for called workflows, and so on. Variable definition tasks are described in Working with Variables.

6. Define all the low-level details for the actions contained in these node types, such as expressions, parameters for business operations, JMS messaging options for actions that post XML events, XML document content for actions that embed XML documents, and so on. For actions that reference users, roles or organizations, you can even use the default users as placeholders, until you have defined the entities that represent your business requirements.

7. Define specific node properties for Start, Event, and Task nodes. These tasks are discussed in Defining Node Properties.

8. Set up exception handlers and their actions.

9. Copy the components you have created into new workflow templates (described in Copying Nodes), or export the template definitions to Java archive files for re-import into new templates.

10. Arrange the predefined nodes into a flow and define high-level organizational data relevant for the new template definitions.

 

---

Studio Tools

In addition to the graphical drawing engine you use to design process flows, the Studio also provides the following tools to help you manage external resources and define workflow properties:

• XML Finder

  The XML Finder is a file and content management tool that allows you to access and organize different types of XML content, including Schemas, document type definitions, message formats, and so on, that may be stored in a database table or in files. The XML Finder is described in Managing Entities in the Repository and Using the XML Finder to Retrieve and Export XML Entities.

• XML editor

  Many Studio actions allow you to compose, import and export XML documents from within workflows. These actions contain an XML editor that you can use to compose XML document templates from scratch, edit existing documents, and validate content according to XML Schemas. XML editing features are described in Working with XML Entities.

• Expression Builder

  Many Studio dialog boxes require that you enter data in workflow expression syntax. The Expression Builder is an editing tool that allows you to select from a catalogue of operators, literals, workflow functions, and variables you have created, to construct expressions component by component. When you have finished building an expression, the Expression Builder validates the syntax and informs you of any errors. The Expression Builder is described in Using the Expression Builder.

• XPath Wizard

  To extract content from incoming XML documents, you use XPath functions to locate the target data in XML elements and attributes. The XPath Wizard is a point-and-click tool that allows you to automatically generate XPath expressions from selected content in sample XML documents or Schema or DTD-generated XML, without the need to master the syntax of the XPath language. The XPath Wizard is described in Creating XPath Expressions Using the XPath Wizard.

• Import/Export wizard

  The Import/Export wizard allows you to export all workflow templates, template definitions and associated resources, such as business operations, event keys, plug-ins, and XML entities, that have been defined in the system. Workflow objects are exported to a Java archive file and can be re-imported to any system running the Studio. The Import/Export wizard is discussed in Importing and Exporting Workflow Packages.