Home > Process Modeling and Simulation Concepts > Activity Outputs > On Completion Tasks
The following topics discuss some of the ways that you can use On Completion options for handling transactions at an activity.
Duplicate On Completion
Creates copies of transactions and sends down all lines (paths) that leave the activity. For example, palettes are unloaded from a truck. The transaction was used to represent the truck, now each transaction represents the palettes that were unloaded from the truck.
Throw away the transaction, and do not count it as completed in the simulation report unless a monitor was defined before the transaction was discarded. For example, in a catsup bottling plant, the catsup must be bottled and capped within twenty minutes. As each batch of catsup is processed for bottling, its preparation time is examined. If any batch is older than twenty minutes, it is discarded.
A batch collection created at one activity may exit that activity as a batch and may pass through one or more activities as a batch before being unbatched in a subsequent activity.
When a batched transaction is unbatched, any resources acquired by the batch are shared by the original individual transactions. Also, each of the individual transactions retain their original attribute values. The unbatched transactions exit the activity in the same queue order as when they were originally batched.
Message On Completion
Send a message to a messaging partner, in order to start or continue processing. The message is received by a partner that has the message defined as an input or exception. For example, send a message to a supplier to order materials.
In Process-type diagrams, messages can be sent within the same swimlane. For BPMN diagrams, messages can only be sent to Pools (swimlanes) other than the one containing the shape that sends the message.
Note: Signals are similar to messages, but are not restricted to only one messaging partner.
The transaction throws an error to the parent process and continues through the process hierarchy until an activity or event catches the transaction. When a transaction throws an error, the transaction can jump through several layers of hierarchy, depending on where the fault is caught.
Transactions that leave the shape can be prevented from continuing through the process under certain circumstances and instead throw a fault. For example, a fault may be an event that requires special handling of a transaction through another process. The fault modeling causes the transaction to be discarded where it is and take an alternate path through the parent process. By default, this causes the transaction to be terminated, but the fault can be intercepted by a parent process of the activity and corrective action taken.
Note: An Escalation is similar to a fault, except that it may be non-interrupting. The normal processing of the transaction may continue, and the activity catching the Escalation may send a duplicated transaction down an exception path.
This option is only effective for a shape that is inside a Business Transaction or has a Business Transaction as its parent process. A Cancel may be an event that requires special handling of a transaction through another process. Modeling a Cancel behavior causes the transaction to terminate its process where it is and take an alternate path if the path is defined.
In a process that is party to a Business Transaction, the Cancel option indicates that the Business Transaction is to be canceled. When a transaction completes the task of a shape, the Cancel option causes the process to stop in the Business Transaction where this cancel is used. A transaction that triggers a Cancel stops its processing in a Business Transaction and take the alternate route if a cancel-type exception event is defined for that Business Transaction.
When a transaction triggers a Cancel but the transaction’s parent processes have no Business Transaction, the simulator ignores the cancel exception. If the transaction’s parent processes have Business Transactions but no Cancel exception specified for any of them, the transaction is discarded in the topmost Business Transaction process in the transaction’s process hierarchy, along with the transaction’s family members within that Business Transaction.
The transaction throws a compensation in order to reverse or undo completed activities; such as 'Issue a refund on a prepaid canceled order.' You may ensure the transaction does not continue until the compensating activities have completed, or allow it to proceed.
Compensation activities are not considered part of the sequence flow, and are only triggered when they catch a thrown compensation.
Related Topics
See Also