Can any one please help me in the design of this BPEL Process.
1) Consumer invokes the BPEL. BPEL validates the XML and sends an acknowledgement to the consumer. After sending an acknowledgment its the responsibility for the BPEL to deliver the message to the target service. So, whenever the target service is down or when the target sends out an negative acknowledgement, its BPEL responsibility to deliver the message. Can anyone please help me how to structure the BPEL Process.
One way to deal with the remote exceptions, and re-try the same call several times, every N seconds, is to use the Fault Management Framework. Within the framework, u can specify if a given Exception happens, u will handle it in a special way.
Pls take a look to this documentation http://docs.oracle.com/cd/E17904_01/integration.1111/e10224/bp_faults.htm
If the Target Service responds with a business error, then u need to read it within the bpel process, and manage it , in the way u need it.
hope this helps
Thank for your reply. Actually my business requirement is that when ever we are not able to deliver the message to the target service. The message should not be lost. We should redeliver the message at a later point of time when the target service is up and running.
Well, definitely the Fault Management Framework will do the job.
U can specify the amount of times to retry, the interval (in seconds), and if at the end it couldn't consume the Service, u can send that transaction to a manual recovery, so u never lost a message.
Here is an abstract from a policy file:
<?xml version="1.0" encoding="UTF-8"?>
<faultPolicy version="2.0.1" id="SOAODI"
reading native data') or
So, as u can see, the "retry" action will do it 5 times, every 30 secs, if it couldn't make it, it will send it to a manual recovery.
If u don't want the manual recovery, u can implement something else, or simply rethrow the fault , and try another 5 time (or any number).
Hope this helps.
Thanks for your reply.
The major concern is that there will be many transactions per seconds. So when the target system gets up again its not manually possible to recover all the transactions from the em console. Is there any alternative design approach
Our approach to this is to use queues. We started looking at JMS queues but have ended up moving to AQ's (via JMS) because we have a cluster setup.
We set our BPEL transactions to roll back to the queue on failure and the retries are done from the queues. After all the retries have occured the messages get put on an Exception queue.
It is the possible to build another process which takes the message from the Exception queue and this can be done individually or in bulk
We can configure Automatic recovery `for BPEL instances that failed in invoke,callback or any other time bound activities ( like wait , onAlarm in pick etc..)which failed to execute on the threshhold time.
In your case, lets say your code( instance) is calling target service via invoke and failed due to some error ( network error) and like wise multiple instances ( multiple transactions) failed. In this case, the automatic recovery will recover all the transactions that failed based on your recovery schedule. Infact you can set properties to limit maximum number of time as message can be submitted for recovery (MaxRecoverAttempt - property available in Mbean section for BPEL) and also maxMessageRaiseSize to some value to limit total number of messages per activity per each recovery.
For more clarity. Refer - http://docs.oracle.com/cd/E25054_01/admin.1111/e10226/bp_config.htm
Thanks and Regards,