BatchActivity Plugin

XML Tag Name

There is no tag in the simulation file.
All the information needed will be provided in the BPMN file as extension attributes. You will se details in the next chapter.

Short description

Batch processing enables a business process, which usually acts on a single item, to bundle the execution of groups of process instances for particular activities in order to improve its performance.
Each batchActivity has four Attributes:
A maxBatchSize, an activationRule, a groupingCharacteristic and an executionType.

Dependencies to other plugins

Deactivate the subProcess plugin, they exclude each other.

Collaborations

If the XES-Logger is active, the batch activities will be logged in there.

Detailed description

The detailed description of the attributes are as follows:

• maxBatchSize, an integer, that defines how many processes can be executed together.
• activationRule, which can be either a thresholdRule or a minMaxRule. That defines when a batch is enabled to be executed.
  • As activation rule, a ThresholdRule is chosen which activates a batch cluster either if two instances are available, or a maximum waiting time of 30 minutes is reached. The maximum batch size is three; as the maximum batch size is higher than the maximal threshold, further instances can be added to the batch cluster although it was already activated as long as the processing is not started by the task performer.
  • Similar, the MinMaxRule triggers the check of the condition, if the size of the batch cluster bc is increased, or when no new one was added for a specific period, such that a timer event is fired. The condition is a logical expression requiring that either the minimum condition is true while there exists no other instance with the same data view, or the maximum condition is true to trigger the action.
• groupingCharacteristic which holds several processVariables. They reference to fields of data objects which define the parameters(s) that have to be same, so that equal objects will be processed together. You can define as many grouping characteristics as you want, but you can also leave this field empty.
• executionType which describes whether the events and tasks of the batch activity will be executed parallel or sequential. Parallel means that all process instances in a batch cluster will be executed together (all instances of a batch will have the exactly same output in the XES file). Sequential says the following: First, all process instances will do the first event/task. When they are all finished, all of them will do the second one etc. until all process instances in this batch cluster have finished the batch activity.
  If this field is left empty, parallel will be chosen as the default parameter.

An example for a batchActivity in the BPMN file. The two outer namespaces have to be enumerated with your root tag (in this case bpmn), the inner ones can be either enumerated with either the root or the camunda tag:

<bpmn:subProcess id="Task_0z95iaa" name="Batch Activity">
	<bpmn:extensionElements>
        	<camunda:properties>
          		<camunda:property name="maxBatchSize" value="100"/>
          		<camunda:property name="executionType" value="parallel"/>
          		<camunda:property name="groupingCharacteristic">
           			<camunda:property name="processVariable" value="RoomRequest.Date"/>
          		</camunda:property>
          		<camunda:property name="activationRule">
            			<camunda:property name="minMaxRule" minInstances="1" minTimeout="PT0S" maxInstances="2" maxTimeout="PT30M"/>
          		</camunda:property>
		</camunda:properties>
	</bpmn:extensionElements>
	<bpmn:task id="Task_1pqdkju" name="Prepare printouts">
		....
	</bpmn:task>
	...
</bpmn:process>

and the corresponding dataObject , which is defined in the simulation file

<bsim:dataInput id="DataObjectReference_0vnqhdu" name="RoomRequest" >
	<bsim:field name="Date" type="long">
		<bsim:uniformDistribution>
			<bsim:lower>0.5</bsim:lower>
			<bsim:upper>21</bsim:upper>
		</bsim:uniformDistribution>
	</bsim:field>
</bsim:dataInput>

In detail to the implementation and pluggable usage:
There is a batch cluster lass added, which holds all the relevant information for one batch cluster. A batch cluster is a collection of process instances which will be executed together (whatever that means is dependent of the execution type). When a process instance reaches the batch activity it will be added to a cluster, by following its grouping characteristic. A cluster will then start the batch activity when its rule is activated. Depending on the rule, during activation and execution other process instances are able to join a cluster.

The processModelParser of Scylla gets extended by a section which handles the parsing of extension elements of sub processes, to parse the batchActivitys from the BPMN file(not in an extra class, the vanilla class handles it).
Furthermore the BPMNStartEventPluggable gets extended by the BatchBPMNSEPlugin, the BPMNIntermediateEventPluggable by the BatchBPMNIEPlugin and the BPMNEndEventPluggable by the BatchBPMNEEPlugin. These are mainly needed for the logging of the not simulating process instance when having a parallel execution, the finishing of the batchActivity sub process or the scheduling of the other, not primary process instances, when having a sequential execution.
Also the task pluggables are extended, in detail the TaskBeginEventPluggable by the BatchTBPlugin, the TaskCancelEventPluggable by the BatchTCPlugin, the TaskEnableEventPluggable by the BatchTEPlugin and the TaskTerminateEventPluggable by the BatchTTPlugin which d also logging in the parallel case but also handle the prevention of execution of tasks automatically scheduled, because it is a sub process.