How to Configure a Deadline for a BPMN Process

19-2 Modeling and Implementation Guide for Oracle Business Process Management unexpected situations within the process flow. One way to handle the situation in this example by letting the customer cancel the order or save it for later. The following are typical examples of unexpected situations within a process: ■ Lack of stock ■ Workload limit exceeded ■ Expense limit exceeded ■ Feedback past due ■ Credit card authentication problems When an exception occurs in a process, it affects the state of the SOA composite that contains that BPMN process. For more information on how exceptions affect the state of the SOA composite, see Section 23.1.4, How Do BPMN Errors Affect the SOA Composite Status .

19.1.1 Handling Errors Using Exceptions

Oracle BPM uses business exceptions to represent unexpected situations that can occur while running a business process. You can design how to handle an exception as part of the business process, but it is something that occurs outside of the usual flow of a process. The use of business exceptions enables you to create less complicated processes where the main flow follows the typical use cases, and there is a separate flow to handle the process exception.

19.2 Using Business Exceptions

Business exceptions are considered a normal part of the process design, rather than an error. When you add a component to the business catalog, if the services in the component specify that they can produce errors, then these errors appear as business exceptions in the business catalog in the Errors predefined module. An exception can arise when you invoke a service. You can handle these exceptions using a boundary error catch event or an event subprocess. You can also define business exceptions in the business catalog. Then, you can use those business exceptions in an error end event that is triggered under a certain condition. The error end event generates the exception, and the parent process can handle the exception.

19.3 Using System Exceptions

System exceptions represent low level errors that may occur while running a process. In some cases you may require to handle this low level errors within your process. To handle a system exception within the process flow you must catch the exception and configure the error catch event to use system exceptions. System exceptions may occur while running a service or another BPMN process. You also design your process to throw certain system exceptions. The only exception that you can use in a throw or end event is Rollback. All the other supported system exceptions are only available for start of catch error events. Handling Errors 19-3 System exceptions contain an errorInfo attribute of type Any. You can assign any value to this attribute. Because its type is Any this value can belong to any type. Generally you use this attribute to store the cause of the exception or important information for troubleshooting the application. You can only view the list of available system exceptions from the Implementation Properties of an error event. Table 19–1 describes the supported system exceptions. It also specifies the module where the system exception resides and the error events that can use the specified system exception.

19.4 Typical Flow of an Exception

The flow of a system or a business exception depends on where the exception occurred. Exceptions can occur while running the following: ■ a task ■ a subprocess ■ a reusable process

19.4.1 Typical Flow of an Exception Thrown in a Task

The following describes what happens when the BPMN Service Engine runs a task that causes an exception. Table 19–1 System Exceptions System Exception Module Description Error Event AssertFailure Bpel Indicates that the specified assertion failed. Catch, Start BindingFault Bpel Indicates that the preparation of the operation invoked in a flow object failed. For example, the WSD loading failed. You cannot retry the invocation after a BindingFault, recovering from this error generally requires human intervention. Catch, Start InvalidVariables Bpel Indicated that the variables used are not valid. Catch, Start RemoteFault Bpel Indicates that there was a problem invoking a service in a flow object. For example, the remote service returned a SOAP fault. Catch, Start Timeout Soap Indicates that the service exceeded the response time out period. Catch, Start ConflictingReceive Soap Indicates that there are multiple receive activities to respond to the invoked operation. Catch, Start ConflictingRequest Soap Indicates that there are multiple requests on the same partner link for the invoked operation. Catch, Start CorrelationViolation Soap Indicates that the message does not provide the required correlation information. Catch, Start ForcedTermination Soap Indicates the service terminated because a SOAP fault occurred. Catch, End InvalidReply Soap Indicates that the reply does not contain the correlation information required by the corresponding receive. Catch, Start MismatchedAssignmentFailure Soap Indicates the assigned types are incompatible. Catch, Start RepeatedCompensation Soap Specifies that a compensation handler is invoked multiple times. Catch, Start SelectionFailure Soap Indicates there was an error running a selection operation. Catch, Start UninitializedVariable Soap Indicates that the variable you are accessing is not initialized. Catch, Start Rollback Soap Enables the receiver of the exception to rollback the current JTA transaction from within the process flow. Throw, End