Case based Activity Prioritisation
| Document Owner | @Iryna Halenok |
| Document Status | Draft |
| Last Time Revised | 2022-01-24 |
This document describes the new feature added to the Prosimos tool.
Previously, activities were being executed based on their enabled time (taking that the resource who executes the activity is available). However, this is not the case in the real life. For example, the activity can be prioritised by the resource executing the activity or some specific attributes of the process instance can define the priority of the activity execution. Thus we want to allow user to introduce the activity prioritisation by attributes unique by Case ID.
Case ID is a unique identifier of every process instance run during the simulation.
The user should be able to specify the rules and their appropriate priority level. The system is not checking the conformance of the used attributes inside the rules. If case attributes does not exist in scope of the simulation, the exception will be thrown.
The lowest priority level that can be used is 1 and there is no upper limit. The lower number of the priority is - the higher this priority is treated.
Every case should have their priorities calculated. The order of the rules incoming as an input is not playing any role. The system should order them based on the priority level (from the lowest priority to the highest, e.g., from 1 - to infinity). When calculating the priority level of an individual case, the check for the truthy rule is stopped once the first true one is found. This means that even when we have case attributes that satisfy two separate rules in the config, the one higher in the priority is taken as a final priority level.
While adding the task to the queue, we, first, take into account the priority level. In case an activity has the same priority level, we select the item for the next execution based on the enabled time. As a result, we take two parameters into consideration while prioritising the next activity for the execution: 1) a priority level of a case under which an activity in being executed, 2) enabled time of an activity. And the order of parameters is preserved as mentioned.
In case of batching, we have two parts where we impact the existing functionality.
- Execution order inside the batch itself.
All activities inside the batch are being executed according to the priority level of the case they are assigned to. This means that there should be no difference between the execution of the activities in the general pool and those activities present inside the batch.
- Execution order outside of the batch.
In this case, we assume the whole batch as one activity and calculate the priority for this batch. For calculation, we get priority level for all cases that are present in this batch and select the maximum.
We are introducing the prioritisation for items that could be asssigned to a resource. Meaning, we impact the choice of the tasks' allocation to the resource. Since events are being executed on their own and depend only on a provided distribution function, the prioritisation does not impact events execution in any way.
Due to the fact that events and tasks "live" in the same priority queue, we still need to assign some priority to those items internally. For this, the priority of events equal 0. This guarantees that they are executed before the activities and remain being executed in the same order as before the implementation of the prioritisation feature.
The domain model diagram is visualised below.
Composition link is being used for all relationships in the diagram. This is followed by a use case that it does not make sense to have any of the domain elements individually. For example, having AndRule without a parent of OrRule element is not contributing to any of the specified requirement. This means AndRule should exist only together in composition with OrRule. As a result, deleting OrRule results in deleting the underlying AndRule, as well (we should not be left with an orphaned AndRule).