BPM, Workflow, and Case

 View Only

Recipe: Parent Child workflow in IBM BPM

By Saswat Patnaik posted Mon September 20, 2021 01:10 PM

  

Creation of multiple child workflows and parallel human tasks


Contents



Skill Level: Beginner

Ingredients

IBM BPM 8.5.x

Step-by-step

  1. USE CASE DESCRIPTION

    There can be use cases where customer will mail/call a service representative to explain the problems related to a product provided by the company. Each problem raised by the customer are initiated as an independent workflow, and all these independent workflows will be mapped to a parent workflow which will be referred by the service representative for monitoring purpose.

    Each workflow will consist of predefined human activities (consider as request tasks) which will be created parallel to each other. Each human activity will be assigned to different teams in-order to take necessary steps that will lead to closure of the case. There can be situation of adding a new parallel activity to an existing workflow, provided the request activities for that workflow are not yet completed. Once all the parallel request activities are completed, a human activity for the approval flow will be created.

    At the same time, there can be scenarios where a new problem can be added to the existing parent workflow, considering the parent workflow is not yet terminated or completed. After the completion of each independent workflows the parent workflow can be marked as completed.

    In case a customer requests for cancellation of his/her request and the parent workflow needs to be terminated, then all the independent workflows and its respective opened activities need to terminated first, so that the parent process can be terminated.

    To implement the above use case or similar use cases that can come across in different vertical for example: opening accounts for different products, onboarding multiple new customers in a single request.

    This article describes the concept of creating a parent process in IBM Business Process Manager(IBPM) that can have multiple child processes within it, and each child processes can consist of parallel/sequential human activities.

    Parent_Child

     

    In this article you will find the step by step implementation for the above scenario or similar kind of scenarios in IBM BPM.

    To understand the end to end implementation we will go through the below steps in details:

    1.       Initiate the parent process and case creation.

    2.       Description of Parent process workflow.

    3.       Description of Child process workflow.

    4.       Adding new child process to an existing parent process.

    5.       Adding new request activity to an existing child process.

    6.       Terminating parent process.

  2. Initiate the parent process and case creation

    Fig1_Initiate-Parent-Process-Service

    Fig 1 : Initiate Parent Process Service

     

    If BPM coaches will be used, then the service flow i.e. Initiate Process as mentioned in Fig-1 can be called from Human service or it can be exposed as restful/webservice API’s for third party user interface to implement IBM BPM processes. Once the service is called, a unique case reference Id/request Id will be created in the BPM application which will be referred as the parent reference Id for future references.

    There can be individual persistent database which will be used to store the request details including the unique request Id, customer details etc. For an example to store the details related to the case there can be a table BPM _Case which will have the basic details related to the case like case reference number, current process step, case status, case created user, case created timestamp, last modified user, last modified timestamp, case completed timestamp.

    After successful persistence of the data, the parent process workflow will be initiated (will be described in details in Step 3) using the Java script API function i.e. “startProcessByName”. When a process is initiated in BPM, a unique instance id is auto generated that can be captured from “tw.system.startProcessByName().id”. You will need another table in the persistent database(let’s refer it as BPM_Case_Instance) to create mapping of case reference Id and instance id.

    Initiate Process service will respond back the unique case reference id to the calling system.

  3. Description of Parent process workflow.

    Fig2_Parent-Process

    Fig 2: Parent process

    In the parent process workflow, child/sub process will be initiated, and the parent process will wait for the event messages whether to complete the parent process or add a new sub process to the existing parent process as shown in Fig-2.

    To understand the parent process workflow, we will go through the below steps:

    1.       Persisting details and initiating of child/sub process.

    2.       Use of Intermediate Message Event(IME)

    • Persisting details and initiating of Child process.

    Fig2.1_Initialize-child-process-and-persist-data-SP

    Fig 2.1 : Initialize child process and persist data SP

    After parent process is initiated you need to find out how many child/sub processes need to be initiated according to the request raised by the service representative. Once you get the count, unique case reference ids/request Ids needs to be created for each of the child process which will be referred as child case reference id. The details of each child process will be persisted w.r.t. their case reference id in the persistence database table(BPM_Case). After successful persistence of the data in the database, the child processes will be initiated (details of child process workflow will be explained in step 4) using the javascript API “startProcessByName” and the instance ids for each child process initiated will be captured. The instance ids will be mapped with the child case reference ids in the persistence database table(BPM_Case_Instance). Another table is required in the persistence database to map the relationship between parent process and child process using the respective reference/request ids, to easily identify all the child processes under a parent process from business as well as technical point of view. After persisting the data in the database and after mapping the parent and child processes, the parent process token will be waiting for the event message in-order to proceed to the next step.

    To listen the event message in the parent process, BPM component On-Event Undercover Agent(UCA) will be used which will be implemented as an intermediate message event(IME) in the parent process (as mentioned as Parent IME in Fig-2).

    • Use of Intermediate Message Event(IME)

    In BPM whenever a message event is triggered, the UCA of active and default snapshot listens the message. If there will be multiple snapshots active in an environment with the same UCA, there can be chances UCA may trigger wrong snapshot. To avoid such scenarios, a correlation key can be prepared using combination of parent case reference id with parent process instance id to trigger the correct IME.

    There will be two functionalities which can be achieved by using an IME:

    1. Addition of new child cases (Detail is explained in step 5)
    2. Completion Of the parent process – This step will come when a child process will be completed, and a message event will be send to the parent process to notify completion of a child process. Once the IME in the parent process is triggered, there will be a decision gateway which will be used to validate whether the event is for completion of parent process or addition of new child process. If the event is for completion of parent process, then retrieve the status of all the child processes from the persistent database w.r.t. the child case reference ids. If the final status of any one child case either not terminated or completed, then the parent process token will move back to the Parent IME, else proceed to complete the parent case and update the parent case status in the persistent database table. The child process should send a flag parameter to the parent process in-order to recognize the event as “Complete Parent Process”. Details on how the parent IME will be invoked from the Child process, will be explained in the step 4.
  4. Description of Child process workflow.

    Fig3_Child-Process

    Fig-3: Child Process

    The child process workflow will be used for:

    1.Creation of the predefined parallel request tasks which might get assigned to same or different teams.

    2.Wait for the event messages whether to create the approval task or add a new request task to the existing child process.

    3.Triggering event messages for completion of parent process.

    To assign the task to different teams to each request task, you can create a team filtration service and attach it in the assignment section tab.

     

    Fig3.1_Team-Assignment

    Fig 3.1: Team Assignment

    To create the parallel request tasks (Refer Fig-3), parallel gateway will be used which will be dividing the process token into two paths. The first path (Request Task) will create the human request task and in the second path (Decision Gateway) there will be an exclusive decision gateway which will check whether there are more activities/request tasks to be created. In case there are more activities to be created then it will proceed to the parallel gateway (Yes path will be followed More Activities gateway as mentioned in the Fig-3) and same procedure will continue till all the request tasks are created. After all the request tasks are created the token will proceed in forward (No path will be followed from More Activities gateway as mentioned in Fig-3) and will be waiting for the event message in-order to proceed to the next step. To listen the event message in the child process (as mentioned in Fig-3), BPM component On-Event Undercover Agent(UCA) which will be used which will be implemented as an intermediate message event(IME) in the child process (let’s refer it as Child IME as mentioned in Fig-3).

    As discussed earlier to invoke the correct IME in the process, a correlation key will be created for the Child IME by appending the child case reference Id and the child instance id (Each child processes that got created from the parent process will have both unique case id and instance id).

    The UCA in the child process will be having the below functionalities:

    • Addition of new request to the child process workflow (Detail is explained in step 6)
    • Completion of the parallel request task– After the completion of one request task, you need to check whether all the request task that got created in the child process are completed or not (Refer to Fig-3.1). If completed then you need to invoke the Child IME using the correlation key “ChildCaseReferenceId+ChildInstanceID”, in-order to proceed to the next step i.e. creation of the approval task. Else the process token waits in the parallel join gateway (Refer to Fig-3). The UCA needs to send a flag parameter to the Child IME in-order to recognize “Complete Request Task”.

    Fig3.2_Check-status-of-task-and-trigger-Child-IME

    Fig-3.2: Check status of task and trigger Child IME

     

     After the completing the approval task in the child process, you need to invoke the Parent IME using the correlation key “ParentCaseReferenceId+ParentInstanceId”. The UCA need to send a flag parameter to the parent process in-order to recognize the event as “Complete Parent Process”.

  5. Adding new child process to an existing parent process.

    There can be scenarios where a new child request need to be added to an existing parent request. This can be achieved by calling another service i.e. “Add New Child Case” either from a BPM coach or the service can be exposed as restful/webservice for the third-party user interface (Refer Fig 4 for the service). Once the service is called, it will validate the request details. If validation fails, then will respond back the error message to the calling system else will invoke the Parent IME and pass the request details to the parent process. Once the IME in the parent process is triggered (refer to fig-2), there will be a decision gateway which will validate whether the event is for addition of a new child process to the parent process or for completion of the parent process. If the event is for addition of new child process, then append the new child request details to the existing child details list and follow the steps as explained in the step 3 only for the new child case. After the new child process is initiated, the process token will wait on the Parent IME for a new message event.

     

    NOTE:

    1. The parent case reference id will be coming as input to the service.

    2. The parent instance id can be retrieved from the persistent database table w.r.t. parent case reference id

    3. The correlation key for the UCA will be “ParentCaseReferenceId+ParentProcessInstanceId”.

    4. UCA need to send a flag parameter to the parent process in-order to recognize the event as “New Child Process”.

     

    Fig4_Add-New-Child-Case

    Fig-4: Add New Child Case

  6. Adding new request activity to an existing child process.

    There can be scenarios where a new request task need to be added to an existing child process. This can be achieved by calling another service i.e. “Add New Request Task” either from a BPM coach or the service can be exposed as restful/webservice for the third-party user interface (Refer Fig 5 for the service). Once the service is called, it will validate the request details. If validation fails, then will respond back the error message to the calling system else will invoke the Child IME and pass the request details to the child process. Once the IME in the child process is triggered (refer to fig-3), there will be a decision gateway which will validate whether the event is for addition of a new activities to the child process or for creation of approval task in child process. If the event is for addition of new activity, then append the new request task details to the existing request details list and follow the steps as explained in the step 4 only for the new request task. The process token will wait on the Child IME for a new message event.

    NOTE:

    1. The child case reference id will be coming as input to the service.

    2. The child instance id can be retrieved from the persistent database table w.r.t. child case reference id

    3. The correlation key for the UCA will be “ChildCaseReferenceId+ChildProcessInstanceId”.

    4. UCA need to send a flag parameter to the parent process in-order to recognize the event as “New Request Task”.

    Fig5_Add-New-Request-Task

    Fig-5:Add New Request Task

  7. Terminating parent process.

    There can be scenarios where requests need to be cancelled. In-order to cancel the parent case, all the active child cases and their respective open activities needs to be cancelled. This can be achieved by using a service flow i.e. “Terminate Parent Case”, either from a BPM coach or the service can be exposed as restful/webservice for the third-party user interface (Refer Fig 6 for the service). The service will retrieve all the child case reference ids from the persistence database table w.r.t the parent case reference id and will verify the status of each child case from the persistence table. For the child cases which are still active, need to verify whether they have any opened activity. If yes, then need to finish those activities and terminate the child case instance using java script API “findProcessInstanceByID(id).abort()”and simultaneously update the status of the respective child case as cancelled in the persistence database table. Once it’s done for all the child cases related to parent case, the parent case instance needs to be terminated and the status of the parent case will be updated as cancelled in the persistence database table.

    Fig6_Terminate-parent-Case

    Fig-6:Terminate Parent Case

0 comments
44 views

Permalink