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.
In the present lesson, lets see how Error Hospital can come to rescue. We will first run Human Workflow Example with incorrect values and see how transaction fails. Then, we will make slight change to the Mediator to see how the failed transaction can be retried.
Lets create an entry in Orders.txt file with an item that doesn’t exist in ITEMS table. In my case, ITEMS table contains two items with IDs 1 and 2.
Lets create an order entry in Order.txt with ItemId 3.
When Order.txt is placed in file poller directory, as expected, transaction fails.
Click on Instance ID to go to process Flow Trace. We can see the transaction has failed because of Foreign Constraint violation.
We can’t retry this transaction. Lets slightly modify Order Router mediator to change this behaviour.
Open OrderRouter from composite.xml and go to Routing Rules section. Observe the both routing rules we defined earlier are “sequential” type. Change them to “parallel”. Click OK for any information dialogs you get in the process.
Redeploy the composite and copy same Order.txt file to the poller directory. Go the EM Dashboard and see deployed process instance. We can that it is in “Recovery Needed” state.
We can see the process instance is in “Recovery Needed” state instead of “Faulted”. Click on “Recover …” link at the bottom of the page as shown above.
Fault Trace shows the details of recoverable error. Click on error message to see error details. Below error message, we can see editable payload with an option to either Retry or Abort the transaction.
Change Item ID to 1 and Retry the transaction.
Go back to the Process Dashboard and click on Instance ID again to go to Flow Trace. We can see the transaction is successfully completed.
Though it solves bulk of our requirements, we may still want to refine fault handling by fault category. We also may want to extend fault handling to BPEL processes. In such cases, we can make use of Fault Management Framework.
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.
In the present lesson, lets see how Error Hospital can come to rescue. We will first run Human Workflow Example with incorrect values and see how transaction fails. Then, we will make slight change to the Mediator to see how the failed transaction can be retried.
Lets create an entry in Orders.txt file with an item that doesn’t exist in ITEMS table. In my case, ITEMS table contains two items with IDs 1 and 2.
Lets create an order entry in Order.txt with ItemId 3.
When Order.txt is placed in file poller directory, as expected, transaction fails.
Click on Instance ID to go to process Flow Trace. We can see the transaction has failed because of Foreign Constraint violation.
We can’t retry this transaction. Lets slightly modify Order Router mediator to change this behaviour.
Open OrderRouter from composite.xml and go to Routing Rules section. Observe the both routing rules we defined earlier are “sequential” type. Change them to “parallel”. Click OK for any information dialogs you get in the process.
Redeploy the composite and copy same Order.txt file to the poller directory. Go the EM Dashboard and see deployed process instance. We can that it is in “Recovery Needed” state.
We can see the process instance is in “Recovery Needed” state instead of “Faulted”. Click on “Recover …” link at the bottom of the page as shown above.
Fault Trace shows the details of recoverable error. Click on error message to see error details. Below error message, we can see editable payload with an option to either Retry or Abort the transaction.
Change Item ID to 1 and Retry the transaction.
Go back to the Process Dashboard and click on Instance ID again to go to Flow Trace. We can see the transaction is successfully completed.
Though it solves bulk of our requirements, we may still want to refine fault handling by fault category. We also may want to extend fault handling to BPEL processes. In such cases, we can make use of Fault Management Framework.
No comments:
Post a Comment