Creating re-usable activities


I'm facing some problems regarding Activities. Here I explain the problem and all possible approaches that I've thought of till now due to which the post becomes too long. Thanks for reading.

I am trying to create Activities which take predefined inputs and return some outputs. I want these activities to be able to be reused again inside other processes at a later time (like maybe create a new Process and drag few predefined Activities into it as per your requirement to create a Process flow).

The problem occurs because activities don't exist on their own (they need to be inside an already defined Process). Because of this, I tried few alternatives:

  1. First Approach: I thought of creating a Process and then define all the required Activities inside it. So whenever you need to create a new Process Flow, create a Process and copy the activities(using Ctrl + C) from the first Process and paste it wherever required in the new Process. This way, I am using the first process only for holding my re-useable Activities and no actual instance of that Process is ever run.
    Problem: By using this method, if in future the definition of an Activity changes, I'll need to change it at all the places where that Activity is copied.
  2. Second approach: I thought of defining all the re-useable Activities by keeping one Activity inside one Process. This way whenever I need to reuse an Activity, I call LaunchProcess action of the Process containing that activity.
    i) If my Process flow contains 20 Activities, that'll mean I'll be Launching 20 Process instances one after the other from a single Process.
    ii) Using this method, I can't make sure that the first Activity inside a process finishes before the second activity in that process is started (since processes are run asynchronously). So, it might create problems if my first activity has an output parameter to be used as an input in second activity.
  3. Third approach: I thought of creating one Action Logic for each re-useable Activity inside the Logic tab in Service Studio. So whenever I need to reuse an Activity, I create a Process, then drag a new Automatic Activity from left panel and then place the required Action Logic inside that Automatic Activity.
    Problem: It only solves the problem for Automatic Activities. This way I'll still have to configure the properties (in bottom right properties panel) for human activities and wait statement.

    Currently I'm following the 3rd approach, but need to find out a way to minimize the configurations that need to be done after design of re-useable components is done.

    Please suggest some way for this (and thanks for reading it till last! :P)

Hello Mandeep,

Personally I prefer the second approach, although it creates much more metadata for the instances, you get to change smaller pieces of the process without affecting the parent processes design. This is actually the recommended approach for better controlled process deployment when process versioning is considered (publishing a sub-process does not lock it's parent process, nor it's siblings).

I believe having one sub-process per activity may be a bit too much, but I don't know your specific usecase. Usually granularity sits a step higher in abstraction, where you have something like "Create Invoice" or "Approve Documentation" with several decision, automatic and human activities inside, all working towards a single objective.

Now I don't understand why you say the 20 activities are all launched at once. The launch subprocess is not assynchronous, it waits for the previous subprocesses in the same flow path. 

Serial processing:

Parallel processing: 

Also please note that subprocesses do not exit to it's parent processes unless all execution paths are covered (Process2, Process3 and Process4 in the previous instance), or if a Terminate node is executed.

Let me know if this helped you in any way.

Kind Regards,

João Grazina

Hi João,

Thanks for your reply. It definitely helped me since till now I was thinking that launch sub-process is asynchronous.

So, it does solve my second point where I say that I can't pass on the output of one sub-process as an input to another sub-process.

But still my concern remains that if a process has several steps (which could be as large as 50 steps), it would mean that there are 50 sub-processes inside that process. Won't this cause the system to slow down since we are launching multiple sub-processes from a single process?

Hi Mandeep,

Actually it won't slowdown. The difference between having an activity or a subprocess in terms of resource usage, is simply that the subprocess has more metadata than the activity. There is no specific CPU process allocated to a BPT SubProcess (or process, for all that matters).

Let me try to put it in a specific example so that you understand resource consumption on BPT. Imagine the following two scenarios:

1) Single step Automatic activity

2) Subprocess with single step Automatic activity

On the first scenario, metadata that is written is the Activity table (and it's inputs/outputs which we'll disregard), so only one record in a table.

On the second scenario, the metadata that is written is:

- SubProcess activity on Activity table

- The actual SubProcess on the Process table

- Start, Stop and Automatic activity from the SubProcess on Activity table

So in all, 4 activities and 1 process on their respective entities. 

Now to go back to the performance side of the question when the system needs to run an activity, it will poll these tables for actionable activities, and execute them one after the other until execution is suspended for some reason (human activity, wait for node, an exception, etc). This happens with the same number of threads regardless of whether you have one automatic activity (1), or a subprocess (2). 

There usually are 10 processes per frontend processing BPT threads, and these processes are assigned activities to run when they are ready to be executed.

So in all, if you take the subprocess approach, I only have two hard recomendations:

- keep it clean, use the BPT_API to delete ended processes or bulk delete by process type (don't worry, it only deletes ended processes) -

- Define the granularity you need. I like the idea of encapsulating complexity in subprocesses to enable safe versioning, but I think having one subprocess per activity may be a bit too much. you will loose some interesting features like BAM readability.

Kind Regards,

João Grazina