How to do parallel processing within a BusinessWorks process
It is generally well-known that the BusinessWorks engine is multi-threaded and that multiple instances of the same process or different processes can be executed in parallel, each process instance under execution using one of the available engine threads.
This means that in general a given process instance executes in a single thread and activities execute sequentially even when they are in parallel branches.
In the example below there are two parallel branches in the process definition but at run time the two branches will be executed one after the other:
. One of the branch will be picked first and activities of this branch will be executed one after the other until an activity having a transition coming from the other branch will be reached (note : there is no way to control which branch will be picked first by the engine)
. Then activities of the second branch will be executed one after the other until the activity where the two branches are joining will be reached
. Then execution will continue on the remaining part of the process
Note : Control can be given back to the BusinessWorks engine scheduler once the number of executed activities reach a certain threshold value, this mechanism is not included here to keep things simple.
Meanwhile if the above is generally true in practice the exact behaviour will depend from the type of activities used in the process branches.
This is not well known but there are two kinds of activities in BusinessWorks:
. Synchronous activities: those activities execute entirely without returning control to the engine, most of BusinessWorks activities are synchronous like for example the Mapper activity
. Asynchronous activities: those activities execution is managed in two parts:
- A first part that generally consist in sending a request to an external system or initiating the wait of an external event
- A second part that generally consist in handling the response coming from the external system previously invoked or processing a received external event
Between the two parts control is returned to the BusinessWorks engine scheduler that can then schedule the execution of the other branch of our process or the execution of another process (note : there is no way to control this).
Generally speaking asynchronous activities are the following:
. Request / Reply or Invoke activities (like Invoke, JMS Request / Reply, HTTP Request / Reply…) (it can be noticed that in practice asynchronous activities are used to call Synchronous services –Request / Reply services where the Reply is needed to continue execution)
. Wait activities (like Wait for JMS Messages, …)
So overall it means that it is possible to do parallel processing within a BusinessWorks process when asynchronous activities are used.
In the example below at run time the two branches will be executed in the following way:
. One of the branch will be picked first and activities of this branch will be executed one after the other until an asynchronous activity will be reached, the activity will send a request to an external system or will start waiting for an external event and control will be returned to the BusinessWorks engine scheduler
. Then activities of the second branch will be executed one after the other until an asynchronous activity will be reached or the activity where the two branches are joining will be reached
. The responses or the events awaited by the asynchronous activities on the different branches will be received asynchronously and execution of the related branches will resume (we don’t know which branch will be the first to resume execution)
In the example above the overall response time is close from the highest response time between the Invoke activity and the JMS Request / Response activity.
If the service invocations where done in sequence the overall response time would be close from the sum of the response times of the Invoke activity and the JMS Request / Response activity.
This design pattern is very useful when a BusinessWorks process has to call different services or APIs and response times have to be reduced has much as possible (which is often the case in the context of Synchronous architectures).
The principles described above applied to BusinessWorks 6.X, BusinessWorks Container Edition and BusinessWorks 5.X.
Going further
It is also possible to split a process execution over multiple-threads using the following pattern:
. From the main process call a sub-process with the Spawn option. With this option checked the sub-process is executing in its own thread.
. Synchronize between the main process and the sub-process using the Wait / Notify activities, this can be done with the following :
- Use a Notify activity at the end of the sub-process execution to inform the Main process of its completion and if needed pass a data structure
- Use a Wait activity in the main process to wait for the completion of the Sub process execution and read the data structure returned by the Sub-process.
In this approach, the main process and the sub process are executed in their own thread and can then be parallelized at engine and JVM level.
Example of a main process made of two execution branches with one being a sub-process called with the Spawn option and later using a Wait activity to synchronize with the called sub-process :
Example of a sub process using a Notify activity to synchronize with the main process:
Wait activity configuration :
Notify activity configuration :
Notification schema :
It is possible to use this pattern to distribute processing over multiple threads by spawning multiple sub-processes and using multiple Wait activities in the main process.
Useful elements in BusinessWorks 6.X and BusinessWorks Container Edition contexts
Link to the BusinessWorks 6.X documentation explaining the behaviour of the BusinessWorks engine scheduler :
The number of engine threads available to run process instances is defined by the bw.engine.threadCount property managed in the appspace or appnode config.ini file (by default the value of this property is 8).
The following BusinessWorks 6.X and BusinessWorks Container Edition activities are asynchronous:
. Invoke
. Invoke REST API
. Wait, WaitFor, and Sleep activities
. JMS Request/Reply
. Send HTTP Request
. Send Rendezvous Request
. JDBC activities (Query, Update, Call Stored Procedure and SQL Direct)
Useful elements in BusinessWorks 5.X contexts
Link to the BusinessWorks 5.X documentation explaining the behaviour of the BusinessWorks engine scheduler :
Reference information about thread usage by the different activities in the BusinessWorks 5.X documentation:
In BusinessWorks 5.X the number of engine threads available to run process instances is defined by the Engine.ThreadCount property managed in each application .tra file and taken from the deployment configuration (defined in TIBCO Administrator or in the deployment.xml file if you are using AppManage — by default the value of this property is 8).
The following BusinessWorks 5.X activities are asynchronous:
. SOAP Request/Reply
. Wait, WaitFor, and Sleep activities
. JMS Topic/Queue Requestor
. Send HTTP Request
. Adapter Request-Response Invocation
. Invoke Partner activities
. Send Rendezvous Request
. JDBC Query
