Sequence Process Instance
By default, the BW engine doesn’t maintain the event or message arrival order and in many times, users want to maintain this order. If this order can be controlled, the BW process will receive the message/event in order, some problems will be avoided and it also predigests the BW processes.
BW allows two ways to control the process order execution.
TIBCO Administrator allows you to control the maximum number of process instances in memory as well as the maximum number of concurrently executing process instances. Using these settings, you can specify that all process instances execute sequentially in the order created.
2.Process Starter Configuration
Alternatively, at design-time BusinessWorks allows you to specify a sequencing key on process starters and dictate sequential process execution. Process instances with sequencing keys that evaluate to the same value are executed in the order they were started. Process instances can have sequencing keys that evaluate to different values, but only process instances with the same value for the sequencing key are executed sequentially. Process instances with different sequencing key values can be executed concurrently.
In the above figure, one element value of the JMS Message body is set for the Sequencing Key. If the JMS sender sends message and the element which set to the key is constant (for example 10), this process will be executed sequentially. In the designer tester, you can find when the processes receive the messages; the process instance will be created but not executed immediately. They will be completed one by one sequentially.
If sequence key value is not constant or the Sequencing Key is not set, the process will execute concurrently.
In many scenarios, some resource will be access by different process. These processes maybe access those resources concurrently; the processes maybe got dirty data if we don’t set some synchronize measure. BW provides Critical Section to protect these critical resources.
Add group activity in process and set the Group Action as Critical Section. There are two Scopes in the Critical Section attribute – Single Group and Multiple Group.
Single Group is in effect in all the process instances of one Process. For example, a critical section is defined in a process. This process will create more than one process instances when it executed. Those process instances will be synchronized when they executed into the critical section. If one process instance executed into the critical section, other instances will wait it finished the critical section. The critical section in the other process, don’t influence the single group in current process.
Multiple Group is in effect in the process instances of different Process and it also can across different process engine. Multiple Group use Lock Object to synchronized between different critical sections in different process. Multiple Group section with same Lock Object will be synchronized even those critical section in different process or engine.
In above figure, there are two critical sections, both of them are Multiple Group and with same Lock Object. They are different critical section not like Single Group only effect in same section. If the process instance execute in one of the section, the other section will be suspend until the execute section finished and release the Lock Object. And even in the different process instance of different Process definition, we will get same effect.
Generally, the synchronization operation will lower the performance of the application. We will avoid use the following activities in Critical Section:
Wait-for, Sleep, RequestReply and all other activities which take long times.
Avoid using nesting critical sections.
For training on TIBCO BusinessWorks mail us at firstname.lastname@example.org