Onboarding scenario

The following example provides an overview of a combination of various APIs used to configure a new trading scenario from the ground up. This is only a subset of the available APIs. Other APIs are available and can be found within your environment:

http://<host>:<port>/apidocs

Sample code

The following file containing sample code is available in the TE_sample.zip folder that is packaged with this guide: community_partner_onboard.docx.

Use this file to test community and partner creation using the APIs as you follow the scenario.

A sample code file is provided which enables you to to test community and partner creation using the APIs as you follow the onboarding scenario.

Follow this link to access sample files.

Overview

In a typical trading scenario, data is exchanged between a partner and a community (which can be seen as a local partner), or the other way around. In order to facilitate these trading patterns, the first step is to define the participants and all of their characteristics.

Step 1 Overview:

  • Trading participant (Partner and Community) identifiers (Routing IDs, Messaging IDs)
  • Trading participant (Partner and Community) identifiers (Routing IDs)
  • Protocol parameters (Pickups, Deliveries)
  • Certificates

Step 1 can be visualized as follows:

Diagram outlining community and partner relationships.

Step 2 Overview:

After the file has been received by the community (from a partner), the infrastructure needs to be set up in the "backend." This is needed to be able to deliver messages or, for outbound scenarios, to be able to pick up messages.

Step 2 can be visualized as follows:

Diagram showing the relationship for application pickup and delivery.

Step 3 Overview:

In a Trading Engine only scenario, from partner to backend and back, a full flow setup would consist of the following minimum steps:

  • Community definition
    1. Trading pickup definition
    2. Messaging ID definition
    3. Routing ID definition (optional)
    4. Certificate addition (optional)
  • Partner definition
    1. Partner delivery definition
    2. Messaging ID definition
    3. Routing ID definition (optional)
    4. Certificate addition (optional)
  • Application delivery definition (Trading partner - Backend)
  • Application pickup definition (Backend - Trading partner)

Step 3 can be visualized in the following diagram:

Diagram showing the delivery and pickup relationship between a community and a partner.

The following paragraphs describe the details about each of these steps.

Add a community

To create a new community definition through API requests, follow the steps listed below.

Note   This scenario assumes a completely new configuration without any existing pieces.
  1. Login. Authenticate yourself with a valid username and password combination. This will allow you to interact with the system and continue with the next steps. Depending on the tool used, authentication might be needed only once per session.
  2. Add a community with POST: /restapi/v1/communities. In this scenario, the community represents the local trading participant. In this step, the community is basically an empty shell with a name.
  3. Add a trading pickup exchange with POST: /restapi/v1/communities/exchange/<id>/trading/pickup, where "id" is the community identifier returned by the request in the previous step.
  4. Add a messaging ID to the created community with POST: /restapi/v1/communities/messagingIds/<id>.

Add a partner

To create a new partner definition through API requests, follow the steps listed below. (Note that this scenario assumes a completely new configuration without any existing pieces).

  1. Login. If you haven't done so yet, authenticate yourself with a valid username and password combination. This will allow you to interact with the system and continue with the next steps. Depending on the tool used, authentication might be needed only once per session.
  2. Add a partner with POST: /restapi/v1/tradingPartners.
  3. Add a partner delivery protocol with POST: /restapi/v1/tradingPartners/exchange/<id>/trading/delivery, were the "id" is the partner identifier. This step is necessary to allow the partner to trade information with the community or communities.
  4. Add a messaging ID to the created partner with POST: /restapi/v1/tradingPartners/messagingIds/<id>.
  5. Subscribe the partner to the community with POST: /restapi/v1/tradingPartners/<p_id>/subscriptions?communityId=<c_id>, where "p_id" is the partner identifier and "c_id" is the community identifier.

Add an application pickup

To add an application pickup through API requests, the steps listed below must be followed.

Note   This scenario assumes a completely new configuration without any existing pieces.
  1. Login. If you haven't done so yet, authenticate yourself with a valid username and password combination. This will allow you to interact with the system and continue with the next steps. Depending on the tool used, authentication might be needed only once per session.
  2. Add an application pickup with POST: /restapi/v1/application/exchange/pickup. The application pickup will pick up the messages from the back-end location.

Add an application delivery

To add an application delivery through API requests, the steps listed below must be followed. (Note that this scenario assumes a completely new configuration without any existing pieces).

  1. Add an application delivery with POST: /restapi/v1/application/exchange/delivery. The application delivery will deliver the messages to the back-end destination.
  2. Add application delivery settings with POST: /restapi/v1/communities/<id>/deliverySettings, where "id" is the community identifier. The application delivery settings will route the traffic to the defined application delivery.

Query existing objects

The following examples show how to query existing objects in the configuration.

  1. List the configured communities with GET: /restapi/v1/communities. The response will return the configured communities. The query can be filtered by partyName, countryCode, _id, aliases and contacts. Filter examples: partyName like 'Axway%', routingId.id = 'ZZAXWAY', _id = '2136000'
  2. List the configured partners with GET: /restapi/v1/tradingPartners. The query can be filtered by partyName, countryCode, _id, aliases and contacts. Filter examples: partyName like 'Acme%', routingId.id = 'ZZACME', _id = '2136001'.

Also available are the REST API instructions for:

Related Links