How to move an EDI provider (OpenText/Seeburger/home-grown EDI) to SAP BTP Integration Suite

[MichalKrawczyk]

Introduction 

In my previous blog “B2B/TPM on SAP BTP Integration Suite migration (SAP PO, Boomi, EDI Providers and home-grown apps) I tried to answer mostly the question Why does it make sense to move away from EDI providers and home-grown EDI applications to SAP BTP Integration Suite to be ready for next wave of integration explosive growth - 4 big waves for API led strategies and SAP BTP Integration Suite explosive growth.

 

In this article, I’d like to concentrate a bit more on the “How” question. What are the ways of working when doing such a big migration program and how can we secure it for two reasons:

• To guarantee to business continuity of the migration – no interface/EDI partner/Message type cannot be testing in a massive way to eliminate 100% of doubts that the integrations running on the SAP BTP Integration Suite will work flawlessly.
• We want to eliminate or reduce to minimum the involvement from the business/functional teams for testing – it’s a technical project so we don’t need to be blocked by other teams to finish such migration programs.

Question 1:  What is the general idea behind the EDI Provider/home-grown EDI migration to SAP BTP Integration Suite?

Answer 1: In order to safely migrate your EDI flows we will use a Test-Driven Approach (TDD) for the whole migration process. This means we will use the historical electronic messages (input and output) to create a repository of test cases (consisting of hundreds of messages for each message type/partner combination) in SAP BTP Integration Suite testing platform – Int4 Suite, and only as a second step we build the mappings in the SAP BTP Integration Suite. This way after each iteration of mapping development, the development team can quickly validate the progress of the mapping activity by rerunning all available test cases automatically. This process will ensure the 100% regression testing of the historical messages against the new mappings done in SAP BTP Integration Suite.

Question 2:  How can I load my historical EDI files and their corresponding SAP formats (IDOC, API, etc.) into the Int4 Suite to create the test case repository?

Answer 2: You can load the historical messages (EDI files from your EDI archive and their corresponding SAP formats) using the file loader functionality which allows for single pair (one input and one output) or massive file upload (multiple pairs of input and output messages).

 Figure – historical messages (EDI and SAP format) file loader function for Int4 Suite

Question 3:  How can I create the new EDI mappings in the SAP BTP Integration Suite?

Answer 3: Once you load the historical EDI messages and their corresponding SAP formats (IDOC, API, etc.) you can use SAP Integration Advisor to help you build the mappings and you can also use the  Mapping Proposal service to automatically generate those too - Leverage Integration Advisor (IA) to Generate Mapping Artifacts for SAP Integration Solutions

Question 4: Wait, but I want to change the SAP format from one to another (maybe IDOC to API) or even stay in the current format but extent it a little bit to have more common mappings on the SAP BTP Integration Suite, can I still use the Test-Driven Development?

Answer 4: Yes, you can! One of the functions of Int4 Suite is the possibility to execute a pre-mapping before doing a real test. This means that even if in the past you were using EDI to IDOC communication and you want to load this as your historical messages using the file loader functionality you can add a pre-mapping (XSLT) which can translate the IDOC into a new format – like a Web Service or OData during each run of the regression test as shown in the Figure below.

Figure – XSLT pre-mapping which can be executed to change the source or target test data format.

Question 5: How many times do I need to run the regression testing?

Answer 5: It depends, as a developer you may need to run it multiple times for a single mapping if you will be creating the mapping from scratch but remember doing a regression testing for 50-100 test cases (message variants) for each interface will just take a few minutes and the message compare will be done automatically. At a later stage (SIT and UAT testing) you may want to run the regression testing for all the EDI interfaces at once – this run may take even up to 30 mins if you want to regression test a few thousands of test cases.

Question 6: What about the volume testing, do I need to do it too?

Answer 6: We highly recommend doing real end to performance test using the peak hours requirements using Int4 Suite. SAP BTP Integration Suite is hosted on the cloud (with exception of the Edge Integration Cell) so it’s advisable to make sure the complete EDI flow can be processes according to the predefined conditions. Int4 Also allows you to do validate the speed of the postings or EDI messages on the SAP S/4HANA backend if required.

Further information:

For further reference on testing and simulating EDI partners, please have a look at our openSAP course: “Avoid SAP S/4HANA Project Delays with Third-Party Systems Service Virtualization”  Week 2 - Unit 2: “Simulating EDI partners based on historical transactions”