Configure a one-way client pull

About this topic

This topic describes options for configuring Activator as an AS4 pull client.

For an example of an AS4 pull server configuration, see AS4 use case: One-way pull (MMD initiated).


In order to correctly configure an AS4 client pull transaction, you must have a formal agreement of how you will exchange AS4 messages with the pull server. This agreement includes:

  • Message Partition Channel to use
  • Security requirements
  • Receipt requirements
  • Reliable messaging
  • Whether to support message splitting

Pull initiation options

With Activator, there are several ways to initiate an AS4 message pull from a remote server:

  • Scheduled pull – Scheduled pulls enable you to automatically poll remote server queues for messages to consume, at periodic intervals and for fixed numbers of pulls per specified interval of time.
  • MMD-initiated pull – Message Metadata Document (MMD) initiated pulls enable you to initiate a single remote server queue polling event by consuming a file from the back end system. This back-end MMD initiation can be done manually, for example by depositing a file to a directory, or may be the result of a programmed back-end system event that generates the MMD file.

Scheduled pull configuration

To schedule AS4 client polling, you work in the AS4 polling client Pickup/ Advanced tab.

On the Advanced tab you can set the following poll scheduling parameters:

  • Maximum pull requests per polling interval – The highest number of pull requests per polling interval, that the community can send to retrieve messages that are queued in the AS4 polling queue on the partner server. The polling interval is set in the "interval" field below.
  • Polling interval (seconds) – (Default = 60) The interval, in seconds, Activator waits between polling actions for messages to retrieve.

When you have set these poll scheduling parameters (along with the proper connection and enveloping information) the polling client will automatically execute pulls of available messages according to the settings. PullRequests are generated iteratively, as long as a user message or a message fragment is received in response to generated PullRequest. If an eb:Error is received in response to a pull request, then the remaining PullRequests in the cycle are not generated.

MMD-initiated pull configuration

To use an MMD to initiate the polling of a remote AS4 server queue:

  • Create an AS4 MMD with pull request metadata. The following file is an example of an AS4 pull request MMD:
  • In this example:
    • SignalType = PullRequest
    • The Message Partition Channel is explicitly specified. Each MPC is linked to a server queue, so this attribute identifies both the partition channel to use, and the queue to poll.
  • Configure Activator to consume AS4 MMDs from the back end network. One way to do this is with a file system type application pickup. See Add an application pickup.
  • Configure Activator to generate the AS4 pull request signal message from the MMD. To do this you configure Collaboration Settings (see AS4 default settings) and create an AS4 server Delivery (see Add an AS4 trading delivery).
  • Configure Activator to correctly handle the packaging and receipt requirements you have established with your trading partner (AS4 pull server).

The following figure illustrates an example of a pull-request processing sequence initiated by a back-end MMD.

Diagram showing example of a pull-request processing sequence initiated by a back-end MMD

In this figure the following events occur:

  1. Activator consumes an AS4 MMD from the back-end file system.
  2. Activator message handler analyzes the MMD and detects that it is an AS4 pull request.
  3. Activator applies AS4 collaboration settings and builds and packages the outbound AS4 signal message.
  4. Activator sends the AS4 pull request signal message to the server using the partner AS4 delivery exchange.
  5. The remote server receives the pull request. It checks the sender, receiver and MPC that are specified in the pull request, and if it finds a match, and if there are any queued messages in the corresponding queue, the server returns the first queued AS4 user message.
  6. If receipts are expected by the sender of the user message, and if "Generate receipts" is enabled on the AS4 trading pickup referenced by AS4.ResponseProcessingExchangePoint metadata in PullRequest MMD, then synchronous receipts are generated.

Message Participation Channel options

For a detailed description of Message Participation Channel selection, see Message Partition Channels (MPC).

Security options

In the Community Collaboration Settings, you can select several security options for packaging and sending AS4 messages:

  • Encrypt messagesActivator supports Triple DES and AES (128, 192, 256 bit) encryption algorithms for AS4 trading. On the receiving partner side, the encryption requirements are controlled in the Message Validation Rules (see Validation rules: Encryption tab).
  • Sign messagesActivator supports SHA1 and SHA256 signing algorithms for AS4 trading. On the receiving partner side, the signing requirements are controlled in the Message Validation Rules (see Validation rules: Signing tab).
  • Use username token when sending — Select this option to enable the use of username tokens to authenticate the sender of the PullRequest on the receiver side. After the sender of the Pullrequest is authenticated on the server side, the sender may be authorized (based on MPC in the PullRequest) to consume user messages queued for him.
  • If you select this option you must provide the required user name and password.
  • You can optionally select to use a password digest in place of plain text during authentication.

For additional information, see the Collaboration Settings section: AS4 default settings.

For additional information on user authentication and username tokens, see AS4 user authentication.

Reliable Messaging options

Activator supports the use of reliable messaging multiple retry features for AS4 message exchanges.

This is a feature that is configured on the AS4 Server side, enabling the server to make multiple attempts to respond to client pull request, in the event of a user message delivery failure in response to a pull request.

Message Splitting options

For detailed information on setting up message splitting, see Large message splitting and joining.

Related topics

Related Links