Systemic Quality: Redelivery in the BPEL SE.
The bpel-se uses factory/helper methods provided in the common library "Quality of Service" (QoS) to generate redelivery configuration and status objects. These classes are then used to configure the redelivery protocol implementation in the common library.
Overview of Redelivery Rules.
- Redelivery support in the common library consists of two separate pieces:
- An API that allows components to define and query redelivery configuration and status information.
- An implementation of the redelivery wire quality protocol.
- Unique Message ID
- Redelivery processing depends on the presence of a unique message id as a "standard" property on each message exchange.This message id is defined in QoS api ServiceQuality as
public static final String MESSAGE_ID = "com.sun.jbi.messaging.messageid";
- Redelivery parameters can be defined via QoS extensions in the service assembly jbi.xml. The redelivery implementation in the library automatically parses an endpoint's associated jbi.xml to determine QoS.
- Redelivery status can also be reset if redelivery attempts have been exhausted. A component might use this feature if it wanted to restart the redelivery protocol in response to some user-initiated action.
- Error Endpoint and Delete behaviors are limited to InOnly message exchange patterns. The Suspend behavior may be used with InOnly or InOut.
Redelivery configuration example
<consumer endpoint-name="redeliverPTRole_partnerRole" service-name="ns1:redeliverPL" />
<provider endpoint-name="javaee_port1" service-name="ns2:redeliverService" />
<qos:consumer endpoint-name="redeliverPTRole_partnerRole" service-name="ns1:redeliverPL" />
<qos:provider endpoint-name="javaee_port1" service-name="ns2:redeliverService" />
<rd:redelivery maxAttempts="2" waitTime="1000">
<rd:redirect endpoint-name="JmsServicePort" operation="JmsOper" service-name="ns1:JmsService"/>
Redelivery functionality in the BPEL SE.
Redelivery configuration settings.
The user configures the bpel-se endpoint for redelivery through the CASA editor as shown in the configuration example above. The user can set the following redelivery parameters.
- 'maxAttempts' : number of retries to attempt .
- 'waitTime' : time to wait between redelivery attempts in milliseconds.
- on-failure : type of action to be taken when redelivery attempts have been exhausted.
on-failure has three options that the user can configure.
This option is supported only for InOnly ME. This implies that after the redelivery attempts have been exhausted the ME is simply deleted by the QoS utility and a 'Done' status is send back to the bpel-se, on which the bpel process proceeds with the next activity.
This option is supported for InOnly ME. The user would need to configure the 'endpoint'
as the additional field. This implies that after the redelivery attempts have been exhausted the QoS utility would send the ME to the configured endpoint (ex: like a dead letter queue).
This option is supported for InOnly and InOut ME. This implies that after the redelivery attempts have been exhausted the bpel-se would have to suspend the instance of the bpel process. Suspend is only supported if monitoring is enabled in the bpel-se, since the user has to use the monitoring tool to resume a suspended instance.
This option is supported for InOnly and InOut ME. This is the default on-failure configuration in the event that user having defined the redelivery configuration may choose to not define the on-failure for this redelivery configuration.
Deployment of the configured service unit.
- The bpel-se uses an instance of the QoS api 'com.sun.jbi.common.qos.messaging.MessagingChannel' as the 'DeliveryChannel' implementation. The channel has as an interceptor/wrapper that provides QoS capabilities and delegates to the actual 'DeliveryChannel' the messaging requirements.
- On deployment an instance of 'com.sun.jbi.common.qos.descriptor.DeploymentLookup' is used within the component context to retrieve the configured QoS qualities for this SU.
- The redelivery configuration 'com.sun.jbi.common.qos.redelivery.RedeliveryConfig' is retrieved for each endpoint in the deployed process.
- The retrieved redelivery configuration for each endpoint is initialized with the QoS utility by way of the api's of the 'MessagingChannel'.
Runtime execution of redelivery.
For illustrative purposes, let us assume that user has configured the redelivery parameters as
'maxAttempts' : 2
'waitTime' : 1000ms
and for the 'on-failure' let us consider the three options.
- delete (applicable only for InOnly ME, ex one-way invoke).
The bpel-se will send and resend the ME till a 'Done' status is received for the ME. The QoS utility will attempt to deliver the message to the actual provisioning endpoint till the 'maxAttempts' count has been exhausted. It returns an 'Error' status for each failed attempt back to the bpel-se, which will resend the ME. Finally on exhausting the 'maxAttempts' count the QoS utility will abandon the ME and return 'Done' status to the bpel-se, which will continue execution of the process instance.
- redirect (applicable only for InOnly ME, ex one-way invoke).
For the bpel-se the behavior for this configuration is similar to the one for the 'delete' case above. The difference being that the QoS utility will route the ME to the configured redirect endpoint when the 'maxAttempts' count has been exhausted, if the QoS utility is successful in routing the message to the redirect endpoint a 'Done' status is returned to the bpel-se if not an 'Error' status is returned.
The QoS utility in this case will always return a 'Error' status to the bpel-se if it is not able to deliver the ME to the actual provisioning endpoint. The bpel-se before re-sending the ME to the QoS utility will use the QoS utility api 'com.sun.jbi.common.qos.redelivery.RedeliveryStatus'
to check if the 'hasFailed'
api returns a false boolean value. If the 'hasFailed' api returns a true boolean value the bpel-se will suspend the process instance, only if the monitoring for the bpel-se is enabled. This requirement ensures that the user will be able to resume the instance once its suspended.
The QoS in this case will always return a 'Error' status to the bpel-se if it is not able to deliver the ME to the actual provisioning endpoint. The bpel-se before re-sending the ME to the QoS utility will use the QoS utility api 'com.sun.jbi.common.qos.redelivery.RedeliveryStatus'
to check if the 'hasFailed'
api returns a false boolean value. If the 'hasFailed' api returns a true boolean value this indicates that the retries have been exhausted and the bpel-se should throw an Exception.
- on-failure options of 'delete' and 'redirect' cannot be applied to InOut ME, because the InOut ME requires a response to be received for the process instance to proceed further and hence the return value for these options would not suffice.
- if the on-failure condition is not specified in the jbi.xml for the redelivery configuration, the default will be the 'error' configuration.
Click Here for how to configure a BPEL endpoint for redelivery.