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.
