Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
jirifridrich
Participant
0 Kudos
1,504

Now let's focus on the PARTNER part of the EDI message exchange. 

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.

jirifridrich_0-1728042472071.png
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.

jirifridrich_1-1728042472073.png
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.

jirifridrich_2-1728042472074.png
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 real world.

jirifridrich_3-1728042472077.png
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.

 

jirifridrich_4-1728042472078.png

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.

jirifridrich_5-1728042472079.png

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:

jirifridrich_6-1728042472079.png


Communications

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

jirifridrich_7-1728042472079.png

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.

jirifridrich_8-1728042472078.png

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.

2 Comments
jyotis
Explorer
0 Kudos

Hi,

Nice blog, but one question. Is it possible to use SAP ECC with TPM in integration suite?

Thanks for your reply!
Br,
Jyoti

jirifridrich
Participant
0 Kudos

Hi Jyoti,

Thank you.
Although ECC is not listed among Type Systems, I don't see any reason why not. TPM cares about the IDoc, not about the system which generated it. As long as SAP ECC can call the IDoc Sender adapter in Integration suite, which it can, it should work.
With regards,
Jiri

Labels in this area