Procedures provide a graphic definition of component methods that do not have interaction with end users. Procedure use a graphical syntax similar to ALBPM Studio processes.
Procedures contain a set of activities that is executed by a single participant. It also has a reduced set of activities that can be used. No roles are allowed because a procedure is limited to automatic activities.
Procedures are designed to be used in any part of a process. A procedure cannot be used outside the project that it belongs to, but it can be reused among Processes in the same Project.
As it has an automatic behavior, a procedure does not have roles and it only includes automatic activities. That is, activities of the following types: Begin, End, Process Creation with no Termination Wait activity, Process Notification, Automatic, and Split-Join). It also includes Groups and Compensate Transitions.
- Process Business Language (PBL) Methods
- Component calls (Runs on server components only.)
- Procedure calls.
When to Use Procedures
Procedures should be used in order to reuse part of a process. They are the right way to share process behavior between more than one process or inside the same process (calling the same procedure several times) instead of using IPC.
- Having a set of automatic activities that perform several notifications to different third-party applications and this behavior is repeated by most of the processes within the project.
- A set of automatic activities that should be used several times within a Process. Therefore, adding several Procedure calls to the same Procedure would clarify the design.
- If your BP-Method has a large number of lines, you should consider the possibility of moving the BP-Method to be implemented as a procedure and break down the method into several activities in a graphical design.
- To graphically show a sequence of components methods to improve its comprehension.
- To hide certain details of the implementation and push some logic to another level of the design.
Procedures within a Process Instance
Once the process instance reaches an activity that executes a procedure, it remains there until the procedure finishes. The process instance is never in the procedure. The process instance actually remains in the process therefore, whatever you 'apply' in the procedure does not affect the process instance.
The procedure instance is a separate instance and the operations performed over the instance within the procedure will not apply to the process instance. For example, neither adding notes nor attachments will apply to the process instance. If you need to use any of the process instance variables data, they need to be passed as arguments.
Rolling Back Procedures
Procedures are defined as atomic. The rollback is automatically done by the Engine.
- Transactions performed using External Resources that handle transactions such as Data Base transactions or EJB.In a BPM J2EE Engine the rollback is guaranteed by the two-face commit. In a BPM Engine Standalone, the commit is an optimist commit. This means that each external resource receives an independent commit but it is expected that neither of them will fail, but if one does, then the transaction is not fully rolled back. For example, if you have two databases with different transactions, and the second one fails, the commit performed to the first one is not rolled back.
- Update to Instance information.
- Update to variables information.
Exceptions cannot be treated inside a Procedure, they are thrown to the immediate outer group (or parent group).
Example: Storing a Purchase Order
The Order is composed of a header and line items. The first procedure activity can be the storage of the header and the second one can be the storage of each individual line item. You can implement the loading of the order in the same way-a procedure activity will load the header and another activity will load the order line items.
