> Tutorial: Building Your First Business Process > Step 3: Define Conditions for Alternate Paths of Execution

Tutorial: Building Your First Business Process

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Step 3: Define Conditions for Alternate Paths of Execution

This step describes how you design a common pattern in business processes—one that selects one path of execution based on the evaluation of one or more conditions. You create this pattern by designing a Decision node in your business process.

In this part of the tutorial scenario, the business process is designed to make a decision based on a value that the business process extracts from the variable to which the XML message from the client is assigned. You design a single condition, which is evaluated at run time to determine whether the shipping address, specified in the incoming Request for Quote xml, requires that sales tax is calculated for the quote. If the condition evaluates to true, then sales tax must be calculated and the flow of execution proceeds along a branch that calls a Web service to calculate the sales tax. If the condition evaluates to false, then no sales tax is required for the quote and the flow of execution proceeds along the default branch. This step includes the following tasks:

To Add A Decision Node To Your Business Process
  1. If the Node Palette is not visible in BEA Workshop, choose WindowArrow symbolShow ViewArrow symbolNode PaletteArrow symbolfrom the BEA Workshop menu. From the Select Perspective dialog box, select Process. The Node Palette is now visible.
  2. Click Decision in the Node Palette, then drag and drop the Decision node onto the business process, positioning it directly below the Client Requests Quote node that you created in Step 2: Specify How the Process is Started.
    3. Note: As you drag a node from the Node Palette onto the Design view, targets appear on your business process. As you drag the node near a target location, the target is activated  and the cursor changes to an arrow . When this happens, you can release the mouse button and the node snaps to the business process at the location indicated by the active target.

    The Decision node includes a node representing the condition (labeled Condition) and two paths of execution: one for events to be executed in the case the condition evaluates to true and the other (the Default path) for events to be executed in the case the condition evaluates to false.

  3. Relabel Decision, Condition, and Default to identify the business tasks for this node more clearly:
    1. In the node's Name box, replace Decision, with Sales Tax Calculation Needed?, then press Enter.
      2. Note: If the Name box is not open, double-click Decision to open it.
    2. To enter a label to replace Condition and identify the true path, double-click Condition and enter Yes, then press Enter.
    3. To enter a label to replace Default and identify the false path, double-click Default and enter No, then press Enter.

      4. The Decision node in your business process should now appear in the Design view as shown in the following figure.



To Define a Condition in This Decision Node
  1. Double-click the condition node to invoke the decision builder. It provides a task-driven user interface that helps you design the decision logic.



    2. In the decision builder, Variable is selected by default. Do not change the selection because, in this case, you design the decision based on the value of an element in an XML document, which is valid against an XML Schema.

  2. Select an XML element on which the decision is made. To do so, complete the following steps:
    1. In the decision builder, select a variable by clicking the for the Left Hand Expression.

      2. A drop-down list of variables in your project is displayed. In this case, the variable you created for the Client Request node at the start of your business process is displayed: requestXML.

      A representation of the XML schema for the QuoteRequest is displayed in the Select Expression Node pane:



      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. The schema in our example (QuoteRequest.xsd) specifies a root element (quoteRequest), and child elements: customerName, shipAddress, and a repeating element (identified by ): widgetRequest. The shipAddress element contains the following attributes: street, city, state, zip.

    2. In the Select Expression Node panel, expand ShipAddress and click the state attribute.

      3. This selects the node in the XML document that represents the element for which you want to define the condition.

      The Selected Expression field is populated with the following expression:

      fn:data($requestXML/ns0:shipAddress/@state)

    3. Click Select.

      4. The Left Hand Expression field is populated with expression.

    4. Select the = operator from the Operator list.
    5. Enter "CA" in the Right Hand Expression field.
    6. Click Add to add the condition you just created:
      7. fn:data($requestXML/ns0:shipAddress/@state) = "CA"

      This completes the design of the first condition on this node.

    7. Select the expression in the condition list pane, as shown in the following figure:



    8. Change the Join Type option to OR.
    9. In the Right Hand Expression field, select "CA", then change the entry to "California".
    10. The Add button changes to Update.
    11. Select the arrow beside the Update button, scroll-down then select Add from the menu.
    12. Repeat the process of selecting the expression and then adding it to the condition list changing the entry in the Right Hand Expression field to NJ and New Jersey consecutively.

      13. The conditions you specify are listed in the condition list pane, as shown in the following figure.



  3. Click Close to close the decision builder.

    4. The icon for the Condition node in the Design view has changed from to . It is a visual reminder that the condition you defined on this node is based on the evaluation of XML.

    This step completes the design of the condition that is evaluated when the flow transitions to the Decision node at run time. Your condition logic is written in source code as an XQuery expression—see the following section: XML Conditions in the Source Code.

    You are ready to define the actions on the subsequent paths in the flow—proceed to
    Step 4: Invoke a Web Service.

XML Conditions in the Source Code

As you define your XML conditions in the decision builder, BEA Workshop writes an XQuery expression to the JPD file. Specifically, XQuery expressions are written in the Process Language region of the JPD file.

To view the XQuery expression written in keeping with your work in the preceding section, click the Source tab.

The condition defined by following the example in steps 2 through 9 in the preceding section creates the following XQuery expression in the source code: 

@com.bea.wli.common.XQuery(prolog=
	"declare namespace ns0=\"http://www.example.org/request\";" +
	"declare function cond_requestXML_1($requestXML as element()) as  		     xs:boolean  {" +
         " (((data($requestXML/ns0:shipAddress/@state) = \"CA\") or              (data($requestXML/ns0:shipAddress/@state) = \"California\"))               or (data($requestXML/ns0:shipAddress/@state) = \"NJ\")) or       (data($requestXML/ns0:shipAddress/@state) = \"New Jersey\")" + "};" +        "declare function get_requestXML1($requestXML as element())                as element()* { " +
               "$requestXML/ns0:widgetRequest" +
"};",

Related Topics

Defining Conditions for Branching


  Back to Top       Previous  Next