Procedures provide a graphic definition of component methods that do not have
interaction with end users. Procedure use a graphical syntax similar to Oracle BPM 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.
Automatic Activities within the procedure can have:
- 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.
A procedure is a set of automatic activities that does not define a Process, but it
defines some automatic instance behavior. For example:
- 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 PBL-Method has a large number of lines, you should consider the possibility of
moving the PBL-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.
Operations guaranteed to be rolled back are:
- 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).