Retry-Policy Service

ActiveVOS Server User’s Guide

Retry-Policy Service

At times an endpoint may not reply when it is invoked in a BPEL process. In normal circumstances, the invoke faults. To avoid this, you can attach a policy to the endpoint reference in the PDD file to indicate that additional retry attempts are allowed at a specified interval for the endpoint. This technique is described in Endpoint References and WS-Policy.

Alternately, you can name a service in the policy section of the PDD file whose job it is to provide a retry interval, that you may want to calculate dynamically, and do additional work programmatically. The service could also specify an alternate endpoint to try when the invoke is faulting or suspended.

This service, which is a retry-policy service, is a BPEL process you can create and that the ActiveVOS server instantiates when an invoke activity is faulting (or suspended). The retry-policy BPEL process must be based on a WSDL named retryCheck.wsdl.

In essence, the WSDL defines the retryCheck operation, which receives information from the server regarding the fault name, process Id, and other details of the faulting invoke activity. The process you write is instantiated when the invoke activity faults (or can be suspended), and it receives an input message identifying details of the fault.

An input message sent to a retry-policy BPEL process would have the following parts:

<retryCheckInput

    xmlns="http://www.activebpel.org/services/retry">

   <faultName>{namespace}localpart</faultName>

   <processId>process id</processId>

   <processName>process name</processName>

   <invokePath>path of activity which is faulted</invokePath>

   <attempts>retry attempts already executed</attempts>

   <partnerLinkName>partner link used by invoke

    </partnerLinkName>

   <partnerLink>endpoint reference of partner link

    </partnerLink>

</retryCheckInput>

The process you write would send back a message to the server with the following parts:

<retryCheckOutput

    xmlns=http://www.activebpel.org/services/retry>

   <retry>yes or no indicating whether or not to retry</retry>

   <interval>number of seconds to delay if retrying</interval>

</retryCheckOutput>

The message you send back could also include an alternate service to try. The message to send back to the server would look similar to the following:

<retryCheckOutput

    xmlns=http://www.activebpel.org/services/retry>

   <retry>yes or no indicating whether or not to retry</retry>

   <interval>number of seconds to delay if retrying</interval>

   <wsa:EndpointReference xmlns="http://

      schemas.xmlsoap.org/ws/2003/03/business-process/"

      xmlns:ext="http://www.activebpel.org/bpel/extension"

      xmlns:ns1="http://www.activebpel.org/services

        /retrytests"

      xmlns:s="http://www.activebpel.org/

        services/retrytests"

      xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03

         /addressing"

       xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03

          /business-process/"

      xmlns:xsd="http://www.w3.org/2001/XMLSchema">

      <wsa:Address>ae:localhost:alternateRetryService

      </wsa:Address>

      <wsa:ServiceName PortName=

         "retryTesterServicePort">s:retryTesterService

      </wsa:ServiceName>

   </wsa:EndpointReference

</retryCheckOutput>

The process could do many other programmatic tasks, such as account for system downtime.

System Downtime

A service may have downtime for maintenance or for an unplanned event. In either case, it may be appropriate to use a retry-policy service to reschedule an invocation programmatically using BPEL activities.

Here are some general steps to consider when creating a retry-policy service.

To create a BPEL process to be used as a retry-policy service:

In the Project Explorer, create a new project.
Select File>New>BPEL Process.
Name the process and click Next.
On the Process Template page, select the Retry-Policy process template.
A new file opens on the Process Editor canvas with a ReceiveRetryCheck activity. The receive activity is based on the retryCheck operation.
Finish building the process, replacing the default retry and interval data in the Assign activity that you wish.
Launch the Process Deployment Descriptor wizard and on the Partner Links page, do the following:

Select the My Role partner link.
Type in a Service Name for the My Role partner link.

Start up the ActiveVOS server, and deploy the retry-policy process to the server. Note that in the BPR, there are no WSDL or XSD. They are already deployed and available on the server.
The retry-policy service name is important to remember. You must refer to it in the Retry Policy Assertion in the PDD file of the process containing the invoke activity targeted by the retry-policy BPEL process. In the Retry Policy Assertion dialog, be sure to specify the QName of the retry-policy process as shown in bold in the following example:

<wsa:EndpointReference

    xmlns:s="http://www.activebpel.org/services/retrytests">

  <wsa:ServiceName PortName=”retrytesterServicePort”>

    s:retryTesterService</wsa:ServiceName>

  <wsp:Policy

   xmlns:wsp=”http://schemas.xmlsoap.org/ws/

      2002/12/policy”

   xmlns:abp=”http://www.activebpel.org/policies”>

   <abp:retry service=”retryCheckerService”

     faultList="{http://xml.apache.org/axis/}*

        {http://www.active-endpoints.com/2004/06/bpel

           /extensions/}*

        {http://www.activebpel.org/services

           /retrytests}*"/>

  </wsp:Policy>

</wsa:EndpointReference>

Deploy the process to the server and use remote debugging to test that when the invoke faults, the retry-policy service executes.