10 points to consider when building EDI B2B integrations with SAP CPI

[valivanov]

In the context of enterprise integration, many companies have already decided to consider SAP CPI as the main integration platform in their cloud or hybrid environment. Becoming an API-centric or API-first company could be a long road for many organizations that have an important EDI legacy, so transition to the cloud integration require also a very strong and clear EDI strategy. You will find in this post some of the points to consider before planning to build and run your EDI world using SAP Cloud Platform Integration.

 

1. Transition to cloud integration could be the perfect timing for an EDI assessment to check if your integrations are still valid and effective and if it makes sense to replace some of your old EDI integrations with a new and modern API approach. Check your partners, assess your mid and long term business development and evaluate the option of starting an API program in parallel with running some of the old EDI integrations.

2. You don't start from zero. Look over the SAP best practices, templates and prepackaged content. One option to start with are the EDI Integration Templates for SAP Cloud Platform Integration Advisor. There are a lot of documents and iFlows that you can analyze and have a solid start in what will be in the end your specific EDI approach.

3. Inspect all the features of the SAP Cloud Platform Integration Advisor and see how you can use it in your company. Try to understand the value of the tool as a whole. There could be many situations in the beginning when the automatic mapping proposal will not give you the expected results, but there are many other use cases of the service that could bring real value, one of them is  being a central point to handle message types and mapping documentation. With the latest updates we can also upload custom message types. Even if there are still some constraints regarding the XSD format that we can use, with some manual adjustments we can start using our own message types.

4. Design a SAP CPI EDI approach document and train your development team to follow these guidelines. Try to adapt your current EDI internal procedure to the new environment. Consider also building a set of iFlow templates to be used by the developers. With just a couple of important integration patterns, the majority of the EDI challenges can be technically solved. Templates will also allow having a unified and consolidated solution for general topics like security, message audit, sync or async acknowledgment or IDoc status management replication on the backend.

5. Don't build separate iFlows for each partner, group your integration scenarios based on message types, business scenario or 3rd party EDI platform and structure your integration flows to have in the end a minimum set of artifacts. One option will be to have a receiver flow, a mapping flow and a sender flow for each group. Once you decided about the flow structure, define an internal process for on-boarding new partners, that can include specific activities like:

• checking general mapping


• creating pre or post xslt


• creating pre or post flows


• adding records in Partner Directory


• running the regression tests cases


• approving the new partner to be deployed to productive

6. Partner Directory is a key component for maintaining specific partners attributes but also specific partners resources that can be uploaded with just a simple API call, without redeploying the flows ( XSLT Mappings or XSD files). If you have a large number of partners, consider building your own user interface for maintaining the directory data or choose some of the existing tools developed by the community. One example is Fatih Pense's tool. Consider using directory attributes to dynamically link the three main flows - sender, mapping and receiver.

7. Leverage and adapt the Integration Flow Extension concepts in the same way SAP standard flows are built to support customer enhancements. Pre-exit and post-exit concepts can be delivered in two flavors, either by calling a dynamic XSLT file read from the Partner Directory or in more complex situations with a separate flow called with Process Direct Adapter. These two options can be controlled also with Partner Directory attributes. In the end you will want to have a single general mapping per business process that is common for all your partners. For any partner specifics, use the pre-flow and post-flow extension points.

8. Check all the Parameterizable Integration Flow Components that can be linked automatically with the Partner Directory. Depending on your context you will choose which attributes are relevant to be set dynamic or static on partner level.

9. Limit your RFC destinations and ports when using IDoc as outbound protocol on the backend side. Structuring and grouping your CPI flows will help you also achieving this. You could have for example one RFC destination and port for each generic sender flow.

10. Don't underestimate the testing phase. Use a testing tool that can help you create and run automated test cases. Regression testing are crucial to be planned on every update of a general mapping, new partner on-boarding or deployment on a new tenant.

We all know that integrations are always context related and every customer implementation is unique, nevertheless it is always important to know our tools and options from the beginning when we have to take strategic decisions. Hope that this set of ideas will assist you in taking the best decisions for your EDI cloud integration implementation. If you already been there, please share your experience also.

[jmalla]

Hi Valentin,

In the PI/PO land, we did a lot of EDI mapping using SeeBurger.  For Cloud Platform Integration and the S/4 HANA Cloud, are the XSLT mappings provided by the EDI Integration Advisor package fairly comprehensive?  Were you able to use this package and the provided mapping without much tweaking?

It would be good to get your feedback.  Your blog is well written and you have some excellent points.

Thanks,

Jay

 

 

 

[valivanov]

Hi Jay,

Thanks for your comment. SAP is not providing with Integration Advisor a package with XSLT mappings, but proposals based on the crowd-based machine learning approach, which are very dependent on the context of your specific integration scenario, so consider EDI protocol, message type, business process, country, industry, etc.

In terms of EDI integrations in S/4HANA Cloud, I would suggest to start with checking the SAP Best  Practices, there is a special section dedicated to EDI Integration (with scope items like 2MB, 2EJ, 2EL). Then, you can move to Integration Advisor, create your own Message Implementation Guidelines and check what kinds of proposals are available for your specific scenarious.

Valentin

[jmalla]

Hi Valentin,

Thanks for your response.  For a lot of new videos on S/4 HANA Cloud integration, the advice is to use SOAP async messages instead of IDoc/BAPIs from the traditional perspective.  For S/4 HANA on premise, we are still using extensive IDoc integration scenarios that have been migrated from the older ECC days.

However, for a new S/4 HANA Cloud system - we wanted to just use SOAP as the output configuration.  The proposed mapping for ANSI X12 to SAP SOAP order did not generate any proposed mapping so that was a little disappointing.  Looks like we will need to develop that one from scratch - I need to research further and also look into the best practices in more detail.

Thanks,

Jay

 

[dineshhome1361_7]

Hi All.

Do we have any prepackaged content flows in CPI related to EDI

If anyone know , pls let me know

Thanks,

Dinesh

[former_member688062]

Hi Valentin,

Currently we are planning to intergrate US customers(EDI) via CPI. Can you suggest best approach for authentication instead of Client Certificate. Once in a year i have to share my new CPI certificate to all my EDI customers.

 

Thanks and Regards,

Raja

vbrsraja.sap@gmail.com