Your first step of Questetra BPM Suite / Chpt.4: Splitting by Condition

Chapter 4: Splitting by Condition

• Chpt.1: Using the Preinstalled App as Workflow User
• Chpt.2: Creating a Simple App
• Chpt.3: Creating a Travel Request App
• Chpt.4: Splitting by Condition

In Chapter 3 we added the [Boss] Swimlane allowing the applicant’s supervisor to participate in the travel request process. When that happens, you might start having ideas to improve the App, such as whether or not it is sufficient for the supervisor to just look over the request. For the final installment of this tutorial, I will introduce you to the implementation of splitting, which changes the token’s destination according to the conditions. This will greatly enhance the expressive power of the App.

Making the Boss able to Reject the request

In the current state a travel request cannot be rejected. The supervisor should be able to choose whether to approve or reject a request after reading its contents in the [Approve] Task. Let’s create this option.

Editing Workflow diagram

Launch the Modeler and open the [Workflow Diagram] tab. Then add an End Event to the [Boss] Swimlane and draw a flow arrow from the [Approve] Task towards the End Event.

When you added the flow arrow it created a branch, so the destination of the token depends on the supervisor approving or rejecting it. “Approve” and “Reject” along the arrows are also the names of the button labels displayed at the bottom of the task processing form. Since they are not displayed immediately after adding the flow let’s set the button labels.

Setting up the button labels

Now let’s set the display labels of each button. Open the settings window of the [Approve] Task. When you move to the [Split] tab, you can see the Button Label settings item there.

Set the name of the button whose destination is [Confirmation] to “Approve”. Similarly, for the destination End Event, set this label to “Reject”. By doing this, when the supervisor finishes handling the [Approve] Task by clicking on the [Approve] button, the token will transit to the [Confirmation] Task, and by clicking the [Reject] button it will go to the End Event on the [Boss] Swimlane. Now save the App and release it.

If Canarias makes a travel request for example, and Sumatera, who is Canarias’ supervisor, opens the Operating screen of the [Approve] Task, it will look like the above figure. Try clicking on the newly created [Reject] button.

The token advanced to End Event on the [Boss] Swimlane and the Process has ended. In this way you can change the destination of the token by using the options. This is one way of implementing a split.

Practically, it would be better that if the supervisor rejects a request, it is returned to the applicant. However, for the sake of simplicity I made this example so that the Process is terminated when rejected.

Letting the company president check requests with high costs

Finally, let’s modify the App so that it requires confirmation by the president of the company on requests for expensive business trips that will cost more than $10,000. Please open the edit screen as we are going to revise the App again.

Editing the Workflow diagram

Modify the Workflow diagram as follows; we will add a [President] Swimlane and make substantial changes after the [Approve] Task. Let’s see the procedure in detail.

First, add a new Swimlane between [Boss] and [Management Department]. Then change its name to “President”. Also, add a Task to the [President] Swimlane and name it “Confirmation”.

The green diamonds labelled [Split] and [Merge] in the above figure are referred to as Gateways. They control the splitting and merging of flows. Gateways are also contained in the pallet.

When you click ▼ next to the diamond icon the list of Gateways is expanded. You can add various Gateways to a Workflow diagram by choosing the icon. The following two Gateways are used this time.

The Basic edition does not show the [Inclusive (OR) Gateway ] and [Parallel (AND) Gateway  ], and [Merge Gateway (OR)] [Merge Gateway (AND)] that are not available.

	Exclusive (XOR) Gateway	Advance to the branch which satisfies the condition first among multiple flows
	Merge Gateway (XOR)	Merge multiple split flows into one

Place an Exclusive (XOR) Gateway onto the [President] Swimlane, and a Merge Gateway (XOR) onto [Management Department]. Since the Merge Gateway you just deployed is not named open the settings window just like any other object and set the name to “Merge”.

It is correct if the objects are arranged as in the above figure.

All we have to do is to redraw the flow arrows. Upon doing so, please be careful not to inadvertently move the flow extending from the [Approve] Task in the [Boss] Swimlane. The Reject and Approve flows set earlier have been given specific branching conditions. Since deleting or rerouting the root of the flow (on the [Approve] Task side) will delete the Split condition setting you will have to set it again. In particular, please do not delete and redraw the Approve flow. Drag and drop the arrowhead of the flow.

Taking note of the above let’s draw flow arrows to look like the figure below.

After redrawing all the flow arrows, check if the names of the flows extending from the [Approve] Task remains as “Reject” and “Approve”. If a flow arrow is deleted or its root is removed from a Task, the splitting condition is deleted and the labels will disappear. If that happens, please re-establish the splitting condition you set previously. Remember to reset the button label for the splitting condition.

Setting the Splitting condition

Next, set up the newly created split. Open the settings window of the Exclusive (XOR) Gateway. There you can set the destination of the token for each condition in the Destination Node section.

Condition	Destination
Travel cost is more than $10,000	[Confirmation] Task on the [President] Swimlane
Others	[Merge] Gateway on the [Management Department] Swimlane

It seems that the App will behave as desired if you can set up as the above table. As there are two conditions and a Default Flow from the beginning let’s edit those. A Default Flow is what will be selected when none of the conditions is satisfied. Thus, it will be sufficient if you set the condition “Amount is over $10,000” and a Default Flow. The Default Flow serves the role of “Others” shown in the above table.

First, delete one of the conditions whose destination is Merge, since it is sufficient to have only one condition and a Default Flow. Next, change the destination of the Default Flow to Merge. With these, you have set up the “Others” condition.

And in the other condition whose destination is Confirmation, the condition has been set as “Always move to Destination”. You must change it so it will move to that destination if the Amount is greater than or equal to $10,000. Click on the pencil symbol to open the details window and set it up as follows. Enter “condition1” as the condition name.

It has been set so that when the value of the Data Item “Amount” is over 10000, that is, the travel cost exceeds $10,000, the token moves to the [Confirmation] Task on the [President] Swimlane. Now, you can control the transition of the token as shown in the table above.

Please confirm that the properties of [Split] are like the above figure. There is nothing to set in [Merge] (the Merge Gateway). Now you have completed the Workflow diagram!

Setting the Operator

After finishing editing the Workflow diagram you will set up the Operators next. In the [President] Swimlane settings window, change the Operator to [Organization] [00 COMPANY NAME] [Leaders who belong to this]. Since the top Organization of the company is [00 COMPANY NAME], the leader of it represents the President.

Now save and release it, and try making a request with a cost of more than $10,000 as an employee. Like before, the [Approve] Task will be delivered to the immediate supervisor. When the supervisor approves it, the [Confirm] Task will be delivered to you as the president of the company.

Does the App you created work properly? Once you have created the App it automatically processes the designation of the immediate supervisor, and whether the president needs to give confirmation or not. The log of who operated which Task and when can be confirmed later.

This is the end of the Questetra BPM Suite Tutorial for beginners. I introduced only the rudimentary functions of Questetra BPM Suite, but how was it? I hope you will meet your challenges for the automation and visualization of business rules which are repeated every day using Questetra BPM Suite!