In Part 1, I explained the overall setup of B2B Advisory. How the TPM foundation was structured. With the Company, Trading Partner, and Systems configuration in place, the next critical layer is the Agreement.
In B2B Advisory, the Agreement is not just a configuration object — it is the runtime decision engine. Every inbound or outbound message must resolve to a valid Agreement. If it does not, the processing stops at the monitoring layer.
In this part, I will focus on how Agreement determination works how it can be create, how it interacts with payload identifiers, and what challenges arise when dealing with XML-based EDIFACT.
What is Agreement
In simple language, an Agreement in B2B Advisory defines the rules under which a message is allowed to be processed between two parties. It answers four basic questions:
Who is sending the message?Who is receiving the message?What type of message is it?In which direction is it flowing (Inbound or Outbound)?
If all these conditions match, the system allows the message to proceed. If not, processing stops.
You can think of an Agreement as a contract between two systems. Unless a valid contract exists, the message cannot move forward.
Agreement Templates
Agreement template are created for the refernce of an actual agreement. It consist a desgin flow of how actual end-2-end B2B flow works. Who it the party (Our business or Trading partner), what all systems are involve, communication adapters information what messgae are we using, invlolved identifer. This is just a template where all the input values can be changed later on while creating an actual agreement.
Agreement
This is the core of the B2B Advisory. While creating an agreement, you can take refernce of an existing agreement template so that a desing flow with the connected systems wil automatically populated.
Working with copy with template –> agreement will copy the existing configuration available in selected template and give the option to modify as requried. (preferable choice)
Working with bind with template –> agreement will bind with the existing configruation and doesnot allow to change configuration.
Agreement Overview
This include the overview of your agreement, who is the initiator, connected type system, SAP system and what are the identifers involve to check wether the incoming messgae have one of these identifer. These identifer are not entered manually instead is take refernce from the profile (Company/Trading profile). You have a option to create on prompt but advisable is to take refernce from the profile (Single/Group Identifer).
Learning from agreement
While creating an agreement sometime a confusion arise that, for one trading partner if we have multiple types of business transactions, then should we create multiple agreements. No, we have options to create multiple business transaction scenario in one agreement (inbound and outbound both). Don’t treat an agreement as one interface, agreement is something a contract between your orgnization and trading partner. So while create an agreement name it as per the involve trading partner.For custom formats there is not option I have found for the Custom type system, So I decided to use type system as “SAP S/4HANA On Premise IDoc” for Trading Partner (considered after various failed hit and try). As based on the Type system standard iFlow behaves differntly and most suitable to work with the XML “SAP S/4HANA On Premise IDoc” is best as per my R&D.We have options to create custom MIG & MAG under custom type system but there is no options I found to include those in the agreement. So I Have used standard MIG of each messgae for my Integration.While fetching the standard MIGs message version are available but there is no guarantee the SAP version you have will be available. In my case for ORDERS.ORDER05 have two versions “S4HANA 1709–Version – S4HANA 1709″ and “1809_FPS02–Version – 1809_FPS02″ and for DESADV.DELVRY07 I see only “1809_FPS02–Version – 1809_FPS02″. Where as in our landscape we have “S/4HANA 2023”. Key consideration is choosing different version on the IDoc may create issue, as the metadata available in yours SAP will not be the same available in the MIG you selected. So instead of choosing MIG in you mapping design, we refer the structure what is available in the SAP. Also, MIG selection is mandatory in the agreement and agreement is based on the Type System, so ultimatly in the Type system (Company/Trading partner profile’) mentioned version what you have in you SAP and what is available in you MIG. S/4HANA Version (MIG)ABAP/Basis Release (IDoc)17097521809753190975420207552023758
B2B Scenario
Next step will be creating the transactions all inbounds and outbounds with the selected trading partner, the actual business flow.
Here we have the designed flow which have the prebuild steps as:
Sender & Receiver can be your SAP system or Trading partner system depends on the what you have choose on the transaction create screen where Interchange have the message and involve type system version information (version/MIG can be editied manually).
Other features what we have here are the Activity Paramters, Custom Search Attributes and Custom Rules.
Activity Parameter –>These can be used for additional mapping logic. for example storing partner profile code, logical system deatils, port details, DUNS number, EDI messgae version, other hardcoded values per trading partner. These can be manually create or can be extend from Company/Trading parter profile. In short partner specific values can be maintained here.
Custom Search Value –> To get more filters for the monitoring such as any messgae id, plant, ship-to, buyer-id etc. These can be added with the help of parameters, headers and XPath.
Transaction Configuration
After these configuration we have to start mantain the channels, mapping, MIG version etc. In the Source Communication we need to maintain the channle, these are not actual channle/adapter instead a template which we create in Company/Trading profile. Actual adapter which will pick the file, need to develop in cloud integration (IFlow designer) which will execute these agreement transaction.
In the inerchnage mentioned the actual MIG used, Number range object, and the version of your SAP system. There are certain other options also we have in case those are requrired as per your requirement. As in my case I have the customized XML of EDIFact file I have used the MIG which is available for me for the business process I have and in the SAP Version I have chaged from original MIG to the one which we have in our landscape. I have used the same process for both sender/receiver interchange.
Mapping Logic –> We have the option to execute the mapping developed in Cloud Integration via process direct or we can use the MAG whatever suite the requirement. In my case because of custom logics I am haved process direct which is calling a seperate iflow developed in cloud Integation.
Once everythig is in there place after activating the agreement, all the information present till agreement will be executed in the partner directory data, which is the runtime enviournment for execution.
Here the Activity Plain ID the the matching string, once that is found correct agreement will be executed else the that transaction will fail with the error “Agreement Configuration Access Failed”.
What This Plan ID Template Represents –> The Agreement Plan ID is constructed by combining multiple message and partner attributes into a single structured string.
sndAdapterType –> The communication adapter (Process_Direct, AS2, IDoc, etc.)sndDocumentStandard –> EDIFACT, X12, SAP_IDoc etc.sndMessageNamespace –> Namespace maintained in designsndMessageVersion –> Version like D96A, 758 etc.dynamic internal placeholder –> %ssndSenderIdQualifier –> Sender ID Identifier (single/group)sndSenderPartnerType –> Type of partner (Customer, Vendor)sndSenderSystemId –> Sender system identifiersndSenderSystemIdQualifier –> Qualifier for sender systemdynamic internal placeholder –> %ssndReceiverIdQualifier –> Receiver qualifiersndReceiverPartnerType –> Receiver partner typesndReceiverSystemId –> Receiver systemsndReceiverSystemIdQualifier –> Receiver qualifiersndMessageType –> Message type like ORDERSsndAdapterType + “-” + sndDocumentStandard + “-” + sndMessageNamespace + “-” + sndMessageVersion + “-%s-” + sndSenderIdQualifier + “-” + sndSenderPartnerType + “-” + sndSenderSystemId + “-” + sndSenderSystemIdQualifier + “-%s-” + sndReceiverIdQualifier + “-” + sndReceiverPartnerType + “-” + sndReceiverSystemId + “-” + sndReceiverSystemIdQualifier + “-” + sndMessageType
This is how an end-2-end configuration of agreement works. In the next step I will show how standard package behaves with this agreement and what changes I made in one of the flow for inbound custom XML based EDIFact.
link (will be update once published) : Implementing B2B Advisory in SAP Integration Suite for Custom XML EDIFACT Scenarios part – 3
In Part 1, I explained the overall setup of B2B Advisory. How the TPM foundation was structured. With the Company, Trading Partner, and Systems configuration in place, the next critical layer is the Agreement.In B2B Advisory, the Agreement is not just a configuration object — it is the runtime decision engine. Every inbound or outbound message must resolve to a valid Agreement. If it does not, the processing stops at the monitoring layer.In this part, I will focus on how Agreement determination works how it can be create, how it interacts with payload identifiers, and what challenges arise when dealing with XML-based EDIFACT.What is AgreementIn simple language, an Agreement in B2B Advisory defines the rules under which a message is allowed to be processed between two parties. It answers four basic questions:Who is sending the message?Who is receiving the message?What type of message is it?In which direction is it flowing (Inbound or Outbound)?If all these conditions match, the system allows the message to proceed. If not, processing stops.You can think of an Agreement as a contract between two systems. Unless a valid contract exists, the message cannot move forward.Agreement TemplatesAgreement template are created for the refernce of an actual agreement. It consist a desgin flow of how actual end-2-end B2B flow works. Who it the party (Our business or Trading partner), what all systems are involve, communication adapters information what messgae are we using, invlolved identifer. This is just a template where all the input values can be changed later on while creating an actual agreement.AgreementThis is the core of the B2B Advisory. While creating an agreement, you can take refernce of an existing agreement template so that a desing flow with the connected systems wil automatically populated.Working with copy with template –> agreement will copy the existing configuration available in selected template and give the option to modify as requried. (preferable choice)Working with bind with template –> agreement will bind with the existing configruation and doesnot allow to change configuration. Agreement OverviewThis include the overview of your agreement, who is the initiator, connected type system, SAP system and what are the identifers involve to check wether the incoming messgae have one of these identifer. These identifer are not entered manually instead is take refernce from the profile (Company/Trading profile). You have a option to create on prompt but advisable is to take refernce from the profile (Single/Group Identifer).Learning from agreementWhile creating an agreement sometime a confusion arise that, for one trading partner if we have multiple types of business transactions, then should we create multiple agreements. No, we have options to create multiple business transaction scenario in one agreement (inbound and outbound both). Don’t treat an agreement as one interface, agreement is something a contract between your orgnization and trading partner. So while create an agreement name it as per the involve trading partner.For custom formats there is not option I have found for the Custom type system, So I decided to use type system as “SAP S/4HANA On Premise IDoc” for Trading Partner (considered after various failed hit and try). As based on the Type system standard iFlow behaves differntly and most suitable to work with the XML “SAP S/4HANA On Premise IDoc” is best as per my R&D.We have options to create custom MIG & MAG under custom type system but there is no options I found to include those in the agreement. So I Have used standard MIG of each messgae for my Integration.While fetching the standard MIGs message version are available but there is no guarantee the SAP version you have will be available. In my case for ORDERS.ORDER05 have two versions “S4HANA 1709–Version – S4HANA 1709” and “1809_FPS02–Version – 1809_FPS02” and for DESADV.DELVRY07 I see only “1809_FPS02–Version – 1809_FPS02”. Where as in our landscape we have “S/4HANA 2023”. Key consideration is choosing different version on the IDoc may create issue, as the metadata available in yours SAP will not be the same available in the MIG you selected. So instead of choosing MIG in you mapping design, we refer the structure what is available in the SAP. Also, MIG selection is mandatory in the agreement and agreement is based on the Type System, so ultimatly in the Type system (Company/Trading partner profile’) mentioned version what you have in you SAP and what is available in you MIG. S/4HANA Version (MIG)ABAP/Basis Release (IDoc)17097521809753190975420207552023758 B2B ScenarioNext step will be creating the transactions all inbounds and outbounds with the selected trading partner, the actual business flow.Here we have the designed flow which have the prebuild steps as:Sender & Receiver can be your SAP system or Trading partner system depends on the what you have choose on the transaction create screen where Interchange have the message and involve type system version information (version/MIG can be editied manually).Other features what we have here are the Activity Paramters, Custom Search Attributes and Custom Rules. Activity Parameter –>These can be used for additional mapping logic. for example storing partner profile code, logical system deatils, port details, DUNS number, EDI messgae version, other hardcoded values per trading partner. These can be manually create or can be extend from Company/Trading parter profile. In short partner specific values can be maintained here.Custom Search Value –> To get more filters for the monitoring such as any messgae id, plant, ship-to, buyer-id etc. These can be added with the help of parameters, headers and XPath.Transaction ConfigurationAfter these configuration we have to start mantain the channels, mapping, MIG version etc. In the Source Communication we need to maintain the channle, these are not actual channle/adapter instead a template which we create in Company/Trading profile. Actual adapter which will pick the file, need to develop in cloud integration (IFlow designer) which will execute these agreement transaction.In the inerchnage mentioned the actual MIG used, Number range object, and the version of your SAP system. There are certain other options also we have in case those are requrired as per your requirement. As in my case I have the customized XML of EDIFact file I have used the MIG which is available for me for the business process I have and in the SAP Version I have chaged from original MIG to the one which we have in our landscape. I have used the same process for both sender/receiver interchange.Mapping Logic –> We have the option to execute the mapping developed in Cloud Integration via process direct or we can use the MAG whatever suite the requirement. In my case because of custom logics I am haved process direct which is calling a seperate iflow developed in cloud Integation.Once everythig is in there place after activating the agreement, all the information present till agreement will be executed in the partner directory data, which is the runtime enviournment for execution.Here the Activity Plain ID the the matching string, once that is found correct agreement will be executed else the that transaction will fail with the error “Agreement Configuration Access Failed”. What This Plan ID Template Represents –> The Agreement Plan ID is constructed by combining multiple message and partner attributes into a single structured string.sndAdapterType –> The communication adapter (Process_Direct, AS2, IDoc, etc.)sndDocumentStandard –> EDIFACT, X12, SAP_IDoc etc.sndMessageNamespace –> Namespace maintained in designsndMessageVersion –> Version like D96A, 758 etc.dynamic internal placeholder –> %ssndSenderIdQualifier –> Sender ID Identifier (single/group)sndSenderPartnerType –> Type of partner (Customer, Vendor)sndSenderSystemId –> Sender system identifiersndSenderSystemIdQualifier –> Qualifier for sender systemdynamic internal placeholder –> %ssndReceiverIdQualifier –> Receiver qualifiersndReceiverPartnerType –> Receiver partner typesndReceiverSystemId –> Receiver systemsndReceiverSystemIdQualifier –> Receiver qualifiersndMessageType –> Message type like ORDERSsndAdapterType + “-” + sndDocumentStandard + “-” + sndMessageNamespace + “-” + sndMessageVersion + “-%s-” + sndSenderIdQualifier + “-” + sndSenderPartnerType + “-” + sndSenderSystemId + “-” + sndSenderSystemIdQualifier + “-%s-” + sndReceiverIdQualifier + “-” + sndReceiverPartnerType + “-” + sndReceiverSystemId + “-” + sndReceiverSystemIdQualifier + “-” + sndMessageTypeThis is how an end-2-end configuration of agreement works. In the next step I will show how standard package behaves with this agreement and what changes I made in one of the flow for inbound custom XML based EDIFact.link (will be update once published) : Implementing B2B Advisory in SAP Integration Suite for Custom XML EDIFACT Scenarios part – 3 Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
