Introduction

With my background in EDI business I was always wondering how Cloud Integration Suite can be used in big EDI scenarios. Since SAP introduced the graphical interface for communication agreements of the Trading Partner Management, it is time to check how the Integration Suite can be used as B2B/EDI platform. So I started to implement a short scenario to get a better understand how the components fit together.

Please see: Announcement: SAP Trading Partner Management and B2B Monitoring brand new capabilities of SAP Integration Suite is released!

Scenario

The idea was to build a classic scenario exchanging EDIfact messages. Let’s assume we receive orders and self billing invoices from customers via AS2, and process them as iDocs. Outbound DESADV iDocs will be mapped into EDIfact messages and send via AS2.

Requirements

Let make a short disclaimer: This blog is not a step by step tutorial. To rebuild the shown scenario additional knowledge is needed.

The following is needed:

• Integration Suite with
  • Activated Trading Partner Management
  • AS2 Adapter (Enterprise Messaging is needed)
  • iDoc connection to some R3 or S4 backend
• Integration Advisor Mappings (Mapping Guideline/MAGs)
  • The creation is not part of this article
• AS2 system to act as EDI partner (by example a second tenant or mendelsonAS2)

To write this article a Cloud Foundry Environment was used.

Implementation

Creating the HTTP user.

The Trading Partner Management needs an authenticated user to identify the related agreement.

First create a role:

For each sending partner a service instance and a service key is required. During configuration of the trading partner the clientid from the credentials is needed.

Configuring the Trading Partner Management

After activating the TPM in the BTP cockpit a new menu “B2B Scenarios” appears on the WEB interface:

Menu B2B Scenarios

In the design view the Trading Partner Management is configured. While there are several articles describing the configuration via API/Postman it is important to know that the information only is written to the runtime configuration upon activation of an agreement. Also, an already existing configuration inserted by API/Postman does not appear in the user interface.

The user interface has the following structure:

• Company Profile (1..1)
  • Contacts (0..n)
  • Identifiers (1..n)
  • Business Context
  • Systems (1..n)
    • Type Systems (1..n)
    • Communications (1..n)
  • Certificates (0..n)
• Trading Partners (1..n)
  • Contacts (0..n)
  • Identifiers (1..n)
  • Business Context
  • Systems (1..n)
    • Type Systems (1..n)
    • Communications (1..n)
  • Certificates (0..n)
• Agreement Templates (1..n)
• Agreements (1..n)

The certificates are directly maintained within the TPM. It is not needed to store them under Overview->Manage Security->Security Material. In same way there is no need to inject the Integration Advisor artifacts.

So let’s start

Only one Company Profile can be configured. When operating a central platform for a company group, multiply company profiles would be helpful to quickly identify internal partners:

After configuring the company profile an agreement template can be created:

The communication channels are configured during the partner configuration. In the AS2 Sender communication you will need to configure the HTTP User:

The fact that Trading Partner Management requires an authenticated HTTPs user may cause some discussions. There are a lot of companies running AS2 without user authentication at the transport level. There, the AS2 Id serves as key, and the partners are authenticated by verifying the signature. Faced with an EDI partner who is not able or not willing to use HTTP users a workaround must be found. API Management can be an option to achieve such workaround. From operations view, perhaps with a special EDI on-boarding team, maintaining the HTTP user in BTP cockpit is quite not comfortable. Also for outbound connections HTTP credentials are mandatory.

It takes getting used to that partners AS2 Id does not play a real role during inbound connections. Assume you have an EDI partner connected years ago. After three merger and five rebrandings, the partner is facing a problem sending documents via AS2. In such situations, it is always challenging to find the corresponding configuration. In my experience, you would ask the partner for his AS2 Id and search for it. With TPM you will need the user id, but clientids are real long if you try to exchange them via phone. But booth values are not searchable with the GUI.

After configuring a partner you can use the template to create an agreement. Be aware, even if the fields are not marked as mandatory you will need them all to activate the agreement. Only one identifier can be added per partner and own company:

Also some data has to be maintained on the B2B Scenarios tab, by example the mapping from the Integration Advisor has to be chosen. It is not possible to activate the agreement without Integration Advisor artifacts:

I am missing the option to define custom fields in an agreement template and configure them with the agreement. This would help to realize custom requirements.

Configuration of the iFlows

In the Discover section the package Trading Partner Management can be found. In this article version 1.1.0 was used:

After coping it to the tenant following artifacts need to be configured and deployed:

• Step 1 – Sender AS2 Communication Flow
• Step 1 – Sender iDOC Communication Flow
• Step 2 – Interchange Processing Flow
• Step 3 – Receiver Communication Flow *

* In case of an on premise SAP backend “Step 3 – Receiver Communication Flow” has to be copied, because the proxy type is not configurable.

Monitoring

Following an example of the monitoring view. It offers links to jump directly into the iFlows. But it is not possible to access the payloads:

Summary

With Trading Partner Management SAP provided a graphical user interface. It allows the configuration of EDI scenarios in an ideal world. Whether the current and future requirements can be implemented with the rigid configuration must be checked in each individual case.

I hoped you enjoyed this overview.

It would interesting if you use TPM in a productive environment, perhaps you can leave a comment.