B2B Trading Partner Management(TPM)

Table of content
❖ TPM
❖ Components of TPM
❖ Configuration of TPM
❖ Standard Trading Partner Management steps
❖ Cloud Integration – Trading Partner Management V2 package
❖ TPM package artifacts
❖ Data FLOW Diagram
❖ INBOUND case
❖ OUTBOUND case
❖ Acknowledgement 997
TPM
SAP Trading Partner Management (TPM) is a solution within SAP Cloud Integration that
simplifies B2B (business-to-business) transactions and EDI (Electronic Data Interchange)
integrations.

The Trading Partner Management (TPM) helps to manage EDI business relationships
with multiple trading partners. It is designed to solve complexity of B2B communication
between trading partners.

B2B TPM holds Company (own) and Partner general information like identifiers,
message type and its version and parameter similar to PO B2B cockpit and newly
added feature like communication channels, credentials and certificate configuration.
Components of TPM

The common components of Trading Partner Management divided

into 4 types:
• Company Profile
• Trading Partner
• Agreement Template
• Agreement
1. Company Profile:
o Company Profile contains company details and address details information.
o Configure company profiles details, Contact, Identifier details, Business Context, Certificates,
parameter, and Systems Details.
2. Trading Partner Profile:
o we have configured correct information about trading partner such as identifier, type system
and others.
o TP contain Trading Partner Overview, Contacts, Certificates, Business Context, Parameter and
Systems.
3. Agreement Template:
Agreement Template used to create a partially configured trading partner agreement which can be
used as a baseline to create agreements.
o In the Overview tab, select and maintain My Company Details.
o B2B Scenarios tab , we can create and maintain both inbound or outbound transactional flows
in one agreement template itself.
▪ Select Interchange and Communication that configure in company profile. Partners details can be selected on
next step agreement.
4. Agreement:
Creating an agreement is the last step in the design of a B2B transaction and consists of two trading
partners representing one type of transaction between those two partners.
o In the Overview tab, select and maintain My Company Details and Trading Partner Details.
o B2B Scenarios tab , displays the multiple transactions that are created under the Agreement
Template.
▪ Define Mapping [MAG or customized mapping], Interchange and Communication in Agreement.
▪ After selecting all mandatory details correctly .
▪ Save and activate the agreement.
Configuration of TPM
➢ Create default Number range as ICN_DEFAULT for TPM usage.
➢ Copy the Cloud Integration – Trading Partner Management V2 package from Discover package
◦ This standard Trading Partner Management package contains the script collections and integration flows needed for
processing messages between B2B partners dynamically based on configurations done in Trading Partner
Management.
◦ We need to connect/configure mapping IFLOW in Trading Partner Management steps and Test the payload.
➢ After copying standard TPM package and make sure that we have to deploy each and every artifact. To run and
process the TPM steps as per logics.
➢ Create MIG’s
➢ Create TPM components
 Cloud Integration – Trading Partner Management V2
This package is responsible processing message for B2B partner. Below
steps/artificats are groovy script and IFLOW that process at runtime.

➢ Reusable Groovy Scripts V2

➢ Step 1 - Sender AS2 Communication Flow V2

➢ Step 1 - Sender AS2 MDN Flow V2

Standard TPM ➢ Step 1 - Sender IDOC Communication Flow V2

Steps ➢ Step 1 - Sender Process Direct Communication Flow V2

➢ Step 1 - Sender SOAP Communication Flow V2

➢ Step 1b - Write Message to Message queue

➢ Step 2 - Interchange Processing Flow V2

➢ Step 3 - Receiver Communication Flow V2

 Cloud Integration – Trading Partner
Management V2
▪ This package is responsible processing
message for B2B partner.
▪ Below steps/artifacts are groovy script
and IFLOW that process at runtime.
TPM package artifacts
Reusable Groovy Scripts V2
Script collection with all needed functionality (events, PartnerDirectory lookup, log, B2B monitor, number ranges...)
Step 1 - Sender AS2 Communication Flow V2
Receives messages via AS2 protocol, identifies type system and writes payload and header parameters into message queue
Step 1 - Sender AS2 MDN Flow V2
Receives messages via AS2 protocol, identifies type system and writes payload and header parameters into message queue
Step 1 - Sender IDOC Communication Flow V2
Receives messages via IDOC protocol, identifies type system and writes payload and headers into message queue
Step 1 - Sender Process Direct Communication Flow V2
Receives messages via Process Direct protocol, identifies type system and writes payload and headers into message queue
Step 1 - Sender SOAP Communication Flow V2
Receives messages via SOAP protocol, identifies type system and writes payload and headers into message queue
 TPM package artifacts
Step 1b - Write Message to Message queue
Receives messages via Process Direct protocol, identifies type system and writes payload and header parameters into
message queue
Step 2 - Interchange Processing Flow V2
Processes source based on sender conventions into target based on receiver conventions and writes target into queue
This is most important IFLOW which is responsible for below:
• Converting XML to EDI Flat file
• Validation XML data with MIG
• Calling Customized IFLOW
• Different types of routing and validation taken care
Step 3 - Receiver Communication Flow V2
Picks interchanges from outbound queue and sends them to the final receiver by the agreed communication protocols
Data Flow Diagram
INBOUND Case: EDI file to IDOC

AS2 IDOC S/4 HANA

Partner SAP CPI
(company)
(cloud)

OUTBOUND Case: IDOC to EDI file

IDOC AS2
S/4 HANA SAP CPI Partner
(company) (cloud)
 INBOUND Case:
1. In Inbound case, Partner is sending EDI ASC-X12 or EDIFACT flat file to us.
a. AS2_CommonIFLOW_Inbound take care the connection between partner to own company for sending data.
b. To process or execute further step - Connect AS2_CommonIFLOW to TPM address (/tpm/b2b/processdirect).
2. The cloud TPM B2B concept - Identify the agreement using partnerdirectyID and process that respective agreement.
3. The TPM steps, first checks the file is XML format or EDI file in Interchange Step-2 process
a. If file is XML payload, proceed next step without conversion (not required) and execute actual IFLOW.
b. If file is EDI (ASC-X12 or EDIFACT) flat file, converts EDI file into XML using MIG (MIG that configured at agreement)
in Step-2 interchange
4. The TPM runtime steps, Validate converted XML with ASC-X12 MIG and proceed to next step that is executing
customized IFLOW (process direct address/calling customized IFLOW)
5. In customized mapping IFLOW, converts ASC-X12 XML into IDOC XML as per mapping logic. Then it sends back this
IDOC XML output to TPM step.
6. TPM interchange step2, validate IDOC XML with IDOC MIG that configured in agreement level
7. The final step IDOC message store into the S4 or ECC (Credential that configured in IDOC Communication channel
level) We can see final output in monitoring level.
INBOUND Data FLOW diagram:
4. Convert/
1. Partner sends 2. Identifies 3. Checks XML/EDI Validate the
EDI Payload partner in TPM in TPM Payload with MIG
(ASC-X12)

6. Validate the
7. Store the IDOC 5. Execute
converted payload
message(S4/ECC) customized IFLOW
(IDOC MIG)
 OUTBOUND Case:
1. In outbound case, company (we are) sending IDOC message to partner.
a. IDOC data send to TPM
2. The cloud TPM B2B concept - Identify the agreement using partnerdirectyID and process that respective agreement
3. The TPM steps, first checks the file is XML format or EDI file in Interchange Step-2 process
a. If file is XML payload, proceed next step without conversion (not required).
b. If file is EDI (ASC-X12 or EDIFACT) flat file, converts EDI file into XML using MIG (MIG that configured at agreement) in
Step-2 interchange
4. TPM runtime steps, validate the IDOC xml payload using IDOC MIG and proceed to next step that is executing customized
IFLOW (process direct address/calling customized IFLOW)
5. In customized mapping IFLOW, Converts IDOC XML to ASC-X12 XML format using Message Mapping logics. Then it sends back
this ASC-X12 XML output to TPM step.
6. After converting/executing ASC-X12, TPM validate XML with ASC-X12 MIG that we configured in Agreement level.
7. If validation is fine, the TPM standard will convert ASC-X12 XML into EDI ASC-X12 file using ASC-X12 MIG in Interchange step-
2.
8. The final step the EDI file sends to partner (Based on AS2 Communication channel details) we can also see the final “EDI file ”
in monitoring.
OUTBOUND Data FLOW diagram:
4. Validate the
1. Company sends 2. Identifies 3. Checks
Payload with MIG
IDOC XML Payload partner in TPM XML/EDI in TPM
(IDOC)

6. validate the
7. Sends EDI 5. Execute
converted payload
payload to Partner customized IFLOW
with MIG (ASC)
 997 Acknowledgement
o In B2B (Business-to-Business) integration, the 997 Acknowledgement message is a key part of ensuring successful
communication between trading partners.
o The 997 acknowledgment specifically refers to a message that confirms the receipt of an EDI transaction (X12 or
EDIFACT) and verifies that it has been successfully processed by the recipient.
Ex: business document **850 Purchase Order**, **810 Invoice** confirming whether the original document was
received
There are two types of acknowledgments:
1. Functional Acknowledgement: FA useful in inbound case. The Company(own) conforming the message received
successfully to the partner.
2. Technical Acknowledgement: TA is nothing also called MDN, and it is useful in outbound case. The partner sends TA
with MDN and conforms “successfully processed the message “ in their side.
How the 997 Acknowledgement message is used in B2B:
1. Purpose of 997 Acknowledgement
- Receipt Confirmation: The 997 acknowledges the receipt of the original EDI document.
- Validation: It provides information on whether the document was syntactically correct. A
successful 997 typically means the document conforms to the correct EDI format,
sometimes data content is incorrect as per partner business logic.
- Error Handling: If there’s an issue with the original document, the 997 will include an error
segment, indicating the type of issue (e.g., invalid syntax, missing fields, etc.).
 997 Ack configuration in B2B TPM:
❖ In cloud, TPM developed with in-built feature for 997 acknowledgement.
❖ In Inbound case, select the acknowledgement drop-down as required and select “Communication for Sender
Functional Acknowledgement” in agreement level
▪ Select Communication channel in agreement that created under profile profile.
▪ Functional Acknowledgement Sent used in inbound case. The Company(own) conforming the message received
successfully to the partner.

❖ In outbound case, Enable the checkbox in interchange and select “Receiver Functional Acknowledgement Channel” in
agreement level.
▪ Select Communication channel in agreement that created under company profile.
▪ Technical Acknowledgement Received (for Sent Receiver Interchange) used in outbound case. The partner sends TA
with MDN and conforms “successfully processed the message “ in their side.
Partner
Inbound Case:
In Inbound case, select the
acknowledgement drop-down as
required and select “Communication for
Sender Functional Acknowledgement” in
agreement level
◦ AS2 997 Receiver communication
Channel needs to be created in
partner profile with proper credential
◦ Select Communication channel in
agreement that created under
company profile.
 Outbound case:
Partner
In outbound case, Enable the checkbox
in interchange and select “Receiver
Functional Acknowledgement Channel”
in agreement level.
◦ AS2 997 sender communication
Channel needs to be created in
company profile with proper
credential
◦ Select Communication channel in
agreement that created under
company profile.
Thank you