Grab activities give processes the flexibility to deal with slowdown conditions and to redistribute instances as appropriate to alleviate such conditions. Grab activities are most commonly used in supervisory roles within the process.
This enables supervisors to monitor instance flow. They can use the Grab activity to easily move instances from one activity's queue to another activity's queue.
The following table outlines some of the considerations when using the Grab Activity within ALBPM Studio.
| WorkSpace | All Grab activity types are visible in WorkSpace to the user(s) assigned to the role. |
| Variables | All Grab activity types can access argument, instance, local and predefined variables from the BP-Method Editor. |
| Pre Conditions | Grab activities require incoming grabbed instances from other activities in the process. Defined Grab activities can only receive instances from activities to which they are attached by transition. Grab From All and Grab From All/To All activities can grab instances from any activity in the process. |
| Post Conditions | Defined Grab: Once marked complete, instances are sent to the next activity in the process via one of the outgoing transition lines. Grab From All : Once marked complete, instances are sent to the next activity in the process via one of the outgoing transition lines. Grab From All/To All: Once marked complete, instances are manually sent to the appropriate activity in the process by the end user. Note: Instances that have been grabbed to one Grab activity and remain in this activity cannot be grabbed from another Grab activity.
|
| Transitions | Defined Grab: One or more incoming transitions are required. An outgoing transition is not necessarily required. There is an implied back transition that takes instances back to the activity from which they were grabbed. This is accomplished by clicking the Ungrab button in WorkSpace. If a Defined Grab activity has transitions to or from activities inside of a Split-Join circuit, this same Grab activity cannot have transitions to or from activities outside the Split/Join circuit. Similarly, a Grab activity with transitions to or from activities outside of a Split/Join circuit cannot have transitions to or from activities inside a Split/Join circuit. Grab From All: No incoming transitions are required. The Grab From All activity can grab instances from any activity in the process. An outgoing transition is not necessarily required. There is an implied transition that takes instances back to the activity from which they were grabbed. Grab From All/To All: Grab from All to All can take instances from any activity and can send them (re-deploy) to any activity. Note: If you do not want to see the Grab transitions, disable the Show Grab Transitions property from the View menu, Transitions option.
|
| Tasks | Tasks have to be defined by the developer. The grab activity has a main task. Moreover, optional tasks can be added. |
| Business Process Methods | Grab activities only have access to another activity's instances. Grab activities cannot access the BP-Method for the activity it is grabbing. However, you can assign the same BP-Method to the Grab activity that is assigned to the activity that you are grabbing instances from. For example, if you have an Interactive activity called Review Order that has one BP-Method called enterCustomerInfo, you can apply the same BP-Method to the Grab activity. You can add tasks to the Grab activity to process the BP-Method according to business rules. You can also ungrab the instance and allow it to go back to the activity from which it was grabbed in order to continue processing. |