B2B on SAP Integration Suite – Cloud Integration – CPI – Part 12 – Migrating SAP PI / PO B2B Mappings without TPM

Post Views: 1,993

Introduction

The journey on the Trading Partner Management so far has looked at “avoiding” the usage of MAGs. This has been a conscious decision on my end as one of the “end objectives” of this series has been to look at SAP PO Migrations for B2B Mappings and how to leverage your existing investments on SAP PO for EDI B2B Mappings.

While migrating to MAGs and re-doing the mappings on MAGs is one option, realistically, PO to CPI migrations is not a “Business Driven Initiative” at most Customers, and “budget is always limited” and hence the pragmatic approach at most Customers has been to leverage the B2B Mappings built on SAP PO on Cloud Integration. Redoing the mappings on MAGs from a time, effort and testing standpoint is something customers we have worked with have wanted to avoid. Why break something that works has been the common phrase.

With that out of the way on why we have not used MAGs (yet), we will now in this post focus on how to Migrate SAP PO Message Mappings for EDIs to Integration Suite.

While this sounds easy and there are multiple SAP PO to Cloud Integration Migration tools ,including from SAP, B2B Mappings and their fitment into Trading Partner Management is not as straight forward. There are tricks and nuances to know and be aware of.

This post focuses on Adjusting Outbound EDI Mappings ,i.e., Mappings that generate EDIFACT messages in CPI to send to Partners without using TPM. In a subsequent post we will address Incoming EDI Messages and what needs to be “adjusted” in those mappings.

Note that we focus on NOT Using TPM in this post. How you migrate SAP PO Mappings into Integration Suite for B2B Mappings depends on whether you plan to use Trading Partner Management ( TPM) or not. This post focuses on your EDI Mappings without TPM, so a point to point B2B Interface in Integration Suite without TPM. In the next post we will extend this to use TPM.

While TPM has its benefits, Customers have also built point to point EDI Mappings and they find no value addition in using a Complex TPM Process and would like to use their SAP PO Mappings as is and migrate flows / mappings 1:1.

Pre-requisites

You have set up the connection between your SAP Integration Suite Cloud Integration and SAP PO. We will use the same scenario from Part 1.

We will in this post not look at the steps to Migrate or Import your Message Mappings from a On-Premise SAP PO System into Integration Suite. There already exists content on it that you can look into the References section.

Import SAP PO Mappings into Cloud Integration

We will import a Message Mapping from SAP PO to Cloud Integration. Before you can do that,

If you use Function Libraries that use Imported Archives in your Message Mapping, remove the use of those Function Library by copying the mapping into a Temp mapping and removing those fields and then import it into Integration Suite.
If you use Function Libraries without Imported Archives, ensure you follow the steps in this post to import the Function Library: SAP Integration Suite – Import PI/PO Function Library into Cloud Integration

This post starts with the assumption you have handled Function Libraries import and are aware of the limitation that Function Libraries with Imported Archives are currently not supported on Cloud Integration and is a road map item (As of Nov 2023).

Import and Deploy your EDI Message Mapping from SAP PO

You can also import the Message Mapping from your ESR directly in Integration flow but for now as we will use the Message Mapping in multiple IFlows, we have chosen the approach of importing your Message Mapping in the package.

Go to your Package ->Click on Add -> Message Mapping -> Select ES Repository ->Connect -> Select your Message Mapping and Click on Submit.

Add Message Mapping in Cloud Integration from ES Repository

Import Message Mapping from ES Repository

Select your Message Mapping and click on Submit

Your Message Mapping is imported into Cloud Integration

Note: Do not forget to Deploy your Message Mapping that you just imported!

Export your XSD from SAP PO

When you import your Message Mapping into Cloud Integration you will notice that the XSDs of your Message Mapping ( External Definitions as they are called on SAP PO ) are converted into WSDLs in Cloud Integration. SAP PO XSDs are compatible within Integration Suite, and hence, we also recommend you export your XSDs from SAP PO and have them locally, as we will use them in our next step.

Save this XSD with the naming convention for use in Cloud Integration. XML to EDI Conversion or EDI to XML Conversion in your Integration Flow demands that you have the name of the XSD with a specific name. In this case, as this is a EDIFACT Message, ensure the XSD is saved as UN-EDIFACT_DESADV_D96A.xsd.

Export SAP PO XSDs from ESR of your Message Mapping for EDI messages.

Run Mappings / IFlows without TPM

Create a Custom Integration Flow

We will create a Custom Integration Flow that references this message mapping from SAP PO that we just imported and then perform a XML to EDI Conversion. Let this Integration Flow have Entry Points as HTTP.

Custom Integration Flow Demoing the usage of B2B Mappings from SAP PO to Cloud Integration

Import Message Mapping ( Add Global References)

As a 1st Step created your Integration Flow and Add References to your Integration Flow to the Message Mapping we imported in the previous step.

Select your Message Mapping imported from SAP PO in previous section.

Import XSD from SAP PO

As we will test the SAP PO to CPI Migration Standalone for a EDI to XML Conversion, we will also import the XSD directly from SAP PO. As we have downloaded that in the previous section, import the XSD into your references section in the Integration Flow.

Extend your Integration Flow

Add the Mapping step to your Integration Flow.

Add Message Mapping Imported from SAP PO

Add the XML to EDI Convertor to your Integration Flow. Reference the XSD from previous imports.

This is how your Integration Flow Looks like now!

The Integration Flow for Testing your SAP PO Message Mappings for EDI.

Test Your Integration Flow

You are now ready to Test your Integration Flow. When you trigger your IDoc to this Integration Flow, technically the Mapping should get executed and XML to EDI Convertor should also get executed. But is it all simple as that? Will our Message Mappings work as is?

S_UNA Segment Not Allowed

The 1st error if all goes well after you have imported your SAP PO Message Mapping into Cloud Integration for EDI will be a error in the XML to EDI Conversion “java.lang.StringIndexOutOfBoundsException: String index out of range: 5.”

It took me sometime to figure out but in a typical SAP PO Mapping, we map the EDI Separators in the field S_UNA. Even if you use the default separators of EDIFACT :+.? ‘ -> your message will error. This is because in Cloud Integration your XML to EDI Conversion for Custom Separators has the configuration in the EDI to XML Conversion.

Hence, it is essential that after you Import your SAP PO Message Mappings into Cloud Integration you disable the S_UNA Field.

S_UNA Is not allowed in Cloud Integration

Disable S_UNA Segment in Cloud Integration

Adapt Mapping for Number Range Usage

Now when you run your Flow ideally your XML to EDI Conversion would have worked as is from SAP PO but you will probably notice that your EDI Control Record has variables like $B2B_END_UEBNR and so on.

This is because in SAP PO, you used the TransmissionNumberModule as a part of the SAP B2B Add On for SAP PO, to handle your Number range substitution. On Integration Suite, though these variables are not identified and your EDI to XML Conversion will not return the valid values for the Control Record of your EDI Message.

If you plan to migrate your B2B Mappings from SAP PO to Integration Suite / Cloud Integration without using TPM, you need to adjust your message mapping to use the right number range. As you would have seen in Part 1 , we define a Number range and you then need to adapt this your IFlow / Mapping to use this Number range.

Access Number Range and save in property

You would need to access the Number Range as a Property. In my case the Number Range is called ICN_DEFAULT and I store it as a property with the same name ICN_DEFAULT

Adjust your Mappings

Adapt your mapping to change the usage of these variables like $B2B_END_UEBNR to use the Property variable from previous section.

$B2B_SEG_COUNTER and its replacement

Your EDI Message will ideally now contain the Number Range object .But if you check deeper, you will find yourself asking the question: What about $B2B_SEG_COUNTER? An EDI Message has the count of segments and on SAP PO, you would ideally just use the variable $B2B_SEG_COUNTER and then your XML to EDI Convertor module (EDIFACTConvertor Module and so on) would handle this out of the box. But how do you do this on Cloud Integration? Do you actually need to write this logic into your message mapping?

Well thankfully no. While there are other options described ( See References section ) on the SAP Community they work on the assumption that you do not map the S_UNB / S_UNZ Segment in your Message Mapping ( which is how MIG works but not SAP PO ). Hence, for SAP PO, you are better off using the XSLT script that is a extension of the solutions from the reference section.

Note: To make this XSLT Dynamic, I have created a Parameter called “RootParam” that is declared as a property with the Value M_DESADV. You can adjust this accordingly for your other EDI Mappings.

Use this XSLT as the last step of your IFlow before the XML to EDI Convertor

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <!-- Declare the parameter -->
    <xsl:param name="RootParam"/>

    <!-- Identity transform template -->
    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
        </xsl:copy>
    </xsl:template>

    <!-- Special template for D_0074 within S_UNT -->
    <xsl:template match="S_UNT/D_0074">
        <xsl:copy>
            <!-- Use the parameter in the XPath expression -->
            <xsl:value-of select="count(//*[starts-with(name(), 'S_')][ancestor-or-self::*[name()=$RootParam]])"/>
        </xsl:copy>
    </xsl:template>
</xsl:stylesheet>

Test Your Flow Again

Now you can Test your SAP PO Mappings in Cloud Integration without TPM, and your EDI Message will be syntactically perfect.

Final Thoughts

Customers using B2B Mappings on SAP PO wanting to migrate them to Cloud Integration is a reality. There exists a genuine use case for SAP PO Mappings for EDI that are point to point mappings specifically set up for specific Trading Partners to not use TPM. In such cases, it might be prohibitive to use TPM and its entire feature set ( even though I am a fan of it ). For such straight forward cases where you want to migrate SAP PO Mappings directly to Cloud Integration without TPM this post provides a direct path.

In Summary, it is essential to remember that some adjustments are needed

S_UNA Segment Not Allowed in Cloud Integration
Adjust Mappings for $B2B_END_UEBNR and related number ranges used in your Mapping *Only needed as we are not using TPM
Adjust mappings for $B2B_SEG_COUNTER using a XSLT Mapping*Only needed as we are not using TPM
If your Message Mapping is using Function Libraries with Imported Archives on SAP PO, then that is not supported yet. It is on SAPs road map. In our case we have imported the Messaging Mapping by manually removing the dependencies and then adjusting the code in Cloud Integration accordingly in Message Mapping. Evaluate such mappings and if you can wait for SAPs migration to support it hold on before migrating such mappings. If you are confident, adjust them as we have done.

At the risk of sounding repetitive, this approach only makes sense if you have a point to point B2B Mapping that you want to migrate to Cloud Integration without TPM with minimal adjustments and code changes. It highlights some of the few adjustments you need to make!

In our next post, we will look at extending the same flow to use TPM based processing, and to allow for SAP PO Mappings to be used with TPM ( as has been the spirit of this series).