Question

Can we attach a child Process at run time in a generic manner e.g. from database metadata?

Answer 1

A little used, but very useful feature in the BPD Modeler allowing you to use a "Dynamic Sub Process".  First note this should actually have been renamed "Dynamic Linked Process" when they change the naming in the 8.X line (mentioning this to avoid confusion).  Also the specific dynamic processes must have the same interface - that is the input and outputs for each need to be the same variables (down to the name I think).

You implement this as follows -

1. Create you BPD that will call the dynamic sub (linked) process.
2. Put an activity on you diagram that will get name of the correct process to use from the DB.  This value should be put into a variable.  I suggest something like tw.local.dynamicProcessName
3. After that put an activity that is implemented by a linked sub process.
4. Create the first linked process you want to use and link it.  This effectively creates the "signature" for your variables.
5. Create the 2nd (dynamic) linked process.
6. In the Master BPD, on the implementation tab toggle the arrow next to "Processing Behavior"
7. In the revealed setting "Dynamic Sub Process" put in your variable name - e.g. tw.local.dynamicProcessName
8. Make sure the DB is returning the right names.

Since you are overriding the Linked Process to execute, the first one you create can be created with no implementation details except the inputs/outputs as it would only actually be executed if its name were returned in the DB call.

Comments

Thanks BPM Overlord, I was looking for this but could not find the exact implementation details, the other method i mentioned was used in previous version of IBM BPM

---

Well, this approach is limited in that it can only be used if your inputs / outputs are consistent between the various implementations (or you use generics, but I think using generics in this way is an anti-pattern).

This feature actually dates back to TeamWorks 6, so it should have been available but there very well have been other reasons not to use it (as noted above)

Answer 2

We can have a pluggable kind of architecture where in database metadata can provide the child process to be invoked and use startBPDByname based on the child process defined in the metadata, for example to create a generic account opening process which can be used as a cookie cutter to attach various different types of account opening processes where the high level process is same but the sub-processes depend on the type of account to be opened

The attached pluggable sub process sends a message back to the parent process on completion to resume the parent process.