This blog is not really a step-by-step configuration guide, we rather focus on the principles and relationships among various aspects of Trading Partner.

At first we need to configure our Parent Company, which is the business entity we are going to integrate with external Trading Partners. We can have only one Parent Company, which means we cannot create a dummy one for testing.

We configure Parent Company the same way we configure external Trading Partners. I will describe the configuration of a Trading Partner, but the same applies to Parent Company.

Trading Partners are those companies we will be communicating with. Before configuring our Partner, we should be clear about 3 levels of communication which we need to establish:

• System — Type of our Partner’s back-end system (SAP, Microsoft etc.). This is not mandatory and we can name it as we want in case we don’t know

• Type System — this is the message format we use in our mutual communication (X12, IDoc, Edifact)

• Communication — the transmission technology or protocol of the exchange, which will define the integration adapter in SAP Cloud Integration (HTTP, IDoc, AS2)

Let’s say our Partner ACME Corp uses SAP S/4HANA as their ERP system, IDoc format as the exchange message type and AS2 protocol as the technical communication channel.

With this in mind, we can configure our Trading Partner.

Clicking on the Trading Partner, we enter the Trading Partner Profile. We fill purely descriptive sections Overview and Contacts and let’s jump to Identifiers.

Identifiers

These are codes, identifying our Parent Company and Trading Partners in the communication.

SAP recognizes two sets of Identifiers:

• codes identifying the Partners (including Parent Company) in the Parent Company’s own back-end system

• codes identifying the Partners (including Parent Company) in the EDI message exchange, ie. these IDs will be used in the message itself and will be validated against TPM configuration. Often these Identifiers are assigned by Dun & Bradstreet or other recognized institution.

We can as well use only one Identifier and if needed, we can map it to whatever value we want in our back-end system. This is the case of our scenario. Let’s say that in our EDI communication with ACME Corp the Identifier 10001_ACME_IDOC will be used in the message exchange.

For our ACME Corp, let’s now create two Identifiers. Identifiers are system-specific, so if our Trading Partner operates IDoc message format, as well as X12 message format, we need to create at least two Identifiers. You can see that for IDoc there is no Scheme available, whereas for X12 EDI format we can choose from various institutions. When using IDs which are not officially assigned by any institution, we can select Mutually Defined, which is also a common choice in the the real world.

For simplification, from now on we will consider ACME Corp running only IDoc communication.

Systems

We skip Business Context section, which is descriptive and helps with the business classification, and have a look at Systems tab. Each System represents a technological platform, which the partner operates — SAP S/4HANA, Microsoft, Amazon, Adobe etc. This is not related to a communication protocol, rather to an ERP or EDI system.

Type System

Clicking on the ACME SAP system, another screen opens. These Type Systems are the communication types. If we exchange IDocs with our Partner, the message format will be XML, even though the Communication type can be HTTP or AS2. This can be confusing. Here you specify solely the message format, not the communication protocol.

Creating a new Type System, we have to select from a dropdown list. Apart of ASC X12 and on-prem SAP S/4HANA we have the following choice:

Communications

Now we get to Communication channel, which represents the technical integration adapter in SAP Cloud Integration.

In our scenario, we communicate over AS2 protocol, so we establish 3 channels — Sender, Receiver and one more Receiver for MDN acknowledgement.

If our preferred communication channel is not listed (for example SFTP at this moment), we select Process_Direct and we have to create a custom separate iflow with SFTP adapter.

Now we have to configure the individual channels. This is the same activity as configuring them in the SAP Cloud Integration iflow. For its complexity I will describe the AS2 settings, but in a separate blog.

Now we have configured our Trading Partner. Nevertheless, we are still not able to exchange a message with this Partner. We need to set Agreement to be able to do so. This we will see in the next chapter.

A whole series of blogs on Trading Partner Management:

1. Overview

2. Data

3. Partner

4. AS2

5. ….will continue

It was also published here:

https://medium.com/@jiri.fridrich/sap-tpm-trading-partner-configuration-26af6a807c35