Scenario: Receiving an AS4 inbound two-way push pull response

A two-way push pull message exchange pattern (asynchronous) is used when the receiver (of the request) requires more time to process the request or the sender does not want to (or cannot) stay idle until the response arrives.

In a two-way push pull exchange, the sender is not blocked or idle until the request is processed and an appropriate response is received.

The following scenarios demonstrate two use cases for the AS4 inbound two-way push pull exchange pattern:

Organization A receives multiple tax returns (batch lodge) from organization B. As it is a batch lodge, organization A needs more time to process the request, and organization B cannot hold on the resources until the processing is complete. Organization B submits the tax returns through a push request, and later, at a scheduled time triggers a pull request to receive the response for the returns.
Organization A receives (push request) a quotation from organization B. After a scheduled and agreed on time interval, organization B triggers a pull request to receive the response for the quotation.

Note: If Sterling B2B Integrator is the business application, you must install the Sterling B2B Integrator bridge and configure the required adapters and business processes. For more information about Sterling B2B Integrator bridge adapters and business processes, see Configuring B2B Advanced Communications integration module.

Configuration requirements

The following table provides information about the configuration that is required to complete an AS4 inbound two-way push pull exchange.

Table 1. Configuration required to complete an AS4 inbound two-way push pull exchange
Configuration	Requirement
Conformance policy	You must define the security, error handling, and reception awareness settings. For more information about configuring a conformance policy, see Configuring custom AS4 conformance policies.
Organizations	You must configure owner and trading partner organizations that are participating in the exchange. The owner organization is specified by default from the owner organization in the conformance policy of the exchange profile. For information about configuring a trading partner organization, see Creating an organization.
Organization credentials	If user name token authentication is enabled, you must configure organization credentials. For information about configuring organization credentials, see Adding organization credentials.
Message queues	A message queue must be configured by a System Administrator. A Master Account Administrator can use the message queue definition when creating an error notification destination. You can also choose to use the default error notification destination. For information about configuring message queues, see Configuring a message queue.
Trading partner certificates	If signing is enabled for inbound exchanges, the push and pull requests, and the receipt received from the trading partner is signed. You must add the public key of the certificate (shared by the trading partner) to B2B Advanced Communications. The certificate is used to verify and validate the signature of push and pull requests and the receipt. For information about configuring trading partner certificates, see Adding a trading partner digital certificate.
Owner organization certificates	If user authentication checking with X.509 certificate is enabled, you must add the required certificate alias to B2B Advanced Communications and share the public key with the trading partner. For information about configuring owner organization certificates, see Adding a CA digital certificate and Adding a private and public key pair digital certificate
Thread pool	A thread pool is a collection of threads. A thread pool manages the threads in the pool to process the tasks. To handle large volumes of files or large files, you can have a thread pool with more threads and associate the thread pool to the AS4 receiver. For information about configuring a thread pool, see Configuring a thread pool
Retry policy	You must configure appropriate retry policy and associate it with the HTTP or HTTPS destination. The retry settings that are specified in the retry policy are used when an HTTP or HTTPS destination is not available (down) during the transmission. For information about configuring a retry policy, see Configuring a retry policy.
HTTP or HTTPS server	An HTTP or HTTPS server is an endpoint that is associated with an AS2 or AS4 receiver. For information about configuring an HTTP or HTTPS server, see Configuring an HTTP server or Configuring an HTTPS server
AS4 receiver	You must configure an AS4 receiver to receive the push and pull requests. For information about configuring an AS4 receiver, see Configuring an AS4 receiver
Messaging destination	You must configure the messaging destination where B2B Advanced Communications sends the unpacked message data. For information about configuring a messaging destination, see Configuring a messaging destination
Messaging receiver	You must configure the messaging receiver where B2B Advanced Communications receives the response (for the push request) from the business application. For information about configuring a messaging receiver, see Configuring a messaging receiver.
Pull destination	You must configure a pull destination from where the trading partner pulls the response for the push request. For more information about creating a pull destination, see Configuring an AS4 pull destination.
Error notification destination	A messaging destination that is used to notify errors (if any) during the push or pull requests to the business application. For information about configuring a messaging destination, see Configuring a messaging destination
Storage settings	You must configure appropriate and required storage settings. For information about configuring storage, see Configuring storage.

The following table lists the users permissions that are required to complete an AS4 inbound two-way push pull exchange.

Table 2. Permissions required to complete an AS4 inbound two-way push pull exchange
User permission	Requirement
User with Master Account Administrator permissions	To create or configure the following components: Conformance policy AS4 inbound two-way push pull exchange profile Messaging receiver and destination Certificate alias (both trading partner certificates and owner organization certificates) HTTP or HTTPS server AS4 receiver Organization credential Trading partner and owner organization Retry policy Pull destination
User with System Administrator permissions	To create message queue and thread pools.

AS4 inbound two-way push pull exchange profile configuration

To create an exchange profile (batch lodge inbound) that can be used to receive (push request) tax returns for multiple clients in a single transmission and to receive the pull request and send a response to organization B, you must complete the following tasks in B2B Advanced Communications:

Note: The following list provides information about the mandatory fields or configuration that is required for an AS4 inbound two-way push pull exchange profile. For information about other fields, see Configuring an AS4 inbound two-way push pull exchange profile.

Profile name – A unique name for the exchange profile. For example, batch lodge inbound.
Conformance policy – A conformance policy defines guidelines for secure and payload-agnostic exchange. Depending on the agreement with your trading partner, you can use the default conformance policies or create a custom conformance policy. If you are using a custom conformance policy, check if the conformance policy is configured. You can configure a new custom conformance policy, or use the default conformance policy to configure a custom conformance policy.
Service details – A service defines the usage of the exchange profile. You must know the service for which the exchange profile is used. In this case, specify batch tax lodging as the service.
Owner organization configuration – In an inbound two-way push pull flow, organization A is the owner organization that receives the push request from the trading partner. Role of the organization A is consumer-responder.
Receiver ID – Receiver ID is a unique identifier that is used to identify organization A (owner organization) that receives the push request. Specify the mutually agreed on receiver ID in the Receiver ID field.
Trading partner configuration – Select the trading partner organization (organization B) that sends the push request (submitting tax return forms). Role of the organization B is provider-initiator.
Sender ID – Sender ID is a unique identifier that is used to identify organization B (trading partner). Specify the mutually agreed on sender ID in the Sender ID field.
AS4 receiver - Organization B sends the push request to the AS4 receiver configured in the inbound two-way push pull exchange profile. You must configure the required connection settings for the AS4 receiver.
Messaging destination - Messaging destination is the queue where the AS4 message service handler sends the unpacked push request.
Messaging receiver – Messaging receiver is the queue where the business application writes the response (pull response) to the push request. The AS4 message service handler picks the response and completes the necessary.
Pull destination or message partition channel - A pull destination from where the trading partner pulls the response for the push request.

Using an AS4 inbound two-way push pull exchange profile to receive a push and pull request

The following list describes the steps that are involved in receiving a push request from organization B (trading partner) to lodge tax returns:

The AS4 receiver that is configured in Inbound Push Request section of the batch lodge inbound exchange profile (of B2B Advanced Communications) receives a push request (tax return forms) from organization B. The push request is an ebMS message that consists of the payload and attachments.
The message service handler (MSH) unpacks the ebMS message and sends the unpacked message to the messaging destination specified in the inbound exchange profile.
The business application picks the BDO, payload, and the attachments from the messaging destination, completes the necessary processing, and sends a response to a message queue. B2B Advanced Communications picks the response from the queue and stores it in the pull destination that is specified in the inbound exchange profile.
The AS4 receiver sends an HTTP 200 OK message to the sending B2B Advanced Communications (organization B). Based on the reception awareness configuration (in the conformance policy), the AS4 receiver might send a receipt (eb:Signal message) to organization B synchronously or asynchronously.
Based on the scheduler configuration (or manual trigger), organization B sends a pull request. The AS4 receiver (of organization A) receives the pull request, retrieves the pull response from the message partition channel (pull destination) specified in the exchange profile, packages it according to the exchange profile and conformance policy settings and sends it to organization B.