Introduction
Hello B2B Integration Community,
As more organizations shift from on-premise solutions to cloud-based platforms like SAP Integration Suite, a common challenge arises—how to preserve and reuse existing investments in B2B mapping content developed over years in SAP PI/PO. For companies heavily reliant on B2B integrations, this migration poses the critical question:
Can legacy SAP PI/PO mapping artifacts be leveraged in SAP Cloud Integration, particularly with Trading Partner Management (TPM)?
In this blog post, I’ll walk you through the solution provided by the B2B Integration Factory, which enables seamless reuse of PI/PO mappings. We will cover:
Key challenges in migrating B2B integration
The high-level architecture of the solution
Key implementation aspects
A configuration guide to help you get started
Key Challenges in Migrating B2B Mappings from SAP PI/PO to SAP Integration Suite
Before diving into the solution, it’s important to understand the primary challenges during the transition:
EDI Schema incompatibility: The hierarchical and segment-based structure and the differences in element naming conventions of EDI UN-EDIFACT, ASC-X12 and TRADACOMS messages does not align with the XML-based processing model used in SAP Integration Suite.
The B2B Integration Factory addresses these challenges by introducing a generic framework that translates PI/PO XML EDI messages into structured XML that conforms to the expectations of Cloud Integration and vice versa for all of the mentioned three type systems.
the overhead of building and maintaining a large number of custom integration flows, especially for B2B scenarios involving many trading partners
The B2B Integration Factory provides a generic framework in where you do not have to build and maintain individual flows.
gap in utilizing native B2B capabilities. Without a smart transition, the migration results in underutilization of built-in B2B features such as B2B Monitoring, Trading Partner Management (TPM), EDI validation and Business Documentation.
The B2B integration Factory’s solution simplifies the onboarding of trading partners using a repeatable configuration model compatible with TPM
High-Level Architecture Overview
The B2B Integration Factory bridges the gap between legacy SAP PI/PO B2B mappings and SAP Integration Suite, while enabling reuse, scalability, and compatibility with cloud-native B2B features like TPM and B2B Monitoring. The reusable generic framework dynamically handles all processing and removes the need to build custom flows for each partner and each message type. The following diagram illustrates how the dots are connected.
The mapping artifacts are decoupled from the flow and the sequence in the respective operating mapping is maintained as activity parameters in the corresponding Trading Partner Agreement (TPA)/Business Transaction Activity (BTA). The generic flow which will be called via custom mapping from each and every BTA is always the same. This flow dynamically reads the configured sequence from the TPM, locates the relevant mapping artifacts, and executes the defined transformation steps accordingly – including the resolution of EDI schema incompatibilities.
Key Implementation Aspects
Locating the relevant mapping artifact without hardcoding them into the integration flow is a key part of explaining the dynamic runtime behavior. To begin with, it is important to examine the possible execution sequence of the mapping logic:
Compliance with naming conventions and exact private key usage is required by the sequence. The table below outlines the parameter names, where $LoopIndex is a numeric index that has to be replaced by the relevant looped iteration.
Parameter KeyTypeParameter ValueMessageMapping_PreProc_XSLT_$LoopIndexBooleanOnly necessary and to be maintained if trueMessageMapping_PreProc_JAR_$LoopIndexStringProcessDirect Address to call the Java mappingMessageMapping_$LoopIndexStringName of the message mappingMessageMapping_PostProc_XSLT_$LoopIndexBooleanOnly necessary and to be maintained if trueMessageMapping_PostProc_JAR_$LoopIndexStringProcessDirect Address to call the Java mapping
There are three types of mapping programs, each located differently:
Message Mapping – Will be migrated via the Migration tool and deployed as an individual message mapping artifact together with the dependent Function Libraries:
XSLT Mapping – located in the Cloud Integration Partner Directory (b), where the PID is the unique TPM PID (a) without the prefix ‘SAP_TPM_’
Java Mapping Classes – currently not supported in the Cloud Integration Partner Directory. Therefore a separate flow will be called in where the jar is deployed. A groovy script calls then the relevant class.
A configuration guide to help you get started
To begin with, we have to update the B2B Integration Factory Packages to the latest version and in particular deploy the generic flow running in the background:
The Process_Direct Address has to be maintained in each TPA/BTA:
Further, it is important to highlight a key distinction between inbound and outbound transactions. For inbound transactions – that means EDI CPI XML data need to be converted to EDI PI XML data – the Namespace as well as the Namespace Prefix matters for the PI/PO message mapping. These can be maintained in the relevant BTA. Parameter Private values are SAP_B2B_MM_Namespace & SAP_B2B_MM_Namespace_Prefix:
For outbound transactions – that means EDI PI XML data need to be converted to EDI CPI XML data – there is no need to maintain any parameter for the EDI PI XML to EDI CPI XML conversion. The EDI schema incompatibility is handled out of the box in the background for UN-EDIFACT and ASC-X12 messages. The approach for TRADACOMS schema translation is slightly different due to the significant variations in the translations. Here the Cloud Integration Partner Directory again comes into picture:
Here the user has to create a PID = TRADACOMS and the ID has to follow the TRADACOMS EDI Standard (Type Systems –> TRADACOMS –> Messages):
Now as an example for the above use case the information of which type system, which message type and which version will be determined in runtime and a lookup is done to the Cloud Integration Partner Directory where the respective XSLT will be found which does the EDI schema translation. Here is a snippet of the .xsl for ORDHDR_FILE_9. You can follow the exact same pattern for your specific message type. And very important, it is a one time activity only per message type:
<?xml version=”1.0″ encoding=”UTF-8″?>
<xsl:stylesheet version=”2.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”
exclude-result-prefixes=”#all”>
<xsl:output method=”xml” encoding=”UTF-8″ indent=”yes”/>
<!–<xsl:param name=”SAP_B2B_MM_Namespace” select=”‘http://sap.com/xi/B2B/Examples/Tradacoms'”/>
<xsl:param name=”SAP_B2B_MM_Namespace_Prefix” select=”‘ns0′”/>
<xsl:param name=”SAP_EDI_Application_Reference” select=”‘ORDHDR'”/>
<xsl:param name=”SAP_EDI_Message_Version” select=”‘9′”/>–>
<xsl:param name=”SAP_B2B_MM_Namespace”/>
<xsl:param name=”SAP_B2B_MM_Namespace_Prefix”/>
<xsl:param name=”SAP_EDI_Application_Reference”/>
<xsl:param name=”SAP_EDI_Message_Version”/>
<!– Root template –>
<xsl:template match=”/”>
<xsl:variable name=”vTag” select=”concat($SAP_EDI_Application_Reference, ‘TO’, $SAP_EDI_Message_Version)”/>
<xsl:choose>
<xsl:when test=”$SAP_B2B_MM_Namespace_Prefix = ””>
<xsl:element name=”{$vTag}”>
<xsl:apply-templates select=”Interchange”/>
</xsl:element>
</xsl:when>
<xsl:otherwise>
<xsl:element name=”{$SAP_B2B_MM_Namespace_Prefix}:{$vTag}” namespace=”{$SAP_B2B_MM_Namespace}”>
<xsl:apply-templates select=”Interchange”/>
</xsl:element>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<xsl:template match=”Interchange”>
<!– S_STX –>
<S_STX>
<C_STDS>
<D_IDEN><xsl:value-of select=”S_STX/C_STDS/D_STDS1″/></D_IDEN>
<D_VERS><xsl:value-of select=”S_STX/C_STDS/D_STDS2″/></D_VERS>
</C_STDS>
<C_FROM>
<D_CODE><xsl:value-of select=”S_STX/C_FROM/D_FROM1″/></D_CODE>
<D_NAME><xsl:value-of select=”S_STX/C_FROM/D_FROM2″/></D_NAME>
</C_FROM>
<C_UNTO>
<D_CODE><xsl:value-of select=”S_STX/C_UNTO/D_UNTO1″/></D_CODE>
</C_UNTO>
<C_TRDT>
<D_DATE><xsl:value-of select=”S_STX/C_TRDT/D_TRDT1″/></D_DATE>
<D_TIME><xsl:value-of select=”S_STX/C_TRDT/D_TRDT2″/></D_TIME>
</C_TRDT>
<D_SNRF><xsl:value-of select=”S_STX/D_SNRF”/></D_SNRF>
<D_RCRF><!– placeholder –></D_RCRF>
<D_APRF><xsl:value-of select=”S_STX/D_APRF”/></D_APRF>
<D_PRCD><!– placeholder –></D_PRCD>
</S_STX>
<!– ORDHDR segment –>
<ORDHDR>
<S_MHD>
<D_MSRF><xsl:value-of select=”M_ORDHDR/S_MHD/D_MSRF”/></D_MSRF>
<C_TYPE>
<D_TYPE><xsl:value-of select=”M_ORDHDR/S_MHD/C_TYPE/D_TYPE1″/></D_TYPE>
<D_VSNR><xsl:value-of select=”M_ORDHDR/S_MHD/C_TYPE/D_TYPE2″/></D_VSNR>
</C_TYPE>
</S_MHD>
<S_TYP>
<D_TCDE><xsl:value-of select=”M_ORDHDR/S_TYP/D_TCDE”/></D_TCDE>
</S_TYP>
<S_SDT>
<C_SIDN>
<D_SALC><xsl:value-of select=”M_ORDHDR/S_SDT/C_SIDN/D_SIDN2″/></D_SALC>
<D_SIAC><!– placeholder –></D_SIAC>
</C_SIDN>
<D_SNAM><xsl:value-of select=”M_ORDHDR/S_SDT/C_SIDN/D_SIDN1″/></D_SNAM>
</S_SDT>
<S_CDT>
<C_CIDN>
<D_CAID><xsl:value-of select=”M_ORDHDR/S_CDT/C_CIDN/D_CIDN1″/></D_CAID>
</C_CIDN>
<D_CNAM><xsl:value-of select=”M_ORDHDR/S_CDT/D_CNAM”/></D_CNAM>
</S_CDT>
<S_FIL>
<D_FLGN><xsl:value-of select=”M_ORDHDR/S_FIL/D_FLGN”/></D_FLGN>
<D_FLVN><xsl:value-of select=”M_ORDHDR/S_FIL/D_FLVN”/></D_FLVN>
<D_FLDT><xsl:value-of select=”M_ORDHDR/S_FIL/D_FLDT”/></D_FLDT>
</S_FIL>
<S_MTR>
<D_NOSG><xsl:value-of select=”M_ORDHDR/S_MTR/D_NOSG”/></D_NOSG>
</S_MTR>
</ORDHDR>
<!– ORDERS segment –>
<ORDERS>
<S_MHD>
<D_MSRF><xsl:value-of select=”M_ORDERS/S_MHD/D_MSRF”/></D_MSRF>
<C_TYPE>
<D_TYPE><xsl:value-of select=”M_ORDERS/S_MHD/C_TYPE/D_TYPE1″/></D_TYPE>
<D_VSNR><xsl:value-of select=”M_ORDERS/S_MHD/C_TYPE/D_TYPE2″/></D_VSNR>
</C_TYPE>
</S_MHD>
<S_CLO>
<C_CLOC>
<D_CALC><xsl:value-of select=”M_ORDERS/S_CLO/C_CLOC/D_CLOC1″/></D_CALC>
</C_CLOC>
<D_CNAM><xsl:value-of select=”M_ORDERS/S_CLO/D_CNAM”/></D_CNAM>
<C_CADD>
<D_CAL1><xsl:value-of select=”M_ORDERS/S_CLO/C_CADD/D_CADD1″/></D_CAL1>
<D_CAL2><xsl:value-of select=”M_ORDERS/S_CLO/C_CADD/D_CADD2″/></D_CAL2>
<D_CAL3><xsl:value-of select=”M_ORDERS/S_CLO/C_CADD/D_CADD3″/></D_CAL3>
<D_CAL4><xsl:value-of select=”M_ORDERS/S_CLO/C_CADD/D_CADD4″/></D_CAL4>
<D_CUPC><xsl:value-of select=”M_ORDERS/S_CLO/C_CADD/D_CADD5″/></D_CUPC>
</C_CADD>
</S_CLO>
<S_ORD>
<C_ORNO>
<D_CONR><xsl:value-of select=”M_ORDERS/S_ORD/C_ORNO/D_ORNO1″/></D_CONR>
<D_DOPC><xsl:value-of select=”M_ORDERS/S_ORD/C_ORNO/D_ORNO3″/></D_DOPC>
</C_ORNO>
<D_CLAS><!– placeholder –></D_CLAS>
<D_ORCD><!– placeholder –></D_ORCD>
</S_ORD>
<S_DIN>
<D_EDAT><xsl:value-of select=”M_ORDERS/S_DIN/D_EDAT”/></D_EDAT>
</S_DIN>
<xsl:for-each select=”M_ORDERS/G_OLD/S_OLD”>
<L_OLD>
<S_OLD>
<D_SEQA><xsl:value-of select=”D_SEQA”/></D_SEQA>
<C_SPRO>
<D_EANC><xsl:value-of select=”C_SPRO/D_SPRO1″/></D_EANC>
</C_SPRO>
<C_CPRO>
<D_CITC><xsl:value-of select=”C_CPRO/D_CPRO2″/></D_CITC>
</C_CPRO>
<C_UNOR>
<D_CUTU><xsl:value-of select=”C_UNOR/D_UNOR1″/></D_CUTU>
</C_UNOR>
<C_OQTY>
<D_NTUO><xsl:value-of select=”C_OQTY/D_OQTY1″/></D_NTUO>
</C_OQTY>
<C_OUCT>
<D_CPRC><xsl:value-of select=”C_OUCT/D_OUCT1″/></D_CPRC>
</C_OUCT>
<C_TDES>
<D_TUL1><xsl:value-of select=”C_TDES/D_TDES1″/></D_TUL1>
</C_TDES>
</S_OLD>
</L_OLD>
</xsl:for-each>
<S_OTR><D_LORD><xsl:value-of select=”M_ORDERS/S_OTR/D_LORD”/></D_LORD></S_OTR>
<S_MTR><D_NOSG><xsl:value-of select=”M_ORDERS/S_MTR/D_NOSG”/></D_NOSG></S_MTR>
</ORDERS>
<!– ORDTLR segment –>
<ORDTLR>
<S_MHD>
<D_MSRF><xsl:value-of select=”M_ORDTLR/S_MHD/D_MSRF”/></D_MSRF>
<C_TYPE>
<D_TYPE><xsl:value-of select=”M_ORDTLR/S_MHD/C_TYPE/D_TYPE1″/></D_TYPE>
<D_VSNR><xsl:value-of select=”M_ORDTLR/S_MHD/C_TYPE/D_TYPE2″/></D_VSNR>
</C_TYPE>
</S_MHD>
<S_OFT><D_FTOR><xsl:value-of select=”M_ORDTLR/S_OFT/D_FTOR”/></D_FTOR></S_OFT>
<S_MTR><D_NOSG><xsl:value-of select=”M_ORDTLR/S_MTR/D_NOSG”/></D_NOSG></S_MTR>
</ORDTLR>
<!– Trailer –>
<S_END><D_NMST><xsl:value-of select=”S_END/D_NMST”/></D_NMST></S_END>
</xsl:template>
</xsl:stylesheet>
Now, let’s deep dive into two practical scenarios – one UN-EDIFACT DELFOR inbound and the other UN-EDIFACT DESADV outbound.
Inbound UN-EDIFACT Case
As we have seen so far the ultimate goal is to decouple the mapping artifacts and to control the automation via just setting Activity parameters in the TPA/BTA:
The first two parameters are already explained above. Now additionally by following the naming conventions we can also see the sequence in the Operating Mapping. In this case we first run a XSLT mapping and then the message mapping. The last parameter is to indicate that the Assembly process is not necessarily needed.
And that is all we have to do. Now let us see how it looks in runtime, especially in B2B Monitor:
We can see that the PI/PO artifacts are linked to TPM and thus also to B2B Monitoring. Inside each interchange there are several events and for the transformation part the ‘Sender Interchange Mapped’ event is of interest. By clicking on the hyperlink you are re-directed to the MPL Log of the relevant Flow:
Here we also do log the artifacts in Custom Headers. Particularly to enhance user experience and to facilitate operational excellence. Since the XSLTs are stored in the Cloud Integration Partner Directory the Custom Header directly tell where exactly that particular .xsl is stored.
Additionaly, important and only relevant for unit testing, we are also writing attachments to track each transformation step:
Outbound UN-EDIFACT Case
Again the approach is to deploy the mapping artifacts and then set the relevant Activity parameters:
Here, the last Message Mapping is just a 1:1 mapping from the output of Message Mapping 2. That should illustrate that we can have an endless sequence which will be supported in the framework. In B2B Monitor:
And there is more
The solution comes from the B2B Integration Factory initiative and was designed for the B2B Integration Factory packages. However, it was designed in such a way that the flow is fully compatible with the SAP standard TPM V2 packages:
Additional benefits
The solution leverages the B2B capabilities with their full functionalities, which allows users using the retry and restart functionality from B2B MonitorSince the mapping artifacts are decoupled, fixes can be applied directly within the mapping itself—no flow deployment is required – and the message can be re-triggered using the B2B MonitorScaleable migration process – there is no need to build and maintain individual flows.
This is also where the product vision is heading towards. Users should maintain their requirements with the trading partners in the TPM only. The number of flows should be reduced to a minimum.
IntroductionHello B2B Integration Community,As more organizations shift from on-premise solutions to cloud-based platforms like SAP Integration Suite, a common challenge arises—how to preserve and reuse existing investments in B2B mapping content developed over years in SAP PI/PO. For companies heavily reliant on B2B integrations, this migration poses the critical question:Can legacy SAP PI/PO mapping artifacts be leveraged in SAP Cloud Integration, particularly with Trading Partner Management (TPM)?In this blog post, I’ll walk you through the solution provided by the B2B Integration Factory, which enables seamless reuse of PI/PO mappings. We will cover:Key challenges in migrating B2B integrationThe high-level architecture of the solutionKey implementation aspectsA configuration guide to help you get startedKey Challenges in Migrating B2B Mappings from SAP PI/PO to SAP Integration SuiteBefore diving into the solution, it’s important to understand the primary challenges during the transition:EDI Schema incompatibility: The hierarchical and segment-based structure and the differences in element naming conventions of EDI UN-EDIFACT, ASC-X12 and TRADACOMS messages does not align with the XML-based processing model used in SAP Integration Suite.The B2B Integration Factory addresses these challenges by introducing a generic framework that translates PI/PO XML EDI messages into structured XML that conforms to the expectations of Cloud Integration and vice versa for all of the mentioned three type systems.the overhead of building and maintaining a large number of custom integration flows, especially for B2B scenarios involving many trading partnersThe B2B Integration Factory provides a generic framework in where you do not have to build and maintain individual flows.gap in utilizing native B2B capabilities. Without a smart transition, the migration results in underutilization of built-in B2B features such as B2B Monitoring, Trading Partner Management (TPM), EDI validation and Business Documentation.The B2B integration Factory’s solution simplifies the onboarding of trading partners using a repeatable configuration model compatible with TPMHigh-Level Architecture OverviewThe B2B Integration Factory bridges the gap between legacy SAP PI/PO B2B mappings and SAP Integration Suite, while enabling reuse, scalability, and compatibility with cloud-native B2B features like TPM and B2B Monitoring. The reusable generic framework dynamically handles all processing and removes the need to build custom flows for each partner and each message type. The following diagram illustrates how the dots are connected. The mapping artifacts are decoupled from the flow and the sequence in the respective operating mapping is maintained as activity parameters in the corresponding Trading Partner Agreement (TPA)/Business Transaction Activity (BTA). The generic flow which will be called via custom mapping from each and every BTA is always the same. This flow dynamically reads the configured sequence from the TPM, locates the relevant mapping artifacts, and executes the defined transformation steps accordingly – including the resolution of EDI schema incompatibilities.Key Implementation AspectsLocating the relevant mapping artifact without hardcoding them into the integration flow is a key part of explaining the dynamic runtime behavior. To begin with, it is important to examine the possible execution sequence of the mapping logic:Compliance with naming conventions and exact private key usage is required by the sequence. The table below outlines the parameter names, where $LoopIndex is a numeric index that has to be replaced by the relevant looped iteration.Parameter KeyTypeParameter ValueMessageMapping_PreProc_XSLT_$LoopIndexBooleanOnly necessary and to be maintained if trueMessageMapping_PreProc_JAR_$LoopIndexStringProcessDirect Address to call the Java mappingMessageMapping_$LoopIndexStringName of the message mappingMessageMapping_PostProc_XSLT_$LoopIndexBooleanOnly necessary and to be maintained if trueMessageMapping_PostProc_JAR_$LoopIndexStringProcessDirect Address to call the Java mappingThere are three types of mapping programs, each located differently:Message Mapping – Will be migrated via the Migration tool and deployed as an individual message mapping artifact together with the dependent Function Libraries:XSLT Mapping – located in the Cloud Integration Partner Directory (b), where the PID is the unique TPM PID (a) without the prefix ‘SAP_TPM_’Java Mapping Classes – currently not supported in the Cloud Integration Partner Directory. Therefore a separate flow will be called in where the jar is deployed. A groovy script calls then the relevant class.A configuration guide to help you get startedTo begin with, we have to update the B2B Integration Factory Packages to the latest version and in particular deploy the generic flow running in the background: The Process_Direct Address has to be maintained in each TPA/BTA:Further, it is important to highlight a key distinction between inbound and outbound transactions. For inbound transactions – that means EDI CPI XML data need to be converted to EDI PI XML data – the Namespace as well as the Namespace Prefix matters for the PI/PO message mapping. These can be maintained in the relevant BTA. Parameter Private values are SAP_B2B_MM_Namespace & SAP_B2B_MM_Namespace_Prefix:For outbound transactions – that means EDI PI XML data need to be converted to EDI CPI XML data – there is no need to maintain any parameter for the EDI PI XML to EDI CPI XML conversion. The EDI schema incompatibility is handled out of the box in the background for UN-EDIFACT and ASC-X12 messages. The approach for TRADACOMS schema translation is slightly different due to the significant variations in the translations. Here the Cloud Integration Partner Directory again comes into picture:Here the user has to create a PID = TRADACOMS and the ID has to follow the TRADACOMS EDI Standard (Type Systems –> TRADACOMS –> Messages):Now as an example for the above use case the information of which type system, which message type and which version will be determined in runtime and a lookup is done to the Cloud Integration Partner Directory where the respective XSLT will be found which does the EDI schema translation. Here is a snippet of the .xsl for ORDHDR_FILE_9. You can follow the exact same pattern for your specific message type. And very important, it is a one time activity only per message type:<?xml version=”1.0″ encoding=”UTF-8″?>
<xsl:stylesheet version=”2.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”
exclude-result-prefixes=”#all”>
<xsl:output method=”xml” encoding=”UTF-8″ indent=”yes”/>
<!–<xsl:param name=”SAP_B2B_MM_Namespace” select=”‘http://sap.com/xi/B2B/Examples/Tradacoms'”/>
<xsl:param name=”SAP_B2B_MM_Namespace_Prefix” select=”‘ns0′”/>
<xsl:param name=”SAP_EDI_Application_Reference” select=”‘ORDHDR'”/>
<xsl:param name=”SAP_EDI_Message_Version” select=”‘9′”/>–>
<xsl:param name=”SAP_B2B_MM_Namespace”/>
<xsl:param name=”SAP_B2B_MM_Namespace_Prefix”/>
<xsl:param name=”SAP_EDI_Application_Reference”/>
<xsl:param name=”SAP_EDI_Message_Version”/>
<!– Root template –>
<xsl:template match=”/”>
<xsl:variable name=”vTag” select=”concat($SAP_EDI_Application_Reference, ‘TO’, $SAP_EDI_Message_Version)”/>
<xsl:choose>
<xsl:when test=”$SAP_B2B_MM_Namespace_Prefix = ””>
<xsl:element name=”{$vTag}”>
<xsl:apply-templates select=”Interchange”/>
</xsl:element>
</xsl:when>
<xsl:otherwise>
<xsl:element name=”{$SAP_B2B_MM_Namespace_Prefix}:{$vTag}” namespace=”{$SAP_B2B_MM_Namespace}”>
<xsl:apply-templates select=”Interchange”/>
</xsl:element>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<xsl:template match=”Interchange”>
<!– S_STX –>
<S_STX>
<C_STDS>
<D_IDEN><xsl:value-of select=”S_STX/C_STDS/D_STDS1″/></D_IDEN>
<D_VERS><xsl:value-of select=”S_STX/C_STDS/D_STDS2″/></D_VERS>
</C_STDS>
<C_FROM>
<D_CODE><xsl:value-of select=”S_STX/C_FROM/D_FROM1″/></D_CODE>
<D_NAME><xsl:value-of select=”S_STX/C_FROM/D_FROM2″/></D_NAME>
</C_FROM>
<C_UNTO>
<D_CODE><xsl:value-of select=”S_STX/C_UNTO/D_UNTO1″/></D_CODE>
</C_UNTO>
<C_TRDT>
<D_DATE><xsl:value-of select=”S_STX/C_TRDT/D_TRDT1″/></D_DATE>
<D_TIME><xsl:value-of select=”S_STX/C_TRDT/D_TRDT2″/></D_TIME>
</C_TRDT>
<D_SNRF><xsl:value-of select=”S_STX/D_SNRF”/></D_SNRF>
<D_RCRF><!– placeholder –></D_RCRF>
<D_APRF><xsl:value-of select=”S_STX/D_APRF”/></D_APRF>
<D_PRCD><!– placeholder –></D_PRCD>
</S_STX>
<!– ORDHDR segment –>
<ORDHDR>
<S_MHD>
<D_MSRF><xsl:value-of select=”M_ORDHDR/S_MHD/D_MSRF”/></D_MSRF>
<C_TYPE>
<D_TYPE><xsl:value-of select=”M_ORDHDR/S_MHD/C_TYPE/D_TYPE1″/></D_TYPE>
<D_VSNR><xsl:value-of select=”M_ORDHDR/S_MHD/C_TYPE/D_TYPE2″/></D_VSNR>
</C_TYPE>
</S_MHD>
<S_TYP>
<D_TCDE><xsl:value-of select=”M_ORDHDR/S_TYP/D_TCDE”/></D_TCDE>
</S_TYP>
<S_SDT>
<C_SIDN>
<D_SALC><xsl:value-of select=”M_ORDHDR/S_SDT/C_SIDN/D_SIDN2″/></D_SALC>
<D_SIAC><!– placeholder –></D_SIAC>
</C_SIDN>
<D_SNAM><xsl:value-of select=”M_ORDHDR/S_SDT/C_SIDN/D_SIDN1″/></D_SNAM>
</S_SDT>
<S_CDT>
<C_CIDN>
<D_CAID><xsl:value-of select=”M_ORDHDR/S_CDT/C_CIDN/D_CIDN1″/></D_CAID>
</C_CIDN>
<D_CNAM><xsl:value-of select=”M_ORDHDR/S_CDT/D_CNAM”/></D_CNAM>
</S_CDT>
<S_FIL>
<D_FLGN><xsl:value-of select=”M_ORDHDR/S_FIL/D_FLGN”/></D_FLGN>
<D_FLVN><xsl:value-of select=”M_ORDHDR/S_FIL/D_FLVN”/></D_FLVN>
<D_FLDT><xsl:value-of select=”M_ORDHDR/S_FIL/D_FLDT”/></D_FLDT>
</S_FIL>
<S_MTR>
<D_NOSG><xsl:value-of select=”M_ORDHDR/S_MTR/D_NOSG”/></D_NOSG>
</S_MTR>
</ORDHDR>
<!– ORDERS segment –>
<ORDERS>
<S_MHD>
<D_MSRF><xsl:value-of select=”M_ORDERS/S_MHD/D_MSRF”/></D_MSRF>
<C_TYPE>
<D_TYPE><xsl:value-of select=”M_ORDERS/S_MHD/C_TYPE/D_TYPE1″/></D_TYPE>
<D_VSNR><xsl:value-of select=”M_ORDERS/S_MHD/C_TYPE/D_TYPE2″/></D_VSNR>
</C_TYPE>
</S_MHD>
<S_CLO>
<C_CLOC>
<D_CALC><xsl:value-of select=”M_ORDERS/S_CLO/C_CLOC/D_CLOC1″/></D_CALC>
</C_CLOC>
<D_CNAM><xsl:value-of select=”M_ORDERS/S_CLO/D_CNAM”/></D_CNAM>
<C_CADD>
<D_CAL1><xsl:value-of select=”M_ORDERS/S_CLO/C_CADD/D_CADD1″/></D_CAL1>
<D_CAL2><xsl:value-of select=”M_ORDERS/S_CLO/C_CADD/D_CADD2″/></D_CAL2>
<D_CAL3><xsl:value-of select=”M_ORDERS/S_CLO/C_CADD/D_CADD3″/></D_CAL3>
<D_CAL4><xsl:value-of select=”M_ORDERS/S_CLO/C_CADD/D_CADD4″/></D_CAL4>
<D_CUPC><xsl:value-of select=”M_ORDERS/S_CLO/C_CADD/D_CADD5″/></D_CUPC>
</C_CADD>
</S_CLO>
<S_ORD>
<C_ORNO>
<D_CONR><xsl:value-of select=”M_ORDERS/S_ORD/C_ORNO/D_ORNO1″/></D_CONR>
<D_DOPC><xsl:value-of select=”M_ORDERS/S_ORD/C_ORNO/D_ORNO3″/></D_DOPC>
</C_ORNO>
<D_CLAS><!– placeholder –></D_CLAS>
<D_ORCD><!– placeholder –></D_ORCD>
</S_ORD>
<S_DIN>
<D_EDAT><xsl:value-of select=”M_ORDERS/S_DIN/D_EDAT”/></D_EDAT>
</S_DIN>
<xsl:for-each select=”M_ORDERS/G_OLD/S_OLD”>
<L_OLD>
<S_OLD>
<D_SEQA><xsl:value-of select=”D_SEQA”/></D_SEQA>
<C_SPRO>
<D_EANC><xsl:value-of select=”C_SPRO/D_SPRO1″/></D_EANC>
</C_SPRO>
<C_CPRO>
<D_CITC><xsl:value-of select=”C_CPRO/D_CPRO2″/></D_CITC>
</C_CPRO>
<C_UNOR>
<D_CUTU><xsl:value-of select=”C_UNOR/D_UNOR1″/></D_CUTU>
</C_UNOR>
<C_OQTY>
<D_NTUO><xsl:value-of select=”C_OQTY/D_OQTY1″/></D_NTUO>
</C_OQTY>
<C_OUCT>
<D_CPRC><xsl:value-of select=”C_OUCT/D_OUCT1″/></D_CPRC>
</C_OUCT>
<C_TDES>
<D_TUL1><xsl:value-of select=”C_TDES/D_TDES1″/></D_TUL1>
</C_TDES>
</S_OLD>
</L_OLD>
</xsl:for-each>
<S_OTR><D_LORD><xsl:value-of select=”M_ORDERS/S_OTR/D_LORD”/></D_LORD></S_OTR>
<S_MTR><D_NOSG><xsl:value-of select=”M_ORDERS/S_MTR/D_NOSG”/></D_NOSG></S_MTR>
</ORDERS>
<!– ORDTLR segment –>
<ORDTLR>
<S_MHD>
<D_MSRF><xsl:value-of select=”M_ORDTLR/S_MHD/D_MSRF”/></D_MSRF>
<C_TYPE>
<D_TYPE><xsl:value-of select=”M_ORDTLR/S_MHD/C_TYPE/D_TYPE1″/></D_TYPE>
<D_VSNR><xsl:value-of select=”M_ORDTLR/S_MHD/C_TYPE/D_TYPE2″/></D_VSNR>
</C_TYPE>
</S_MHD>
<S_OFT><D_FTOR><xsl:value-of select=”M_ORDTLR/S_OFT/D_FTOR”/></D_FTOR></S_OFT>
<S_MTR><D_NOSG><xsl:value-of select=”M_ORDTLR/S_MTR/D_NOSG”/></D_NOSG></S_MTR>
</ORDTLR>
<!– Trailer –>
<S_END><D_NMST><xsl:value-of select=”S_END/D_NMST”/></D_NMST></S_END>
</xsl:template>
</xsl:stylesheet>Now, let’s deep dive into two practical scenarios – one UN-EDIFACT DELFOR inbound and the other UN-EDIFACT DESADV outbound. Inbound UN-EDIFACT CaseAs we have seen so far the ultimate goal is to decouple the mapping artifacts and to control the automation via just setting Activity parameters in the TPA/BTA:The first two parameters are already explained above. Now additionally by following the naming conventions we can also see the sequence in the Operating Mapping. In this case we first run a XSLT mapping and then the message mapping. The last parameter is to indicate that the Assembly process is not necessarily needed. And that is all we have to do. Now let us see how it looks in runtime, especially in B2B Monitor:We can see that the PI/PO artifacts are linked to TPM and thus also to B2B Monitoring. Inside each interchange there are several events and for the transformation part the ‘Sender Interchange Mapped’ event is of interest. By clicking on the hyperlink you are re-directed to the MPL Log of the relevant Flow:Here we also do log the artifacts in Custom Headers. Particularly to enhance user experience and to facilitate operational excellence. Since the XSLTs are stored in the Cloud Integration Partner Directory the Custom Header directly tell where exactly that particular .xsl is stored. Additionaly, important and only relevant for unit testing, we are also writing attachments to track each transformation step:Outbound UN-EDIFACT CaseAgain the approach is to deploy the mapping artifacts and then set the relevant Activity parameters:Here, the last Message Mapping is just a 1:1 mapping from the output of Message Mapping 2. That should illustrate that we can have an endless sequence which will be supported in the framework. In B2B Monitor:And there is moreThe solution comes from the B2B Integration Factory initiative and was designed for the B2B Integration Factory packages. However, it was designed in such a way that the flow is fully compatible with the SAP standard TPM V2 packages:Additional benefitsThe solution leverages the B2B capabilities with their full functionalities, which allows users using the retry and restart functionality from B2B MonitorSince the mapping artifacts are decoupled, fixes can be applied directly within the mapping itself—no flow deployment is required – and the message can be re-triggered using the B2B MonitorScaleable migration process – there is no need to build and maintain individual flows.This is also where the product vision is heading towards. Users should maintain their requirements with the trading partners in the TPM only. The number of flows should be reduced to a minimum. Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
