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 optimize the waiting time for instances with the same grouping characteristic values. 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 value 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 same for 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 (default), 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

Example

The following snippet comes from a process model with a batch activity. 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>

This cluster will group up to two cases together if they have the same room request date and start within 30 minutes. Every group will be processed as one case even if it consists of two actual cases.

Details on implementation and pluggable usage:

The main class BatchCluster holds all the relevant information for one batch cluster. A batch cluster is a collection of process instances which will be executed together (how depends on the execution type). When a process instance reaches the batch activity it will be added to a cluster, following its grouping characteristic. A cluster will then enable the batch activity when its rule is activated or if it is maxloaded and will be started when the needed resources are available. Resources assignments directly to the batch activity are currently only possible when using a task as batch activity, and not a subprocess. Other process instances are currently not able to join a cluster after it has been enabled.

The configuration of a BatchCluster is parsed from a process model by a BatchProcessModelParserPlugin instance, which extends the ProcessModelParserPluggable.

Plugins for start, intermediate, and end events and task enable, begin, cancel, and terminate events are given to define the behavior of these elements inside the execution of a batch cluster.

Execution details on clusters are logged by BatchLogger and BatchCSVLogger, the former in a semi-formal text file, the latter with a table in csv format, containing data on task enablements, starts, terminations, resources and batch affiliation.