Scenario: Receiving an AS4 inbound one-way pull request

The responding message service handler uses the inbound one-way pull exchange profile to receive and process the ebMS pull signal message. In a one-way pull exchange, it is not required for one of the partner systems to have HTTP server capability. Having HTTP client capability is sufficient to configure and use the one-way pull exchange pattern.

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

• Your organization (owner organization A) receives a pull request (from the trading partner - organization B) checking the status of the tax returns that were submitted earlier.
• Your organization (owner organization A) receives a pull request (from the trading partner - organization B) checking the status of an order that was placed earlier.

Configuration requirements

The following table provides information about an AS4 inbound one-way pull exchange profile configuration.

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. 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 you configure the connection settings for an inbound pull request, you must select appropriate organization credentials.

For information about configuring organization credentials, see Adding organization credentials.

Message queues

A message queue is required to configure a messaging receiver and messaging 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 inbound exchanges, the pull request that is 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 request to B2B Advanced Communications. In an inbound exchange, the trading partner certificate is used to verify the signature of the pull request.

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 inbound exchanges is 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 to which the business application writes the business document object (BDO), the message to be pulled, and the payload.

For information about configuring a messaging receiver, see Configuring a messaging receiver.

Pull destination

You must configure the pull destination from where the message is pulled. The pull destination is equivalent to the message partition channel (MPC).

For information about configuring a messaging destination, see Configuring an AS4 pull destination.

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.

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.

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 files or a large volume of files, you can have a thread pool with more number of threads and associate the thread pool to the HTTPS destination.

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.

AS4 receiver

You must configure an AS4 receiver to receive the pull request.

For information about configuring an AS4 receiver, see Configuring an AS4 receiver.

Storage settings

You must configure storage settings, including data retention and divulge information. For information about configuring storage, Configuring storage.

The following users permissions are required to complete an AS4 inbound one-way pull exchange:

User with Master Account Administrator permissions

A Master Account Administrator can create or configure the following components:

• Conformance policy
• AS4 inbound one-way pull exchange profile
• Messaging receiver and destination
• Certificate alias (both trading partner certificates and owner organization certificates)
• HTTP or HTTPS server
• AS4 receiver
• Retry policy
• Organization credential
• Trading partner and owner organization
• Pull destination

User with System Administrator permissions

A System Administrator can create or configure message queue and thread pools.

Creating a sample AS4 inbound one-way pull exchange profile

The following steps describe how to configure an AS4 inbound one-way pull exchange profile. For information about other fields, see Configuring an AS4 inbound one-way pull exchange profile.

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

• Message queues
• Messaging receiver - inboundstatuscheck_msgrcvr
• Pull destination - inboundstatuscheckpulldest
• AS4 receiver - inboundstatuscheck_dest, inboundstatuscheck_rcptdest, and inboundstatuscheck_errordest
• Participating organizations - Organization A and Organization B
• Organization credentials - inboundstatuscheckuser and associated with Organization A (the owner organization)
• Certificate alias of Organization A - OrganizatoinAcertalias, for HTTPS client authentication and signing/signature verification
• Certificate alias of Organization B - OrganizationBcertalias, for HTTPS client authentication and signing/signature verification

To create an exchange profile that can be used to check the status of the previously submitted tax returns:

1. Log in to B2B Advanced Communications as a Master Account Administrator.
2. Click Exchanges > Exchange Profiles.
3. On the Exchange Profiles page, click New and select AS4 Inbound.
4. On the New Exchange Profile dialog box, specify values for the following fields and click Save.

   Profile name

   Enter inboundstatuscheckprofile 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:

   1. User authentication is enabled with user name token and X.509 certificate. The password type for user name token authentication is password digest.

   2. Signing is enabled for outbound and inbound exchanges.

   3. Receipts and retries are configured.

   4. 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 Inbound One-Way/Pull message exchange pattern.

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

   Name

   The name that you entered in the field Profile name, inboundstatuscheckprofile, is populated here.

   Description

   Optional: Enter inbound exchange profile for checking status of tax returns.

   Service

   Enter inbound checking status of tax returns.

   Agreement URI

   Optional: Enter 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.

   If selective pulling is enabled, agreement URI and service are used along with the message partition channel to pull specific messages.

   P-Mode ID

   Optional: Enter inboundstatuscheckingpmodeID

   The mutually agreed on p-mode ID is used to identify the p-mode configuration of the conformance policy.

6. Click Participating Organizations to specify the participating organizations.

   Owner Organization

   The owner organization is specified by default from the owner organization in the conformance policy of the exchange profile.

   Receiver ID

   Click New and type orgA.

   Trading Partner Organization

   Click Select and select Organization B.

   Sender ID

   Click New and type orgB.

7. Click Inbound Pull Document Submit Configuration and specify Trigger and Action settings for the inbound pull request.

   Receiver

   Click Select and select inboundstatuscheck_msgrcvr to receive the BDO, payload, and message to be pulled from the business application.

   Select destination

   Click Select and select inboundstatuscheckpulldest the pull destination from where the message is pulled.

   Connection

   Click Configure and complete the following steps to configure connection settings for the outbound pull request:

   1. Authorization - Select Enable user authentication check box, andSelect select inboundstatuscheckuser.
   2. Signature - Select OrganizationBcertalias to verify the signature of the inbound pull request.
   3. Click OK to save the connection settings.

8. In the Deploy Exchange Profile section, click Deploy to deploy or enable the exchange profile.

   Remember: The Deploy button is enabled only when all the sections of the exchange profile are in Complete status.

Using inboundstatuscheckprofile to receive a pull request to check status of tax returns

The following steps describe how to receive a pull request from Organization B to check the status of previously submitted tax returns:

1. The business application sends a BDO, payload, and message to the inboundstatuscheck_msgrcvr messaging receiver.

2. The messaging receiver uses the following information in the BDO to look up the exchange profile that must be used to receive the pull request from Organization B:

   • Messaging receiver ID
   • Receiver ID (Organization B is receiver)
   • Sender ID (Organization A is sender)
   • Service (inbound checking status of tax returns is theservice that is configured in this scenario topic)
   Tip: If an exchange profile that matches the preceding parameters is not found, inboundstatuscheck_msgrcvr looks for the exchange profile again with the receiver ID set to Anonymous.

3. After searching for the exchange profile and determining that it is a one-way pull message exchange pattern, inboundstatuscheck_msgrcvr calls the AS4 service.

   Note: In a one-way pull message exchange pattern, the store and forward services are bypassed.

4. The AS4 service stores the message that is received from the business application in the pull destination (inboundstatuscheckpulldest) that is configured in the exchange profile (inboundstatuscheckprofile).

5. The AS4 receiver receives the pull request from Organization A and the uses the following information in the incoming request to determine which exchange profile must be associated with the inbound request:

   • MPC name - inboundstatuscheckpulldest.

     Note: If MPC name is not specified in the inbound request, the default MPC is used.

   • User ID - inboundstatuscheckuser.

     Note: User ID is determined from the user name token and X.509 certificate in this case, as both are enabled in the conformance policy.

   If the pull request contains additional attributes, such as the conversation ID, AgreementRef, Service, and Action, these attributes are used to determine the specific message that must be sent for the inbound request.

6. If there is more than one entry in the pull destination that matches the additional attributes, the first-in-first-out (FIFO) order is applied to determine the message that must be sent first. The message that was submitted first by the business application is sent first.

7. The AS4 service unpacks the inbound pull request and verifies the signature of the pull request. It also performs user name authentication based on the configuration of the exchange profile.

8. The message that matched the exchange profile lookup and attribute verification is packaged according to the conformance policy and exchange profile configuration, and sent as the response to the pull request.