A common design pattern in business processes is one which selects one path of execution based on the evaluation of one or more conditions. You can create this pattern by designing a Decision node in your business process.
By default, a Decision node consists of one condition, a path below the condition, which represents the path of execution followed when the decision evaluates to true, and a path to the right of the condition, which represents the path of execution followed when the condition evaluates to false (the default path). A Decision node can contain additional conditions, in which case if the first condition evaluates to false, the second condition is evaluated. If the second condition evaluates to false, the next condition is evaluated, and so on. The default path is executed if no conditions are met.
Note: | To create case statements, WebLogic Integration provides a customized node, called a Switch node. To learn about using Switch nodes and how they differ from Decision nodes, see Comparing Decision Nodes and Switch Nodes in Creating Case Statements. |
This section describes how to add a Decision node to your business process, define conditions, and define activities for the alternative paths of execution in the Decision node. It contains the following topics:
The Design view is updated to contain a Decision node, as shown Figure 8-1.
Note the following characteristics of the Decision node:
At run time, when more than one condition is defined, if the first condition evaluates to false, the second condition is evaluated. If the second condition evaluates to false, the next condition is evaluated, and so on. The default path is executed if no conditions are met.
To create logic for your Decision node, you must complete the following steps:
The node builder displays different options depending on whether you select Variable or Method.
The following steps describe how to select a business process variable that is associated with an XML or MFL schema.
Note: | To learn about creating business process variables and importing schemas to your project, see Business Process Variables and Data Types. |
A drop-down list of business process variables in your project is displayed.
For example, if you imported an XML Schema (QuoteRequest.xsd
) into your project, and created a business process variable (requestXML
) of type quoteRequest
(based on the QuoteRequest.xsd
schema), the requestXML variable is available in the drop-down list of business process variables.
A representation of the XML Schema associated with that variable is displayed in the Select Expression Node field as shown in Figure 8-2.
The elements and attributes of an XML document, assigned to this variable, are represented as nodes in a hierarchical representation, as shown in the preceding figure. Note that the schema in the example (QuoteRequest.xsd
) specifies a root element (quoteRequest
), and child elements: customerName
, shipAddress
, and widgetQuoteRequests
. The widgetQuoteRequests
element, in turn, specifies a repeating element: widgetQuoteRequest
. (A repeating XML element is represented by in the GUI representation of the Schema.)
To continue with the example, supposed you selected customerName from the XML variable represented in the preceding figure. The Selected Expression field is populated with the following expression:
fn:data($requestXML/ns0:customerName)
For example, fn:data($requestXML/ns0:customerName) = “BEA”
The new condition is added to the bottom of the condition list.
Alternatively, you can edit conditions directly in the code. To do so, in the Condition builder, click View Code in the lower left-hand corner. The XQuery function that was written to the file from the design work in the condition builder is displayed at the line of code in your Process.java file; it is indicated by the @com.bea.wli.commom.XQuery
annotation.
In the Design view, note that the Condition in your Decision node displays the following icons:
Defining an XML or MFL condition produces an XQuery function that is written to your Process.java file, which you can see in the Source view. The condition defined by following the preceding example (in steps 1 through 7) creates the following XQuery function in the Process.java file:
@com.bea.wli.common.Xquery(prolog =
“ declare namespace ns0 =\http://ww.example.org./quote\”;”+
“ declare function cond_requestXML_1($requestXML) as xs:boolean {“+
“ fn:data($requestXML/customerName) = \"BEA\"”+
and“ fn:data($requestXML/customerName) = \"Avitek
\"”+
“};”)
The following steps describe how to select a business process variable that is associated with an XML or MFL schema.
The Source view is displayed at the line of code in your Process.java file at which the Java method is written.
In the Design view, note that the Condition in your Decision node displays the following icon: . It is a representation of the condition you defined in source code that specifies the Java method on which to base the decision. To make any further changes to the condition represented on this node, you must edit the source code in the Source view.
After you define the condition, you are ready to define the actions on the paths in the conditions.
This can be any node that performs an activity appropriate for your business process business logic. For example you can use a control to interact with an external resource, such as a database, a JMS queue, or an EJB.
When you complete the addition of activities on the paths of your Decision node, your decision logic is represented as a series of conditions and actions in your business process.
Figure 8-3 shows an example Decision node in the Design view.
Building on the QuoteRequest example used in building the Variable (Schema) condition, two Perform nodes are added to the paths on the Decision node. At run time, the following sequence represents the flow of control in this decision node:
“ fn:data($requestXML/customerName) = \"BEA\"”+
and“ fn:data($requestXML/customerName) = \"Avitek
\"”
Note: | The XML evaluated by the condition node is assigned to the requestXML business process variable. |
Grouping Nodes in Your Business Process
Interacting With Resources Using Controls