MDG Rule Based Workflow – Parallel rejection immediately

#0 Introduction

There is a parallel workflow in which a workflow is sent to multiple departments at the same time, each department takes an action, and when the action is finished, the result is merged to determine the next flow. How to set up this flow is detailed in this document.

#1 Requirement

In a situation where a parallel workflow is implemented, when one department takes a rejection action, we want to immediately make a rejection decision without waiting for the decision of the other parallel side.

#2 Solution

First, separate the subsequent step approve action and reject action on the BRF+ table. When user choose approval, condition 99 selected and process pattern 99 (Close Sub workflow) will be executed.  Otherwise, When the rejection chosen it should calls the system method before terminating the sub-workflow. The system method terminates the parallel sub-workflow on the other side and closes the dialog step to bring the flow to the merge step.

#3 Sample

The basic implementation is the same as this how-to document. When one department of the parallel step takes a reject action, the workflow log is as follows. A dialogs step and a sub-workflow for the other parallel division remain.

You just do call the system method and close the remaining two work items in that method.

The BRF decision table is as follows. In the case of approval, the sub-workflow ends as it is, but in the case of rejection, the system method is set to be called.

To get work item numbers in method, I refer to this article. This would be a good reference. If you can get work item numbers, terminate the work item using WAPI FM as follows.

And I found that the action code was disappear at the merge step. Presumably because you call the system method twice, the action code disappears on the second call. That’s why I add the action code manually at the end.

When the implementation is finished, the flow moves as follows. When either side’s rejection action is executed, the other side’s flow is automatically terminated. You can see that the system workflow user exits the dialog step.

#4 Conclusion

In this way, you can return the flow to the requestor to modify the data without waiting for an action from another department. If one department approves and the remaining department rejects it, the flow works without any problem.