Message Exchange Patterns

Selective-Pull

The selective pull feature pulls a subset of messages posted on Message Partition Channels (MPC). The initiating Messaging Service Handler (MSH) sends a pull signal to the responding MSH along with a pull criteria by using requestSM. The responding MSH uses requestSM parameters to match the messages present in the MPC and sends back the first matching message as a response by using requestUM. A business application initiates a Selective pull mechanism by providing simple selection item or complex selection item parameters in the service.

Simple selection, complex selection or both are used to pull messages from an MPC.

One-Way/Pull MEP - AS4 acting as initiating MSH

When you want AS4 to play the role of initiating MSH, webMethods B2B Integration uses the mpc and pmodeId input parameters that are passed to constructSubmitInput service to fetch the appropriate TPA and identify the messaging parameters for the transfer.

The parameters that are specified in the requestSM leg of the TPA are used to generate the pull signal and identify the address of the responding MSH. When the user message is received as a response to the pull signal, webMethods B2B Integration uses the requestUM leg of the TPA to process the user message.

One-Way/Pull MEP - AS4 acting as responding MSH

In a One-Way/Pull MEP, the message is stored in a Message Partition Channel (MPC) instead of being pushed to the recipient. The recipient pulls it when ready.

To submit the message, use the constructSubmitInput service, which packages the payload by using parameters ReceiverID, ReceiverIDType, ', SenderIDType, and pmodeID. If pmodeID is empty, a tuple of ReceiverID, toRole, SenderID, fromRole, service, action, and agreementRef input parameters are used to locate the appropriate TPA.

The TPA provides messaging parameters, including the MPC location under legs/businessInfo/mpc in the requestUM leg, where the message is stored.

When a pull signal is received, AS4 determines which TPA to use to process the pull signal by matching the MPC named in the pull signal with the MPC named in the requestSM leg of each TPA that is configured in webMethods B2B Integration. The matching MPC is used to process the pull signal. AS4 retrieves the user message from the MPC specified in the pull signal and sends it to the initiating MSH. If no MPC is specified in the pull signal, AS4 uses the default MPC to pull the user message.

AS4 uses the webMethods B2B Integration database as the MPC queue. When a user message is queued, the message is stored in webMethods B2B Integration with a UserStatus of QUEUED, and the corresponding bizDocId is cached. When a pull signal is received, the module first retrieves the bizDocId from the cache First In - First Out, and then retrieves the user message that corresponds to this bizDocId from webMethods B2B Integration. The retrieved message is then sent to the initiating MSH.

Two-Way/Sync MEP - AS4 acting as initiating MSH

When you want AS4 to play the role of initiating MSH, the Two-Way/Sync transfer is initiated by webMethods B2B Integration.

The parameters that are specified in the requestUM leg of the TPA are used to generate the user message and identify the address of the responding MSH. After webMethods B2B Integration receives a reply, it uses the replyUM leg of the TPA to process the user message.

If webMethods B2B Integration does not receive a response within the time-period that is defined in the AS4 configuration, an error message is generated by the initiating MSH.

Two-Way/Sync MEP - AS4 acting as responding MSH

When you want AS4 to play the role of responding MSH, use the constructSubmitInput service to submit a reply user message to the corresponding request user message by setting the sync flag to true. The refToMessageId of the reply user message should be set to the request user message's MessageId value. AS4 uses the requestUM leg of the TPA to process the request user message and sends the reply to the initiating MSH.