BPM, Workflow, and Case

 View Only
  • 1.  Unable to get the name of the BPD that called a service

    Posted Tue October 15, 2019 10:01 AM
    ​Hi,

    I'm currently trying to get the name of the parent BPD to a system task.

    We have 'BPD A' (main process), that drops in to 'BPD B' (sub process) and within the sub-process we have a step called, let's say "Send Message" which implements a system task service.  At a point in the service I want to get the name of the BPD ('BPD B') that invoked the service.

    Basically the called service is going to be a re-usable Toolkit component and could be called from a number of different sub processes in various process apps.  We want to generically get the name of the parent BPD - essentially "I was called by...X"

    I have tried various combinations within the tw.system namespace (currentTask / currentProcess / currentProcessInstance) and all I can seem to retrieve is either the name of the main BPD ('BPD A' - tw.currentProcess.name) or the actual step name as the service box is named within the sub-process BPD ("Send Message" - tw.system.currentTask.processInstanceStep.name).

     

    Essentially I would like to get something like 'currentTask.parentBPD.name' but I'm beginning to think this isn't even possible.  I seem to only be able to get the step name or the instance name, but not the current sub-process name (the middle step).

     

    Does anyone know of a way to get this information at run-time?  I don't mind if I need to get some GUID and call an API to retrieve the details of it, or if I'm just completely missing where this name is stored...

    Cheers!



    ------------------------------
    Grant
    ------------------------------


  • 2.  RE: Unable to get the name of the BPD that called a service

    Posted Tue October 15, 2019 10:43 AM
    There are 2 different ways to invoke a BPD as an activity within another BPD in IBM BPM.  These are "SubProcess" and "Linked Process".  The important question here is which of the 2 you used to implement this.  You stated "Sub Process".  The primary difference in these 2 are in how they are created.

    "SubProcesses" are not reusable as they are created in the context of the activity in the Parent BPD.  They also do not have their own variables, but rather inherit the context of the BPD within which they were created.  Both of these factors are why are some of the reasons why I don't like using them, as they can lead to variable sprawl and prevent proper code reuse.  If you really are using a SubProcess, then there is no "Name" associated with the SubProcess, but rather just an internal GUID used by the engine for tracking the items.  In this case there really is no "BPD Name" for you to use, just the Activity name on the Top level BPD.

    "Linked Processes" actually exist in the Library as their own entities.  These can be reused, and have their own execution context (variables etc.).  They can be invoked as Activities in another BPD.  If this is what you have done there is a chance you can get the data you want, however it will likely require several calls to the ReST API.  I created a quick solution consisting of a BPD called "Test Execution Tree" containing one activity invoking a linked BPD called "Simple Child Process"  in that process I had 1 human activity assigned to me.

    I created an instance of this BPD and then invoked -

    https://<myserver>:<my port>/rest/bpm/wle/v1/process/3903?parts=executionTree%7Crelationships​


    The response was -

    {
      "status": "200",
      "data": {
        "description": null,
        "richDescription": null,
        "caseFolderServerName": null,
        "processAppName": null,
        "processAppAcronym": null,
        "processAppID": null,
        "snapshotName": null,
        "snapshotID": null,
        "snapshotTip": false,
        "startingDocumentServerName": null,
        "comments": null,
        "tasks": null,
        "documents": null,
        "actionDetails": null,
        "relationship": [
        ],
        "executionTree": {
          "executionStatus": "1",
          "root": {
            "name": "Test Execution Tree",
            "nodeId": "1",
            "createdTaskIDs": null,
            "variables": {
            },
            "children": [
              {
                "name": "Call Linked BPD",
                "nodeId": "5",
                "flowObjectId": "c8e578da-b2dd-4ee3-85d8-24ccdb140d04",
                "taskType": "5",
                "tokenId": "4",
                "createdTaskIDs": null,
                "variables": {
                },
                "children": [
                  {
                    "name": "Process \"Simple Child Process\"",
                    "nodeId": "6",
                    "processId": "25.6848e351-1557-4374-8afb-389641578b31",
                    "branchId": "2063.17a1692b-bc3a-4a2f-99c2-155e76264961",
                    "createdTaskIDs": null,
                    "children": [
                      {
                        "name": "Inline User Task",
                        "nodeId": "10",
                        "flowObjectId": "13621c37-7ab0-4650-90b8-40beb58bc134",
                        "taskType": "1",
                        "tokenId": "9",
                        "createdTaskIDs": [
                          "5053"
                        ],
                        "variables": {
                        },
                        "children": null
                      }
                    ],
                    "DataModel": {
                      "properties": {
                      },
                      "inputs": {
                      },
                      "outputs": {
                      },
                      "validation": {
                      }
                    }
                  }
                ]
              }
            ]
          }
        },
        "actions": null
      }
    }


    In the above you can see that the current task is ID 5053, and the parent to that task is a BPD with the GUID of 25.6848e351-1557-4374-8afb-389641578b31 and the name "Process "Simple Child Process"".  So if the user task was the system task you are invoking it could make this call, find it's own entry in the JSON, and navigate up to the parent.

    Now, having said all of this, I would question the utility as my users rarely ever know about the Linked / Sub Process and only ever really know the parent the owns it, so unless the e-mail is specifically intended for a support team I would think the correct "noun" to use would be either the overarching process that is running, or the activity in that BPD that invoked the sub process.

    Hope this helps.



    ------------------------------
    Andrew Paier
    ------------------------------



  • 3.  RE: Unable to get the name of the BPD that called a service

    Posted Mon October 21, 2019 04:28 AM
    Edited by Grant Pozzana Fri November 29, 2019 06:15 AM
    ​Hi Andrew,

    Thank you for the detailed reply.  I did actually mean a 'Linked Process' (terminology faux pas on my part!).  To just give a little more context, the requirement is that we are supplying 'components' to the (non-Developer) people building the processes.  As part of this they want a message sending to an external system to update where in the process the users are currently up to, so essentially we need to give them a component that will return the name of the linked process (process step) before and after the step is complete and pass it to the external system with a timestamp.

    It looks like your solution above will provide what they are after.

    Thanks again!

    ------------------------------
    Grant Pozzana
    ------------------------------



  • 4.  RE: Unable to get the name of the BPD that called a service

    Posted Mon October 21, 2019 11:31 AM
    So, if the real requirement is -
    We want to update an external system with the details of where the process is when a task either is created or completed. 

    I would not use a system lane item to do this, as it impacts performance to no business benefit.  IBM BPM 8.5 and above has a set of JMS messages known as (I think) the DEF queue (Digital Event Framework?).  There is a message emitted on these for every task that is created or completed.  If I wanted to notify a 3rd party system of the state of various processes, I would hook into this queue and then do post processing (like making the ReST call above to get all the data) and push the information over using that rather than require that the process be built properly to get this outcome.

    You could then use either a Whitelist or Blacklist approach to ignore the events that aren't important to the external system that wants to know these states.  We've done this for several of our customer over the years and I feel it is a better approach than requiring that each process make the correct calls to ensure items stay in synch.

    -Andrew Paier





    ------------------------------
    Andrew Paier
    ------------------------------