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. Details will be given 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 defined in the process model:
A maxBatchSize, an activationRule, a groupingCharacteristic and an executionType.

Relations and dependencies to other plugins

subProcess plugin: The batch plugin does not work together with the subprocess plugin. Only one of both can be activa at a time. XES-Logger: 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 the maximum number of processes instances in a batch, independently of the activation rule. A cluster that is maxloaded will start immediately
• activationRule, which can currently be either a thresholdRule or a minMaxRule, defines when a batch is enabled to be executed. For this usually cluster age and cluster load are taken into account
  • A ThresholdRule defines threshold for both cluster age (timeOut) and load. If either one of these is reached or exceeded the cluster is readied for immediate execution. [A variant of the threshold rule, that defines its timeout in relation to a certain due date is in work]
  • A MinMaxRule wants to group process instances with similar grouping characteristics. We currently use data attributes as grouping characteristics. The rule then defines two sets of timeout and threshold: When at least one other instance with the same grouping characteristic is running, the set with higher threshold and timeout is used, otherwise the lower threshold and timeout are used.
• groupingCharacteristic which holds several processVariables. They reference to fields of data objects which define the parameters(s) that have to be samefor cases to be processed together. You can define as many grouping characteristics as you want, but you can also leave this field empty. The grouping characterist is additionally used for the MinMaxRule to determine which thresholds to use.
• executionType which describes whether the events and tasks of the batch activity will be executed parallel, sequential-casebased or sequential-taskbased.
  • parallel executes all process instances in a batch cluster like one (they will then have the exact same output in the XES file).
  • sequential-taskbased sequentially executes all instances of one task (for the process instances of the cluster), then all instances of the next task and so on
  • sequential-casebased, sequentially executes all tasks of one process instance in the cluster, then all tasks of the next process instance and so on 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 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>1</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.