In this tutorial we will examine how to handle run time and business faults, in case of synchronous and asynchronous requests. Here is the flow chart of the use-case we’ll implement.
Client sends a one-way synchronous request message through Mediator.
If Mediator detects invalid XML message (schema validation) runtime exception is directly returned to the client.
Mediator sends a request to BPEL process through “queued” type routing rule. This is equivalent to starting an asynchronous process.
In this article, we are going to learn about exception handling options available within SOA Suite 11g.
Exceptions can be divided into two categories: Business Faults, and Runtime Faults. Usually we let the Business Faults be handled at component level and Runtime Faults at framework level. BPEL and Mediator handle exceptions differently. Lets examine various scenarios:
When exceptions arise in synchronous requests, we will not get enough time to perform any corrective measures as response needs to be returned to the requestor immediately. In such cases, we can only return faults to the requestor. This is true for both BPEL and Mediator.
Oracle SOA Suite 11g offers multiple validation options. By carefully using these options at appropriate places, we can perform validations without compromising on performance.
XSD Validation: This is the most basic form of validation. When enabled, XML elements are verified against their corresponding XSD schema definitions. XSD validation can be performed at Mediator or BPEL component level. Element type and size are two checks that are normally performed using this type of validation.
Since XSD validation is built into the schema, service clients will have an opportunity to understand the validation constraints imposed by the service.
One of the powerful features in Oracle SOA Suite is out-of-the-box Error Hospital. In order to use this feature, Mediator component should have parallel routing rules. Each parallel routing starts a new transaction and can be independently controlled through EM console.
Please refer to Human Workflow Example to understand this lesson better.
MyBay synchronizes its items with MyDel’s datastore at frequent intervals. MyDel expects items from all received Orders to be present in its datastore before further processing. However, due to synchronization issues, sometimes MyBay order items are not found in MyDel’s datastore. In such cases, instead of discarding the entire batch of orders, MyDel needs to selectively retry failed orders after rectifying the issues.
Continuing from earlier Mediator example, lets extend our use-case to include Human Workflow.
MyDel handles two types of orders: Normal and Express. Normal orders are processed only after order items arrive in the Depot. Depot manager then logs into Workflow and releases the order to be sent for further processing in Order Management system. However, Express orders are directly sent for processing into Order Management system.
In this example, we are going to route orders through an Order Router that will route Express and Normal orders to Order Management service and Human Workflow respectively. Depot Manager logs into Workflow system to release order for the goods received in Depot. Released orders will be written to Order Management system.