Monday, May 4, 2015

#397 SOA 12c Fault Handling

Here is my composite - a Sync BPEL process, invoking a web service -

The web service validates a credit card nr and returns "invalid" for those starting with 123.
I deploy and test -

Looks good!

I now stop the web service -

I re-test the BPEL process -

I get the following error, which is to be expected  -

I now look in the EM Error Hospital -

The error is marked as non-recoverable, this is because the
error occurred on the Invoke thread. i.e. Error needs to be handled by
calling client.

I re-start the web service.
I add a dehydration activity to the process and re-deploy -

I test - all goes well!
I then stop the web service and re-test.

I see the expected error -

I check the error hospital -

I see 1 recoverable fault.

Using Fault Handlers and their effect on the Error Hospital

I deploy and test, having stopped the ws.

I see 2 error messages -
1. remoteError
2 -Timeout for sync req-response

I check out the error hospital -

Now let's try the same with an Async process -

I deploy and test, stopping the ws beforehand -

I check out the error hospital -

I see one instance awaiting recovery.

However, if I search for the instance at composite level, it looks as if
it completed successfully -

I need to check the audit trail to see the error -

Now I remove the CatchAll from the process and re-deploy and
then execute 2 tests -

I see the errored instances, at Composite level -

I check out in the error hospital -


Antonio Aliberti said...

do you have any explanation why is needed a dehydrate palette in order to have a recoverable fault?


Niall Commiskey said...

So that the instance state is persisted, giving us something to recover.

Niall Commiskey said...
This comment has been removed by the author.