In many organizations, B2B transactions are not always handled using pure standard formats. Over time, custom XML structures are introduced on top of EDIFACT messages to align with internal processing or EDI broker requirements.
I encountered a similar scenario in one of my recent projects. Through our EDI broker, we were consuming EDIFACT messages in an XML representation. With the upcoming S/4HANA migration, the same integrations needed to be moved to SAP Integration Suite.
Interestingly, the migration itself was not the biggest challenge. The real concern was monitoring and trading partner mantinance.
In our existing SAP PI/PO landscape, we have more than 400 active interfaces processing approximately 200,000+ transactions. Monitoring in such a landscape is already complex. Moving to Integration Suite without a structured monitoring approach would only increase the operational overhead.
Why We Considered B2B Advisory
To address this, we evaluated B2B Advisory capabilities in Integration Suite. The key expectations were:
Automatic payload logging retention for a defined number of daysClear identification of trading partner informationAgreement-based processing for structured partner managementA dedicated monitoring environment for B2B transactions
Another important aspect was our S/4HANA clean core strategy. By leveraging B2B Advisory features properly, we see opportunities to reduce custom logic and keep the core system less cluttered with monitoring-specific enhancements.
Migration Context: From PO Without TPM to Integration Suite
In our SAP PO system, we were not using Trading Partner Management (TPM). As a result, many partner-specific handling rules were built into custom logic. While setting up B2B Advisory in Integration Suite, we started seeing clear structural benefits — especially around agreement handling and partner-based message identification. Even at this in-progress stage, the difference in approach compared to PO is quite visible.
This blog focuses on how I configured B2B Advisory to support our XML-based custom EDIFACT messages. Since we could not directly use the standard packages as-is, I made specific adjustments to adapt them to our scenario. I will walk through:
How the standard B2B Advisory packages behaveWhat limitations we observed with custom XML EDIFACTWhat modifications were requiredKey learnings during configuration
This is still work in progress, but the insights gained so far are already valuable, especially for teams moving from PI/PO to Integration Suite without prior TPM usage.
I have devided thie blog into 3 parts where current blog refers the configuration what we need to do in TPM (Trading partner Management such as Compnay profile, Partner profile, Identifiers, Communication configuration etc.2nd blog will be based on –> agreements and couple of features i have used.3rd blog will be how Iflows are configured and customized as per the need.
Quick Concept: How B2B Advisory & Integration works
Above is the a explanitary flow how messgae processing works with B2B Advisory. Here the brain is TPM Setup and Iflows are executing engine. Let’s break down the setup I have created within TPM.
TPM Setup for B2B Advisory
As explained in the processing flow, the standard B2B Advisory packages rely heavily on Trading Partner Management (TPM). The iFlow itself does not contain hardcoded partner logic. Instead, it dynamically resolves sender, receiver, and agreement details from TPM configuration at runtime. The TPM setup was structured as follows.
Company
The Company object represents our organization within the B2B landscape. In our case:
It reflects our enterprise entity interacting with external partnersThis acts as the anchor for all agreements.All inbound and outbound B2B agreements are defined relative to this Company.
Important consideration:
We ensured that the company identifiers align with the values extracted from the XML payload. If the identifiers do not match exactly, agreement resolution will fail.
Here I have created 2 identifiers from SAP where 1st “BTPISEDI” is the one i’m using for all outbound from SAP (Idoc always) as this is the port we have defined for IDoc in WE21. and “DS4CLNT120″ for all inbound to SAP as that is the logical system for all inbound. How those will be used will be describe in coming setps.
On the continuation on Company profile, we have Identifer where we can add individual identifer and Group Identifier. Group will be used when we have the varite of identifers.
IdentifierActual value from the payload which will be use to identify the flowAliasRepresentation of the identifer which will be display at config levelType SystemType System means the Source Document type in simple languageScheme Name/CodeKind of the identifer number for internal use eg : Customer Number or Partner ProfileAgency Name/CodeKind of the identidier for the trading partner eg : DUNS number or Sender ID
Within the Trading Partner Management setup, the Systems tab allows us to define communication system details such as IDoc or Process Direct configuration parameters.
However, it is important to understand that these are not actual adapters.
The configurations maintained here do not represent runtime adapters directly. Instead, they act as logical placeholders that the standard B2B package references during execution.
How It Works Conceptually:
In TPM, we define a System for:External partner sideOur backend system (e.g., S/4HANA)Type System (System version)Under the System definition, we maintain adapter-related attributes such as:endpoint url of the system (internet/On-Prim)Location ID (if applicable)Process Direct urlCredentails if application
These settings are then picked up by the standard B2B iFlow at runtime. The iFlow reads the resolved Agreement –> identifies the associated Systems –> and dynamically maps the configured values into the actual adapter that is connected in the integration flow.
Learning from various hit/try : If under system purpose is maintain as test, then in case of inbound to SAP, Idoc will never post for automatic posting it should be marked at production.
Partner Profile
Next step would be maintain the system and trading partner information. Here 2 section are devided into 2 maintinance. 1st is the Communication Partner (EDI Broker/Trading Partner Connected System/any other middleware) and Trading Partner (your actual customer/vendor).
Quick concept on Communication Partner :
protocol supported Process Direct and AS2.only connection details are requried under communication partner.technical placeholder for connection.certificates/signatature (for signing and encrption) are available (mostly used with AS2)
Trading Partner
Same setup what we do in company profile need to be recreate here. Except, we can ignore the communication part (channel details/type system). Just adding the reference of the communication partner is sufficient.
Here in the identifier for trading partner I have used group of identifiers instead of individual identifier (nothing intresting just because I have tried individual). These Identifier are used to fetch the correct agreement which will have a better monitoring view per trading partner.
Next series of this blog will be on how agreements can be create (will not be too standard as I have faced couple of challange) and additional paramters which are useful. Also, the configuration we made in this part, how these play a valuable role and where these will be visible at runtime.
link (will be update once published) : Implementing B2B Advisory in SAP Integration Suite for Custom XML EDIFACT Scenarios part – 2
Thanks
Aman Sharma
In many organizations, B2B transactions are not always handled using pure standard formats. Over time, custom XML structures are introduced on top of EDIFACT messages to align with internal processing or EDI broker requirements.I encountered a similar scenario in one of my recent projects. Through our EDI broker, we were consuming EDIFACT messages in an XML representation. With the upcoming S/4HANA migration, the same integrations needed to be moved to SAP Integration Suite.Interestingly, the migration itself was not the biggest challenge. The real concern was monitoring and trading partner mantinance.In our existing SAP PI/PO landscape, we have more than 400 active interfaces processing approximately 200,000+ transactions. Monitoring in such a landscape is already complex. Moving to Integration Suite without a structured monitoring approach would only increase the operational overhead.Why We Considered B2B AdvisoryTo address this, we evaluated B2B Advisory capabilities in Integration Suite. The key expectations were:Automatic payload logging retention for a defined number of daysClear identification of trading partner informationAgreement-based processing for structured partner managementA dedicated monitoring environment for B2B transactionsAnother important aspect was our S/4HANA clean core strategy. By leveraging B2B Advisory features properly, we see opportunities to reduce custom logic and keep the core system less cluttered with monitoring-specific enhancements.Migration Context: From PO Without TPM to Integration SuiteIn our SAP PO system, we were not using Trading Partner Management (TPM). As a result, many partner-specific handling rules were built into custom logic. While setting up B2B Advisory in Integration Suite, we started seeing clear structural benefits — especially around agreement handling and partner-based message identification. Even at this in-progress stage, the difference in approach compared to PO is quite visible.This blog focuses on how I configured B2B Advisory to support our XML-based custom EDIFACT messages. Since we could not directly use the standard packages as-is, I made specific adjustments to adapt them to our scenario. I will walk through:How the standard B2B Advisory packages behaveWhat limitations we observed with custom XML EDIFACTWhat modifications were requiredKey learnings during configurationThis is still work in progress, but the insights gained so far are already valuable, especially for teams moving from PI/PO to Integration Suite without prior TPM usage.I have devided thie blog into 3 parts where current blog refers the configuration what we need to do in TPM (Trading partner Management such as Compnay profile, Partner profile, Identifiers, Communication configuration etc.2nd blog will be based on –> agreements and couple of features i have used.3rd blog will be how Iflows are configured and customized as per the need.Quick Concept: How B2B Advisory & Integration works Above is the a explanitary flow how messgae processing works with B2B Advisory. Here the brain is TPM Setup and Iflows are executing engine. Let’s break down the setup I have created within TPM. TPM Setup for B2B AdvisoryAs explained in the processing flow, the standard B2B Advisory packages rely heavily on Trading Partner Management (TPM). The iFlow itself does not contain hardcoded partner logic. Instead, it dynamically resolves sender, receiver, and agreement details from TPM configuration at runtime. The TPM setup was structured as follows.CompanyThe Company object represents our organization within the B2B landscape. In our case:It reflects our enterprise entity interacting with external partnersThis acts as the anchor for all agreements.All inbound and outbound B2B agreements are defined relative to this Company.Important consideration:We ensured that the company identifiers align with the values extracted from the XML payload. If the identifiers do not match exactly, agreement resolution will fail.Here I have created 2 identifiers from SAP where 1st “BTPISEDI” is the one i’m using for all outbound from SAP (Idoc always) as this is the port we have defined for IDoc in WE21. and “DS4CLNT120” for all inbound to SAP as that is the logical system for all inbound. How those will be used will be describe in coming setps.On the continuation on Company profile, we have Identifer where we can add individual identifer and Group Identifier. Group will be used when we have the varite of identifers. IdentifierActual value from the payload which will be use to identify the flowAliasRepresentation of the identifer which will be display at config levelType SystemType System means the Source Document type in simple languageScheme Name/CodeKind of the identifer number for internal use eg : Customer Number or Partner ProfileAgency Name/CodeKind of the identidier for the trading partner eg : DUNS number or Sender IDWithin the Trading Partner Management setup, the Systems tab allows us to define communication system details such as IDoc or Process Direct configuration parameters.However, it is important to understand that these are not actual adapters.The configurations maintained here do not represent runtime adapters directly. Instead, they act as logical placeholders that the standard B2B package references during execution.How It Works Conceptually:In TPM, we define a System for:External partner sideOur backend system (e.g., S/4HANA)Type System (System version)Under the System definition, we maintain adapter-related attributes such as:endpoint url of the system (internet/On-Prim)Location ID (if applicable)Process Direct urlCredentails if application These settings are then picked up by the standard B2B iFlow at runtime. The iFlow reads the resolved Agreement –> identifies the associated Systems –> and dynamically maps the configured values into the actual adapter that is connected in the integration flow.Learning from various hit/try : If under system purpose is maintain as test, then in case of inbound to SAP, Idoc will never post for automatic posting it should be marked at production.Partner ProfileNext step would be maintain the system and trading partner information. Here 2 section are devided into 2 maintinance. 1st is the Communication Partner (EDI Broker/Trading Partner Connected System/any other middleware) and Trading Partner (your actual customer/vendor).Quick concept on Communication Partner : protocol supported Process Direct and AS2.only connection details are requried under communication partner.technical placeholder for connection.certificates/signatature (for signing and encrption) are available (mostly used with AS2)Trading PartnerSame setup what we do in company profile need to be recreate here. Except, we can ignore the communication part (channel details/type system). Just adding the reference of the communication partner is sufficient. Here in the identifier for trading partner I have used group of identifiers instead of individual identifier (nothing intresting just because I have tried individual). These Identifier are used to fetch the correct agreement which will have a better monitoring view per trading partner. Next series of this blog will be on how agreements can be create (will not be too standard as I have faced couple of challange) and additional paramters which are useful. Also, the configuration we made in this part, how these play a valuable role and where these will be visible at runtime. link (will be update once published) : Implementing B2B Advisory in SAP Integration Suite for Custom XML EDIFACT Scenarios part – 2 ThanksAman Sharma Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
