As we have already mentioned, our sequence of activities is not a linear structure. The activity Notify Customer has not yet been defined as a successor activity of any other one. ACME wants to differentiate between two paths in the process definition:
Which path the process will go depends on the state of the support case. If the activity Analyze To Solve set this variable to "C" which stands for the CLOSED state, the first option will be realized. If the same variable has been set to "R", standing for REJECTED, the activity Notify Customer will follow. This means that processing of the support case needs to be split into two branches at activity Analyze To Solve. Our diagram has to reflect this.
Before we can create a transition between the activities Analyze To Solve and Notify Customer, we have to redefine the properties of the activity Analyze To Solve to make it a node where the split occurs. Additionally, we will add a loop allowing to perform this activity as long as it does not reach one of the mentioned states: CLOSED or REJECTED.
To introduce these supplements to our activity graph, proceed as follows:
Figure: Defining Control Flow of an Activity
! Tip: You may need to adjust the placement of your activities to make the newly added split gateways clearly visible. Adjusting the diagram viewing percentage (zoom) on the Eclipse main toolbar can help you see the overall layout of your diagram.
Now you can add the missing transition between Analyze To Solve and the activity Notify Customer:
An ACME Support Case needs to remain with the Analyze To Solve activity until it is either Closed or Rejected. Thus a loop is needed around Analyze To Solve.
To add the loop transition:
Now, the newly created loop is in the process definition. The process diagram should now be similar to this:
Figure: Activities Graph with a Join, a Split and a Loop
Now the question arises how to make the successor activities of Analyze To Solve conditional depending on the state of the support case. Each transition between activities has a condition, which by default is set to TRUE; this condition can be redefined.
We have defined a split in our process and need transition conditions between the activity Analyze To Solve and its successors. To define the transition condition between Analyze To Solve and Deliver Patch:
SupportCaseData.Product.State == "C"In the transition condition you can use any of the defined data (use the ID of the data element) including a de-referencing path. Keep in mind that this value has been assigned in our implementation to the state "C"(meaning CLOSED), when a support case has been analyzed and solved.
Figure: Setting the Transition Condition between Analyze To Solve and Deliver Patch
Likewise, define the transition condition between Analyze To Solve and Notify Customer:
SupportCaseData.Product.State=="R"In our implementation, this value has been assigned to the state REJECTED, when a support case solution will not be sought.
Figure: Setting the Transition Condition between Analyze To Solve and Notify Customer
Likewise, define the transition condition between Analyze To Solve and its third successor Analyze To Solve:
SupportCaseData.Product.State!="C" && SupportCaseData.Product.State!="R"This will add a loop permitting to perform this activity as long as it does not reach one of the mentioned states: CLOSED or REJECTED.
Figure: Setting a Transition Condition
! Tip: There is another option for implementing the Analyze To Solve repeat loop. You can choose the condition type OTHERWISE. This will cause the transition to only evaluate to true, when all the other conditions on the split have false values.
Figure: OTHERWISE Condition
Please note that once you changed the Condition Type, the entry in the Condition Expression editor will be lost.
The diagram with the transition conditions will look like the following now:
Figure: Diagram with Transition Conditions