Shapes from a Business Analyst Perspective

It is the responsibility of the business analysts to implement the business process flow. To do so analysts will work with the following shapes:

■ Begin This shape is available on all pages that can hold a process flow; it is not available on the Flowchart stencil and cannot be deleted from the page. It is used to assure that there is only one point where a flow begins. In fact, a flow is regarded complete if it starts with a Begin and finishes with at least one End. If you do just this and compile the flow, you will create an "empty" XLANG schedule.

■ Action This shape always needs to be bound to a port in order to receive or send a message. Since a schedule has to receive a message/document first before it can process it and send a message, the first Action shape will always receive a message and will also be the first shape that follows the Begin.

■ Decision We referred to this shape earlier in the chapter as the If-Then-Else construction.This was not completely correct, since its structure is in fact:

If <script expression 1> Then <Start subflow 1> If <script expression 2> Then <Start subflow 2> If <script expression n> Then <Start subflow n> Else <Start subflow m>

Every If statement is called a rule; we discuss the construction of rules in the section Defining Rules.To determine which sub flow to choose, the rules are evaluated, starting at the top.The sub flow of the first "script expression" that evaluates to TRUE is the one that is going to be fol-lowed.The Else flow is mandatory, as it is some kind of "Flow of Last Resort," and that flow will be followed when all other Rules evaluate to FALSE. In the script expressions, you can evaluate message fields and you are free to evaluate different fields in each script expression; there does not need to be any relations between the rules, aside from the fact that they belong to the same Decision shape.You can add rules by right-clicking the Decision shape and selecting Add Rule, or you can select Properties. The former will bring you directly to the Rules Properties dialog.The latter will open the Decision Properties dialog (Figure 7.19) first. Here you can add, delete, and edit rules, as well as change the order of rules. Since the first rule that evaluates TRUE will take the flow, the order of rules is very important.

Figure 7.19 The Decision Properties Dialog Can Be Used to Reorder Rules

Figure 7.19 The Decision Properties Dialog Can Be Used to Reorder Rules

■ While This is the only shape with loop capability.You can add one rule to the While shape; in fact, it is mandatory that you do so. If the rule evaluates to TRUE, the flow attached to the rule is followed.When the end of the flow is reached, the rule is reevaluated and so on, until the rule evaluates FALSE. In that case, the While shape is exited through the Continue and will follow that flow. To add a rule, right-click the While shape and select Add Rule. If the While shape already has a rule attached to it, instead of Add Rule, the option will be Delete Rule.

When you want to modify the rule, right-click the rule in the While shape and select Properties.This will take you to the Rule Properties dialog. Now, right-click the While shape, select Properties, and the While Properties dialog opens. It contains one option labeled State persistence. By default, it is set on No, which is fine unless the While is part of a transaction. In that case, you might consider setting it to Yes .With State persistence active, the messages that are referenced in the loop are also saved in the XLANG Persistence database. If the transaction fails, the On Failure on Transaction flow is called for every time the loop is traversed, even if the loop is completed. If this While is part of the inner transaction of a nested transaction, and the outer transaction fails, the Compensation for Transaction flow is called for every time that While loop is traversed. As you will find out, all rules in While and Decision shapes are centrally stored. This means that the same rule can be used by the different shapes. This will come in handy, since processing messages will often result in performing the same check at different stages in the process. Of course, the chances are that during the development, rules may become obsolete. Without going through the hassle of removing the rules manually, you can always use the Delete Unused Rules utility (under Tools).

■ Fork This shape can be used if you need the business process to split into two or more independent flows that will be executed concurrently. As many as 64 flows can start from a Fork, and they have to finish in an End or come together in a Join. Flows that originate from different Forks cannot come together in the same Join. Since concurrent flows run independently from each other, they cannot exchange messages or other information.

■ Join This shape can be used to let concurrent flows that originated from the same Fork flow together into one flow. As you drag a Join on the page, you will notice that it contains the word AND. This is a Join type.When you right-click the Join shape and select Properties, the Join Properties dialog will open. It holds the Join Type as the sole property of this shape. The two values it can have are AND or OR. The default value is AND, which means that the flow leaving the Join will start, as soon as all incoming flows have finished.When you select OR, the flow that leaves the Join will be started as soon as one of the incoming flows reaches the Join. All the other concurrent flows will continue until they finish in the Join.

■ Transaction This shape enables you to group other shapes into a transaction. We discussed this issue previously, so there is not much left to say about it, except that a transaction is not allowed to contain an AND shape. Be careful when drawing nested transactions, since only shapes that are fully within the inner transaction are regarded as part of this transaction. In the situation that a shape is not fully within the inner transaction, it will be regarded as part of the outer transaction, which can be determined by the fact that the inner Transaction shape will overlay that shape.

■ End This shape determines the end of a flow. Every flow must have an end, which means that every business flow will have at least one End shape; unless you use the Decision,While, and/or Fork shape, you can have more than one End shape within your flowchart.

■ Abort This shape can only be used as an end of a flow within a transaction. It forces the transaction to abort and to be retried, if the transaction did not reach its retry count. Abort can only be used in conjunction with a Decision and/or While shape. Although it is possible to use an Abort together with a Fork, this is not logical since it will always abort a transaction.

■ Port This Port shape is the same one as addressed in the section Shapes from a Developer's Perspective. In this situation, an action will be connected to a port, which will open the XML Communication Wizard, when the port is bound to a messaging technology or it is unbound.This wizard allows you to define the message definition in that port. In case of component technology, the Component Communication Wizard will start and let you choose one of the available methods.You can connect more than one action to the same port. For a port bound to a messaging technology, it is possible to share the same message with more actions, but also have each action have its own message in that port. Ports bound to component technology can also have more actions connected to that port, only now for each action, a Message_In and Message_Out is created, even if these actions use the same Method.

This brings us to a similar situation.When using the Orchestration Designer, notice that the ports appear on all Business Process, On Failure of Transaction, and Compensation On Transaction pages; however, the messages do not.

■ Message This shape is created in the port after the XML Communication Wizard is finished. It represents the data that is exchanged between the action and the Implementation shape. As you right-click the Message shape in the port and select Properties, the Communication Wizard is started. Note the second option View Message on Data Page. If you choose this option, Orchestration Designer switches to the Data page, selects the message, and positions the page so the message is visible.

As you develop your schedule, it is likely that there will be ports and messages on the pages that you will no longer need. Instead of deleting them manually—running the risk of deleting one accidentally—you can use the utility Delete Unused Ports and Messages (under Tools). It will remove all ports that are not connected to an action and Implementation shape. If a port has more messages and at least one has a action and an Implementation shape connected to it, only the message that lacks one of the two connections is deleted. The messages are also removed from the Data page, including the data flow arrows that enter and/or exit these messages.

As mentioned under Fork and Join, more flows can run concurrently between these shapes both in your XLANG schedule diagram and in your machine.The XLANG schedule engine will instantiate a new component for each concurrent flow so it can run independently from others. In addition, since there is no provision made that lets these instantiations directly communicate with each other, they cannot exchange any messages directly. Moreover, since you are nearly never allowed to read messages from a queue, or other Implementation shapes within a concurrent flow, you also are not able to exchange messages via a queue. The reason not to allow reading messages by an Action shape within a concurrent flow is that there is no way to guarantee that a message is or will become available.This will block the concurrent flow from continuing. If you would use an OR-Join, the XLANG schedule can reach the End shape, as long as one of the concurrent flows reaches the Join. However, it will only finish if all concurrent flows have ended. If this is not the case, the schedule will not release its resources.You can imagine what this would mean for your system if this continues over time.This behavior is called "memory leak," and can slow your system or, eventually, bring it to a halt. If you are lucky, the schedule gets at least dehydrated. For example you are waiting for a message that never comes...the reason this could happen is because you had an AND-Join and one of the concurrent flows was not able to end.You will never reach the flow beyond the Join; thus, the XLANG schedule will never finish.

You will use concurrent flows to speed processing, by executing independent actions simultaneously. Of course, these actions will be based on the same input message.We discuss concurrent flows in the section Concurrent Actions.

Was this article helpful?

0 0

Post a comment