This discussion is archived
6 Replies Latest reply: Feb 29, 2012 9:33 AM by Sridhar-SOA RSS

Guaranteed Delivery in BPEL

Naveen1215 Newbie
Currently Being Moderated
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.

Thanks,
NAveen
  • 1. Re: Guaranteed Delivery in BPEL
    Rolando Carrasco Explorer
    Currently Being Moderated
    Hi:

    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

    best
  • 2. Re: Guaranteed Delivery in BPEL
    Naveen1215 Newbie
    Currently Being Moderated
    Ronaldo,

    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.

    Thanks,
    Naveen
  • 3. Re: Guaranteed Delivery in BPEL
    Rolando Carrasco Explorer
    Currently Being Moderated
    Hi:

    Understood.

    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"?>
    <faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy">
    <faultPolicy version="2.0.1" id="SOAODI"
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns="http://schemas.oracle.com/bpel/faultpolicy"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Conditions>
    <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
    name="bpelx:remoteFault">
    <condition>
    <action ref="ora-retry"/>
    </condition>
    </faultName>
    <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
    name="bpelx:subLanguageExecutionFault">
    <condition>
    <action ref="ora-retry"/>
    </condition>
    </faultName>
    <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
    name="bpelx:bindingFault">
    <condition>
    <!--
    <test>not(contains($FaultVarLectura.detail,'Error while
    reading native data') or
    contains($FaultVarLectura.summary,'Error while
    translating'))</test>-->
    <action ref="ora-retry"/>
    </condition>
    </faultName>
    </Conditions>
    <Actions>
    <Action id="ora-retry">
    <retry>
    <retryCount>5</retryCount>
    <retryInterval>30</retryInterval>
    <retryFailureAction ref="ora-human-intervention"/>
    </retry>
    </Action>
    <Action id="ora-retry-crm-endpoint">
    <retry>
    <retryCount>5</retryCount>
    <retryFailureAction ref="ora-java"/>
    <retryInterval>5</retryInterval>
    <retrySuccessAction ref="ora-java"/>
    </retry>
    </Action>
    <Action id="ora-replay-scope">
    <replayScope/>
    </Action>
    <Action id="ora-rethrow-fault">
    <rethrowFault/>
    </Action>
    <Action id="ora-human-intervention">
    <humanIntervention/>
    </Action>
    <Action id="ora-terminate">
    <abort/>
    </Action>
    </Actions>
    </faultPolicy>
    </faultPolicies>


    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.

    best
  • 4. Re: Guaranteed Delivery in BPEL
    Naveen1215 Newbie
    Currently Being Moderated
    Hi ,
    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

    Thanks,
    Naveen
  • 5. Re: Guaranteed Delivery in BPEL
    robert224810 Explorer
    Currently Being Moderated
    Hi,

    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
    Robert
  • 6. Re: Guaranteed Delivery in BPEL
    Sridhar-SOA Newbie
    Currently Being Moderated
    Naveen,

    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,
    Sridhar.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points