Scenario: Sending an AS4 outbound one-way pull request

A one-way pull exchange involves transfer of a single user message unit. The one-way pull exchange pattern is initiated by the receiving message service handler.

The responding message service handler uses the inbound one-way pull exchange profile to receive and process the ebMS pull signal message. Typically the one-way pull exchange pattern is used by medium, small, and micro size enterprises. In a one-way pull exchange, it is not required for one of the partner systems to have an 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 outbound one-way pull exchange pattern:

Your organization (owner organization A) sends a pull request (to the trading partner - organization B) to check the status of the tax returns that were submitted earlier.
Your organization (owner organization A) sends a pull request (to the trading partner - organization B) to check the status of an order that was placed earlier.

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/as4/meg_cfg_si_si_bridge_overview.html.

Configuration requirements

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

Table 1. AS4 outbound one-way push pull exchange profile configuration
Configuration	Requirement
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/as4/meg_as4_configuringanas4customconformancepolicy.html.
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 ../configuring/as4/meg_cfg_orgs_create_organization.html.
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 pull request, you must select appropriate organization credentials. For information about configuring organization credentials, see ../security/as4/meg_sec_addorgcred.html.
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/as4/meg_creating_message_queue_definition.html.
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 AS4 Microservice. In an outbound exchange, the trading partner certificate is used to verify the signature of the pulled message. For information about adding trading partner certificates, see ../security/as4/meg_sec_addtpcert.html.
Owner organization certificates	If user authentication checking with X.509 certificate and signing of outbound exchanges is enabled in the conformance policy, the certificate alias must be added to AS4 Microservice and the public key must be shared with the trading partner. For information about adding owner organization certificates, see ../security/as4/meg_sec_addcert.html and ../security/as4/meg_sec_addppkpcert.html.
Messaging receiver	You must configure the messaging receiver to which the business application writes the business document object (BDO), message, and payload to trigger the outbound pull request. For information about configuring a messaging receiver, see ../configuring/as4/meg_creatingamessagingreceiver.html.
Messaging destination	You must configure the messaging destination to which AS4 Microservice sends the pulled message, BDO, message, and payload. For information about configuring a messaging destination, see ../configuring/as4/meg_creatingamessagingdestination.html.
Error notification destination	If error notification is configured in the conformance policy, you must configure a notification queue for sending errors to the business application. For information about configuring a messaging destination, see ../configuring/as4/meg_creatingamessagingdestination.html.
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 number of threads and associate the thread pool to the HTTPS destination. For information about configuring thread pools, see ../configuring/as4/meg_creatingathreadpool.html
HTTP or HTTPS destination	The trading partner destination where the outbound pull request is sent. For information about configuring an HTTPS or HTTP destination, see ../configuring/as4/meg_ui_creatinganhttpsdestination.html.
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 creating a retry policy, see ../configuring/as4/meg_creatingaretrypolicy.html.
Storage settings	Required storage settings. For information about configuring storage settings, see ../configuring/as4/Welcome_meg_cfg_storage.html
Pull destination	You must specify the message partition channel name (pull destination) in the Outbound Pull Request section of the outbound one-way pull exchange profile. The message 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/as4/meg_as4_creatingapulldestination.html

The following table lists the users permissions that are required to complete the AS4 outbound one-way pull exchange.

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

Creating a sample AS4 outbound one-way pull exchange profile

To create an exchange profile that can be used to check the status of the tax returns that were submitted earlier, you must complete the following tasks in AS4 Microservice:

Note: The following list provides information about the mandatory fields or configuration that are required for an AS4 one-way pull exchange profile. For information about other fields, see ../configuring/as4/meg_as4_creatinganas4outboundonewaypullexchangeprofile.html.

Note: This procedure assumes that the following components are created in AS4 Microservice:

Message queues
Thread pool
Messaging receiver - statuscheck_msgrcvr
Retry policy - OrganizationBretrypolicy
HTTPS destinations - statuscheck_dest, statuscheck_rcptdest, and statuscheck_errordest
Participating organizations - Organization A and Organization B
Organization credentials - statuscheckuser and associated with Organization A (master org)
Certificate alias of Organization A - OrganizatoinAcertalias (usage - HTTPS client authentication and signing/signature verification)
Certificate alias of Organization B - OrganizationBcertalias (usage - HTTPS client authentication and signing/signature verification)

Log in to AS4 Microservice with Master Account permission.
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 `statuscheckprofile` 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 One-Way/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, `checkstatusprofile`, that you entered in the Profile name field is populated here.
Description	Optional: Type `exchange profile for checking status of tax returns`.
Service	Type `checking status of 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. 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: Type `statuscheckingpmodeID` 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.
Receiver ID	Click New and type `orgA`.
Trading Partner Organization	Click Select and select Organization B.
Sender ID	Click New and type `orgB`.

Click Outbound Pull Request and specify Trigger and Action settings for the outbound pull request.

Field	Description
Interval	Specify the interval at which the scheduler must run to send the pull request. The first schedule is run when the exchange profile configuration is deployed. Subsequent schedules are run based on the interval specified here. Let us specify 5 days as the interval to run the schedule for this example.
Receiver	Click Select and select statuscheck_msgrcvr to receive BDO, payload, and message from the business application.
Pull MPC name	Type the pull destination name from where the message can be pulled.
Select destination	Click Select and select statuscheck_dest to send the pull request.
Connection	Click Configure and complete the following steps to configure connection settings for the outbound pull request: Authentication - Click Select and select statuscheckuser. Signature verification - Select OrganizationBcertalias to verify the signature of the pulled message. Destination for ebMS receipt - Select statuscheck_rcptdest to which the Organization A sends the receipt. Destination for ebMS errors - Select statuscheck_errordest to which Organization A sends error messages if errors are encountered when processing the pulled message. 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 statuscheckprofile to send a pull request to check status of tax returns

The following list describes the steps that are involved in sending a pull request from Organization A to Organization B to check the status of tax returns that was submitted earlier:

After the batchlodgeprofile is created and deployed, a schedule configuration is created and run immediately.
Note: Alternatively, the business application can send a BDO, payload, and message to check status of tax returns to statuscheck_msgrcvr.
When the scheduler runs, it picks up the BDO, payload, and message that is sent to the statuscheck_msgrcvr by the business application.
statuscheck_msgrcvr uses the information (such as the sender ID, receiver ID, service, and protocol) in the BDO to look for statuscheckprofile and starts the AS4 service.
The AS4 service retrieves the information that is required to package the ebMS pull signal message from batchlodgeprofile and packages the message. If selective pulling is enabled in the exchange profile the agreement URI and service are used along with the MPC name to pull a specific message.
The AS4 service uses the HTTP or HTTPS destination information in the exchange profile, and sends the message to statuscheck_dest.
If the pulled message is pulled and processed successfully, Organization A sends a receipt (eb:Signal message) to Organization B (statuscheck_rcptdest). If an error is encountered when pulling or processing the message, an error message is sent to statuscheck_errordest.