Scenario: Sending an AS4 outbound two-way push pull response

A two-way push pull message exchange pattern (asynchronous) is used when the receiver (responder or consumer) of the request requires more time to process the request (large documents) or the sender (initiator or producer) does not want to wait until the response arrives.

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

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

Your organization (owner organization A) submits (push request) tax returns for multiple clients in a single transmission (batch request) and expects to receive (pull request) the response later (at a scheduled time).
Your organization (owner organization A) submits (push request) a quotation to a trading partner (organization B), and receives (pull request) the response for the quotation later (at a scheduled time).

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 an AS4 outbound two-way push pull exchange profile configuration.

Table 1. AS4 outbound two-way push pull exchange profile configuration
Configuration	Requirement
Conformance policy	A conformance policy defines guidelines for secure and payload-agnostic exchanges. 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. 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 trading partner organizations, see Creating an organization.
Organization credentials	If user name token authentication is enabled in the conformance policy, you must configure organization credentials. When configuring connection settings for the outbound push request and outbound pull response, you must select appropriate organization credentials. For information about configuring organization credentials, see Adding organization credentials.
Message queue definitions	A message queue is required to configure a messaging receiver and error notification destination. A message queue must be configured by a System Administrator. For information about configuring a message queue, see Configuring a message queue.
Trading partner certificates	If signing is enabled for outbound exchanges, the response received from the trading partner is signed. You must add the public key of the certificate (shared by the trading partner) that is used to sign the response to B2B Advanced Communications. In an outbound exchange, the trading partner certificate is used to verify the signature of the response. For information about adding trading partner certificates, see Adding a trading partner digital certificate.
Owner organization certificates	If user authentication checking with X.509 certificate and signing of outbound exchanges are enabled in the conformance policy, the certificate alias must be added to B2B Advanced Communications and the public key must be shared with the trading partner. For information about adding CA certificates, see Adding a CA digital certificate. For information about adding private/public key pair, see Adding a private and public key pair digital certificate
Messaging receiver	You must configure the messaging receiver where the business application writes the business document object (BDO), message, payload, and attachments to trigger the outbound push request and outbound pull response. For information about configuring a messaging receiver, see Configuring a messaging receiver.
Error notification destination	If error notification is configured in the conformance policy, you must configure a notification queue to send errors to the business application. For information about configuring a notification queue for sending errors to the business application, see Configuring a messaging destination.
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 HTTPS destination. For information about configuring a thread pool, see Configuring a thread pool
HTTP or HTTPS destination	The trading partner destination where the outbound push and pull requests are sent. For information about configuring an HTTPS or HTTP destination, see Configuring an HTTP or HTTPS destination.
Retry policy	You must configure the 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 during the transmission. For information about creating a retry policy, see Configuring a retry policy.
Storage settings	You must configure appropriate and required storage settings. For information about configuring storage, see Configuring storage.
Pull destination	You must specify the message partition channel name (pull destination) in the Outbound Pull Response section of the outbound two-way push pull exchange profile. The response is pulled from the specified pull destination. The owner organization and the trading partner organization exchange the message partition channel names offline. For information about configuring a pull destination, see Configuring an AS4 pull destination

The following table lists the user permissions that are required to complete the AS4 outbound two-way push pull exchange.

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

Creating a sample AS4 outbound two-way push pull exchange profile

To create an exchange profile that can be used to submit (push) tax returns for multiple clients in a single transmission and to receive (pull) the response later at a required time, you must complete the following tasks in B2B Advanced Communications:

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

Note: This procedure assumes that the following components are created in B2B Advanced Communications:

Message queues
Thread pool
Messaging receiver - batchlodge_msgrcvr
Retry policy - orgBretrypolicy
HTTPS destinations - batchlodge_dest, batchlodge_rcptdest, and batchlodge_errordest
Participating organizations - Organization A and Organization B
Organization credentials - batchlodgeuser and associated with Organization A (master org)
Certificate alias of Organization A - orgacertalias (usage - HTTPS client authentication and signing/signature verification)
Certificate alias of Organization B - orgbcertalias (usage - HTTPS client authentication and signing/signature verification)
AS4 receiver - batchlodge_as4rcptrcvr and batchlodge_as4errorrcvr.

Log in to B2B Advanced Communications with Master Account Permissions.
Click Exchanges > Exchange Profiles.
On the Exchange Profiles page, click New and select AS4 Outbound.

On the New Exchange Profile dialog box, specify values for the following fields and click Save.

Field	Description
Profile name	Type `batchlodgeprofile` as the profile name.
Choose a conformance policy	Select Default EbHandler PMode Conformance Policy. Configuration of the Default EbHandler PMode Conformance Policy is as follows: User authentication is enabled with user name token and X.509 certificate. Password type for user name token authentication is password digest. Signing is enabled for outbound and inbound exchanges. Receipts and Retries are configured. Error reporting to the trading partner, Organization B) and error notification to the business application are configured.
Select the message exchange pattern for the profile	Select AS4 Outbound Two-Way/Push-Pull message exchange pattern from the Exchange pattern list.

Click Edit corresponding to the Basic Properties section, specify values for the following fields, and click Save.

Field	Description
Name	The name, `batchlodgeprofile`, that you entered in the Profile name field is populated here.
Description	Optional: Type `exchange profile for batch lodging tax returns` .
Service	Type `batch tax returns`.
Agreement URI	Optional: Type `http://registry.example.com/cpa/123456`. The agreement URI is the location of the agreement (related to the p-mode parameter configuration and operation) between your organization (Organization A) and the partner (Organization B). The URI must be agreed on by both the partners.
P-Mode ID	Optional: Type `batchreturnspmodeID` The mutually agreed on p-mode ID is used to identify the p-mode configuration of the conformance policy.

Click Participating Organizations to specify the participating organizations.

Field	Description
Owner Organization	The owner organization is specified by default from the owner organization in the conformance policy of the exchange profile.
Sender ID	Click New and type `orgA`.
Trading Partner Organization	Click Select and select Organization B.
Receiver ID	Click New and type `orgB`.

Click Outbound Push Request and specify Trigger and Action settings for the outbound push request.

Field	Description
Receiver	Click Select and select batchlodge_msgrcvr to receive BDO, payload, message, and attachments from the business application.
Destination	Click Select and select batchlodge_dest to send the push request.
Configure connection	Click Configure and complete the following steps: Authentication - Click Select and select batchlodgeuser. Select AS4 receiver to which ebMS Receipt Signal messages are sent by Trading Partner - Select batchlodge_as4rcptrcvr. Select AS4 receiver to which ebMS Error Signal messages are sent by Trading Partner - Select batchlodge_as4errorrcvr. Click OK to save the connection settings.

Click Outbound Pull Response and specify Trigger and Action settings for the pull response.

Field	Description
No. of Attempts	Type `5`. If a pull request fails to reach Organization B, Organization A tries five times to send the pull request. The number of attempts must be agreed on with your partner.
Interval	Type `2` and select hours. If a failure occurs, Organization A waits for 2 hours to send another pull request.
Pull MPC Name	Type `batchlodgepulldest`. The pull destination is agreed on with your partner.
Destination	Click Select and select batchlodge_dest to send the pull request.
Connection settings	Click Configure and complete the following steps: Authentication - Click Select and select batchlodgeuser. Sign Verification - Select orgbcertalias from the drop-down list. Organization A verifies the signature of the pull response using orgbcertalias. Select Trading Partner's HTTP(S) destination to which ebMS Receipt Signal messages are sent - Select batchlodge_rcptdest. Select Trading Partner's HTTP(S) destination to which ebMS Error Signal messages are sent - Select batchlodge_errordest. Click OK to save the connection settings.

In the Deploy Exchange Profile section, click Deploy to deploy or enable the exchange profile.
Attention: The Deploy button is enabled only when all the sections of the exchange profile are in Complete status.

Using batchlodgeprofile to send a push request to lodge tax returns

The following list describes the steps that are involved in sending a push request from Organization A to Organization B to lodge tax returns:

The business application sends a BDO, payload, attachments, and message to lodge tax returns to batchlodge_msgrcvr.
batchlodge_msgrcvr uses the information (such as the sender ID, receiver ID, service, and protocol) in the BDO to look for batchlodgeprofile and starts the AS4 sender service.
The AS4 sender service retrieves the information that is required to package the message, payload, and attachments from batchlodgeprofile and packages the message.
The transport service in the AS4 sender service uses the HTTP or HTTPS destination information in the exchange profile, starts the HTTPSender service and sends the message to batchlodge_dest.
The AS4 receiver of Organization B receives the push request (tax return forms) and sends an HTTP 200 OK message to Organization A.
As the conformance policy configuration requires receipts, Organization B sends a receipt (eb:Signal message) to Organization A (batchlodge_as4rcptrcvr).

Using the AS4 two-way push pull exchange profile to send a pull request to receive response for the tax returns

The following list describes the steps that are involved in sending a pull request from Organization A to Organization B to receive response for the push request:

After two hours (as specified in the pull trigger of batchlodgeprofile), the message service handler of Organization A triggers a pull request.
The AS4 sender service retrieves the information that is required to create a pull request.
The transport service in the AS4 sender service uses the HTTP or HTTPS destination information in the exchange profile, starts the HTTPSender service and sends the pull request to batchlodge_dest.
The AS4 receiver of Organization B receives the pull request, retrieves the response message (for the push request) based on the pull destination (batchlodgepulldest) specified in the pull request, packages the message and sends it to Organization A.
After successfully receiving the response message (for the lodged tax return forms) from Organization B, the message service handler of Organization A sends a receipt to organization B (batchlodge_rcptdest).
The response message is unpacked and the BDO, message, payload, and attachments are sent to the business application queue from which the business application picks it up.