AS4 pull destination overview

The pull destination is the message partition channel from which AS4 Microservice pulls the message response. In a two-way push pull or one-way pull message exchange, the messages that can be pulled by a trading partner are stored in the pull destination. For AS4 exchanges, you use a pull destination.

In a two-way push pull message exchange, when a push request is sent from an initiating message service handler (MSH), the receiving MSH unpacks the request and sends the business document object (BDO), message, payload, and attachments to the business application. The business application processes the push request, and sends a response message to the specified messaging receiver. The MSH picks the message from the messaging receiver and looks up for the exchange profile. As the exchange profile for the message is a pull exchange profile, the MSH associates the message with a pull destination that is specified in the exchange profile. If a pull destination is not specified in the exchange profile, the default pull destination is used.

The initiating MSH sends a pull request signal message. The pull destination from which the response must be pulled is specified in the pull request. The receiving MSH associates the pull request signal message with the pull response, based on the message information of the previously sent push request, and sends the related and correct response to the initiating MSH. The business application is notified that the message was successfully pulled from the pull destination.

In a one-way pull message exchange, the business application sends the message to be pulled to a specified messaging receiver. The MSH picks the message from the messaging receiver and looks up for the exchange profile. As the exchange profile for the message is a pull exchange profile, the MSH associates the message with a pull destination that is specified in the exchange profile. The receiving MSH receives the pull request signal message, and allows the message (submitted by the business application) to be pulled based on the pull destination and other details that are specified in the signal message.

The eb:Messaging/eb:UserMessage/@mpc: attribute in the ebMS message contains a URI that identifies the pull destination to which the message is assigned. If this element is not specified in the message, the default pull destination is used.

Resending pull request

For some reason if a trading partner does not receive the pulled message, the trading partner can send another pull request based on the reception awareness configuration (Number of retries and Interval for receipts fields) in the conformance policy. If receipts are configured and the owner organization does not receive a receipt from the trading partner, the message to be pulled is made available in the pull destination after the time specified in the Interval for receipts field. The trading partner can then send another pull request to pull the message.

Purging of messages in the pull destination

A message in the pull destination is purged based on one of the following parameters:
  • Expiration time stamp - An expiration time stamp is specified for the pull message that the business application submits to AS4 Microservice. The expiration time stamp is calculated based on the time when the message was created and the data retention period that is specified for the pull destination. A message in the pull destination is purged if the expiration time stamp is reached when the purge schedule runs.
  • Maximum number of pulls - The maximum number of pulls and the retransmission pull interval for a message depends on the reception awareness configuration in the conformance policy. The message in the pull destination is purged after a receipt is received for the pulled message or after the number of retransmissions (configured in the conformance policy) is exhausted.
    • If receipts are configured and a receipt is not received for a pulled message, the trading partner can send a pull request after the time specified in the Interval for receipts.
    • If receipts are configured and a receipt is received from the trading partner for a pulled message, the message is purged.
    • If receipts are not configured, the message is purged from the pull destination after the pull request is completed.

If a message in the pull destination is not pulled (or a receipt is not received) after the specified number of retransmission attempts, the message is purged when the purge schedule runs and a notification is sent to the business application.

Selective pulling

A specific message or several specific messages can be pulled from the pull destination based on the exchange profile configuration and a few parameters that are specified in a pull request.

If selective pulling is enabled in the exchange profile (by selecting Selective pulling) and a pull request is triggered by a scheduler, the pull request includes the following parameters:
  • Message partition channel name (pull destination)
  • Service
  • Agreement URI
If selective pulling is enabled in the exchange profile and a pull request is triggered by the business application, the pull request can include the following more parameters:
  • ConversationId
  • AgreementRef
  • Service
  • Action
  • RefToMessageId

A specific message or messages that match the parameters that are specified in the pull request are pulled.

Restriction: If a selective pull request is triggered based on a combination of ConversationId and RefToMessageId, pull responses are returned based only on the RefToMessageId.

Message pulling order

When a pull request is received and the pull destination contains multiple messages that match the parameters specified that are specified in the request, a message can be pulled based on the combination of the following criteria:
  • The earliest message or first in message
  • The least pulled message
The first in message that is pulled the least number of times is allowed to be pulled. The following example illustrates the pulling order.
Entry Creation time Number of times pulled Pulled
Entry 1 8:00 AM 1 No
Entry 2 9:00 AM 0 Yes
Entry 3 10:00 AM 2 No
Entry 4 11:00 AM 2 No
In the preceding example, though Entry 1 arrived earlier than Entry 2, Entry 2 is pulled because it arrived earlier than Entry 3 and Entry 4 and it was not pulled earlier.
Note: If receipts are configured for Entry 1, and a receipt is received for the pull response from the trading partner, Entry 1 is purged and is not available for pulling.