Working with Workflow Components


	Corporate Info \| News \| Solutions \| Products \| Partners \| Services \| Events \| Download \| How To Buy
	http://www.oracle.com/technology/documentation/index.html \| Search \| PDF Files \| Contact

WebLogic Process Integrator Doc Home \| Studio Guide \| Previous Topic \| Next Topic \| Contents \| Index

The following sections describe how to use workflow components:

Adding Workflow Components to a Workflow Diagram

After you first create a workflow template definition, the workflow toolbar and workflow drawing area are displayed on the right side of the WebLogic Process Integrator Studio main window.

By default, the drawing area already contains three shapes (components) that you must define: start, task, and done. If you will be adding a shape to an existing workflow diagram, right-click the workflow template definition in the folder tree and choose Open from the pop-up menu to open the workflow diagram.

Add new shapes to the diagram by clicking the shape in the toolbar, then clicking in the workflow diagram where you want to drop the shape. To identify icons to the toolbar, see Workflow Drawing Area in WebLogic Process Integrator Overview.

Deleting Components from a Workflow Diagram

Delete a component from a workflow diagram in one of two ways:

Select the shape in the drawing area, right-click, and choose Delete from the pop-up menu.
In the folder tree, right click the Start node and choose Delete from the pop-up menu.

A confirmation dialog box is always presented.

Defining Variables

Not all workflow template definitions require variables. However, for those workflow template definitions containing processes that require variables, you should define these before you begin defining the workflow template definition. You can also add these variables as you create the workflow template definition.

Process variables have a workflow-global scope. That is, a single variable instance is shared by all objects within a workflow template definition instance. Process variables are therefore defined at the workflow template definition level in the folder tree and are referred to as workflow variables.

Each workflow template definition can have a set of variables associated with it. A variable is typically used to store application-specific information required by the workflow at run time. Variables are created and assigned values largely to "control" the logical path through a workflow instance; the same workflow template definition is instantiated multiple times and can be traversed in different ways if the flow contains decision nodes, which test workflow variable values to branch to either the next True or next False within the workflow.

Defining Variables

To define a variable:

In the folder tree, right-click Variables under the appropriate workflow template definition, and choose New Variable to display the Variable Properties dialog box.
Figure 4-1 Variable Properties Dialog Box
Complete the following fields:

Updating Variables

To update an existing variable:

Right-click an existing variable in the folder tree and choose Properties from the pop-up menu. The Variable Properties dialog box is displayed.
Make changes to the variable as needed, and click OK.

Locating Variables in the Workflow

To see where a variable is used within the workflow, right-click the variable in the folder tree and choose Usage from the pop-up menu. This displays the Variable Usage dialog box.

Figure 4-2 Variable Usage Dialog Box

The Variable Usage dialog box lists the nodes within a workflow template definition in which the selected variable is used and the value assigned to that variable. Variables can be used in all workflow nodes except joins and dones.

In the preceding figure, the Confirm variable is used in the Confirm Order task and has a value of :Confirm="yes".

The dialog box contains the following buttons:

Update — updates the selected action. Opens the action dialog box to allow the variable expression to be edited.
Delete — deletes the selected action.
OK — closes the Variable Usage dialog box.

Variable Conversion Rules

The following table details the implicit conversions that are handled automatically by WebLogic Process Integrator between different variable types.

Table 4-1 Variable Conversions

Value Converted To	String	Integer	Double	Date	Boolean	XML	NodeList 1
String	X 2	X 3	X 4	X 5	X 6	X 7	X 8
Integer	X 9	X 10	X 11	NS	X 12	NS	X 13
Double	X 14	X 15	X 16	NS	X 17	NS	X 18
Date	NS	NS	NS	X 19	NS	NS	NS
Boolean	X 20	X 21	X 22	NS	X 23	NS	X 24
XML	X 25	NS	NS	NS	NS	X 26	X 27

Note: NS means Not Supported.

The following are notes relating to certain conversions in the preceding table:

org.w3c.dom.NodeList, which is typically the output of Xpath() function. The Xpath() function also returns Double, Boolean, String, and Integer types.
As it is.
Java Integer.toString() output.
Java Double.toString() output.
Java Date.toString() output.
Java Boolean.toString() output: "true" and "false".
DOM serializing.
DOM serializing.
An ILLEGAL_CONVERSION warning WorkflowException is thrown if parsing cannot occur (NumberFormatException).
As it is.
Double's Integer value.
1 if true, 0 if false.
DOM serialized to string, then convert to Integer. (See note 9.)
An ILLEGAL_CONVERSION warning WorkflowException is thrown if parsing cannot occur (NumberFormatException).
Integer's Double value.
As it is.
1.0 if true, 0 if false.
DOM serialized to string, then convert to Double. (See note 14.)
As it is.
True if string value is "true", "t", "1"; false if string value is "false", "f", "0". Any other string value throws an ILLEGAL_CONVERSION warning WorkflowException.
False if Integer value is 0, true if any other value.
False if Double value is 0, true if any other value.
As it is.
DOM serialized to string, then convert to Boolean. (See note 20.)
DOM parsing to a XML document element (not simply a node, which means when it is dumped back to a String, it will have XML header similar to the following: <?xml version="1.0" encoding="UTF-8"?>). An ILLEGAL_CONVERSION warning WorkflowException is thrown if DOM parsing cannot occur.
As it is.
DOM serialized to string, then convert to XML node. (See note 25.)

Defining Start

Every workflow has at least one start shape that indicates the beginning of the workflow. The first node after the start will be the first activated node of the workflow, which can be a task, decision, or event.

Specifying Multiple Starts

You can specify more than one start shape, if more than one simultaneous path through the workflow is to be started. For example, when you want two streams of work to start at the same time within a single workflow, you can define two starts within the workflow.

These two streams of work can be started at simultaneously, if they have the same triggering event and are both marked as manual starts or timed starts set to the same time. Otherwise, the two streams can be started separately with each start being an alternate way of starting the workflow.

The benefit to the ability to specify more than one start is visual access to both streams of work within the same workflow and these streams of work can share the same variables. You have the flexibility to take a portion of a workflow and starting it in a different manner or at a different time within the workflow.

Note: If no Start shape is specified, then no task activation can occur in the workflow.

You specify the triggering properties of a workflow in the start node. If a workflow contains multiple starts, each start can have its own triggering method and start independently.

Defining a Start Node

To define a Start shape:

Display or add the Start shape as described in Adding Workflow Components to a Workflow Diagram.
Double-click the Start shape to display the Start Properties dialog box.
Figure 4-3 Start Properties Dialog Box
The Description field by default contains the name Start. Modify this name as needed to create a unique, identifiable name.
Select a workflow triggering method:
Complete or view the fields on the tabs:

Defining Dones

A done shape represents the point within the workflow where the process completes. Once a done node is reached in the workflow, the running instance of the workflow is marked done, regardless of whether all the done nodes have been reached or not.

You can specify any number of done shapes in a workflow. If a workflow can exit from various points, you have the option of placing separate done nodes wherever needed.

To define a done:

Add or view a done shape as described in Adding Workflow Components to a Workflow Diagram.
Double-click the done shape or right-click it in the folder tree and choose Properties to display the Done Properties dialog box.
Figure 4-7 Done Properties Dialog Box
Complete or view the fields:
- Actions — displays the list of all actions to be performed when the Done node is reached. Click Add to display the list of available actions. Refer to Using Actions, for further details on selecting actions.
- Notes — a free form text field for recording notes about the done.

Defining Decisions

The workflow can use any number of decision shapes. Each decision shape contains a condition that is evaluated when a transition to that decision node occurs. The result is either True or False, with subsequent flow of control passed to the subsequent task, decision, event, and join or done node(s). Additionally, it is possible to specify actions to be executed on both a True and a False evaluation of the condition. (If the condition is verified, it is True. If it is not, it is False.)

To define a decision:

Add or view a Decision shape as described in Adding Workflow Components to a Workflow Diagram.
Double-click the Decision shape or right-click it in the folder tree and choose Properties to display the Decision Properties dialog box.
Figure 4-8 Decision Properties Dialog Box
Complete the following fields:
- Condition — specify the conditional expression to evaluate at run time. When the decision is activated in a running workflow (that is, a transition is made to the decision shape), this conditional expression is evaluated.
  Note: Expressions are built using WebLogic Process Integrator expression syntax and typically use the syntax of XPath function to extract values out of XML documents. If you know the syntax of the expression you want to use, you can type the expression directly in the field. Alternatively, click the A+B button to display the Expression Builder dialog box. The Expression Builder helps you construct an expression, which is made up of functions, operators, literals, and variables. For more information on constructing expressions, see Using Expressions and Conditions.
- Actions — a tabbed display showing the list of actions to be executed if the specified condition is evaluated and the result is either False or True. The tab that appears foremost indicates which of the two lists (False or True) is currently displayed. See Using Actions, for a description of how to specify actions.
  False — actions defined in this tab are executed if the condition evaluates to false (is not verified).
  
  True — actions defined in this tab are executed if the condition evaluates to true (is verified).
Provide or view information in the tabs of the Properties section of the dialog box.

Defining Tasks

A workflow contains a series of tasks, each of which represents a discrete activity to be performed automatically by the WebLogic Process Integrator server or by a workflow user. The task behavior is determined by various task properties and by the task actions that define the processing to be performed as certain task events occur.

To define a task:

Display or add a task as described in Adding Workflow Components to a Workflow Diagram.
Double-click the task shape or right-click the task in the folder tree and choose Properties to display the Task Properties dialog box.
Figure 4-9 Task Properties Dialog Box
Complete the following fields:
- Task Name — enter a meaningful name, such as ConfirmOrder. This value is used primarily in the worklist, but it is visible from the various WebLogic Process Integrator monitoring reports. The system automatically assigns a unique temporary name to new tasks (in the form of Task n, where n is a number).
- Priority — select Low, Medium, or High priority. This field is displayed in the worklist and can be used to sort the worklist by priority. The initial default value is Medium.
- Actions — tabbed display of four separate lists of actions for the task, corresponding to the task events. See Using Actions, for a description of how to specify actions. A task responds to an event at run time by executing the associated actions; actions defined within these task events are guaranteed to occur in sequence. The four task events are as follows:
  Created — the workflow is started and all tasks in the workflow are created.
  
  Activated — the workflow diagram indicates a task transition has occurred, usually as a result of another task being marked as done or a decision being evaluated. The task is available to be performed.
  
  Executed — an event has occurred that causes this task to be executed. This usually occurs when a user selects a task in the worklist and executes it, often by double-clicking the task, or when an Execute Task action is performed for that task.
  
  Marked Done — the task has been completed. This event occurs usually in response to the execution of a Mark Task as Done action.
  
  To display the list of actions for a different event, select the appropriate tab.
View or provide information on the following tabs:

Defining Events

A workflow event shape represents a notification node. The workflow waits for an XML message to trigger the event. Upon that trigger, actions defined within the event can be executed and/or workflow variables can be set.

To define an event:

Using Joins (And/Or)

The possibility of multiple paths being active in the same workflow gives rise to the issue of path joining. There are two types of joining: AND joining and OR joining.

How Joins Work

AND joining melds multiple separate paths of control back into a single path, synchronizing them such that control does not continue until all paths converge. This type of join derives its name from the fact that control continues when the AND of all inputs is true. That is, when Path 1 and Path 2 and Path 3 ... etc. are all present, then control proceeds. An AND join will reset itself immediately after it is activated, in order to allow a looping process.

OR joining allows multiple path threads to enter and traverse down the same line of control within the workflow. In this case, the threads do not meld; the nodes along this part of the flow are executed multiple times, once for each thread control passing through it. This type of joining derives its name from the fact that control passes to the next node when the OR of its inputs is true. That is, if Path 1 or Path 2 or Path 3 ... etc. is present, then control proceeds.

An OR join can only be activated once. This avoids the multiple occurrence of actions and events succeeding the OR, which can happen by the completion of the various predecessors of the join. However, this single activation prevents a flow from looping when an OR join is defined, as the flow stops the second time at the OR join.

Use AND and OR joins to link task, decision, and event shapes and thus control the transition coming to the join and flowing from it.

Defining a Join

To define a join:

Display or add a join as described in Adding Workflow Components to a Workflow Diagram.
Double-click the join shape or right-click it in the folder tree and choose Properties to display the Join Properties dialog box.
Figure 4-11 Join Properties Dialog Box
Complete or view the fields as follows: