ability to handle exceptions and recover from errors is fundamental to
implementing reliable and robust business processes and enterprise
There might be cases, though, when an unexpected problem
occurs during the runtime lifecycle of a process that will cause your
process to fail. This could be the result of a connectivity loss, a
failure in a database connection, a selection failure, or a failure
during an invoke activity. These types of errors, referred to as systems
errors, arise directly from the underlying software or hardware
infrastructure where the BPMN Service Engine is running.
might be cases when business faults occur. These are
application-specific faults that are generated when there is a problem
with the information being processed (e.g., a stock control and
inventory service throwing an error when a stock item is not found).
Business faults are a more “controlled” fault type since you are aware
of its plausible appearance; it can occur only if your application
executes a THROW activity or your invoke activity receives a fault
However, despite their essentialness, error
handling and recovery are often overlooked in Business Process
Management (BPM) projects. Analysts tend to model exception handling
(mostly system or rare business faults) in the BPMN, making process
design very complex, and very difficult to read and follow—resulting in
skyrocketing maintenance efforts.
The new release of Oracle BPM
Suite 12c introduced some really nice new error handling and recovery
features. And even though I am tempted to just put on my developer’s
hat, I cannot ignore the importance of the fundamental improvements
Oracle has made in error recovery, from an operations and management
This two-part article will compare the differences in
fault handling options between 11g and 12c and will explore the new
error handling and recovery features introduced in Oracle BPM 12c from
both a developer’s angle (part 1) and an administrator’s perspective
Force Commit After Execution
the new developer-oriented error handling and recovery features in
Oracle BPM 12c is the “Force commit after execution” option (see Figure
1, below). This option configures activities, events and gateways to
explicitly force BPM runtime to add a checkpoint in the dehydration
store, committing the state of the BPM instance after their execution.
important new feature lets developers explicitly force dehydration
during process execution to avoid re-executing non-idempotent activities
in case an error forces the transaction to be rolled back.
take, for example, the loan initiation process. A customer requests a
loan and the system exports the loan application into an xml file before
persisting the loan application data into an operational database (see
Figure 2). Read the complete article here.
SOA & BPM Partner Community
regular information on Oracle SOA Suite become a member in the SOA
& BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.
Blog Twitter LinkedIn Facebook Wiki