The migration from SAP Process Integration/Process Orchestration (PI/PO) to Integration Suite for B2B is a critical step for organizations looking to modernize their integration landscape.
I saw a job post for a customer that wanted to migrate all their exiting partners to Integration Suite. And have been pondering if it is the best approach and my thoughts about the setup.
B2B mappings are the most complex mappings in most integration landscapes, but it is also one of the most standard driving setups. You wanted to have a standard process in place to add your new partners and configure them the most simple way. Here is how it can be done. It is a working prototype that we can improve.
The transition offers two primary pathways to a migration:
- Using Integration Content Advisor (ICA)
- Migrating existing message mappings to the cloud
- Move to another integration platform (not in the scope of this)
Both options come with their own sets of benefits and challenges. This blog is my ideas on this you should consider your own scenarios.
Option 1: Using Integration Content Advisor (ICA)
A Fresh Start
Opting for ICA allows you to create a new integration landscape from scratch. This is an opportunity to implement best practices and set up a more efficient and effective system in Cloud Integration.
ICA is designed to be compatible with the Integration Suite, making it easier to tailor your migration process to the platform’s specific requirements.
Easier to add new partners
If you add new partners then it is much faster because you have the practice and a modern partner setup to allow you to handle the cases.
The process can be time-intensive, especially if you’re not familiar with ICA. You’ll need to invest time in learning the tool and mapping out your new landscape.
Uncertainty Over Existing Mappings
If your existing mappings are complex, you may find it challenging to understand what was previously configured, leading to potential gaps or redundancies.
Lack of understanding of the differences between each mapping
If you have multiply mappings to INVOIC96A mappings then it can be a challenge to understand what the difference is between them. With Figaf you can easily compare multiply message mappings and spot the difference. This will speedup the process of creating variants of the same mapping. This is currently in our Free migration Edition.
Option 2: Migrating Existing Message Mappings to the Cloud
Here you use the existing message mappings and make a few adjustments into them to reuse as much of the business logic as possible.
Quick and Efficient
This option is generally faster and requires less effort compared to starting from scratch with ICA. Just migrate and get one with your flows and get started.
Since you’re migrating existing mappings, there’s less change management involved, making the transition smoother for your team.
You risk migrating some mappings that may not be optimized but are currently functional. This could lead to inefficiencies down the line. But you have probably not touched the mappings in a long period, so that will probably not change.
Implementation of new partners slower
It can be a bit slower to implement new partners in the setup because the message mappings maintenance can be a bit slower to maintain. But you can create new mappings in ICA if it helps your workflow.
Large dependency of B2B TPM
If you have leveraged the TPM with more than just header information but on contract and exchange level it can be more challenge to make a generic replacement function. It is something we need to explore how can be alleviated.
Current limitations of Messages Mapping migration
There are currently a number of challenges of migrating SAP PI TPM to Cloud Integration. Some of this can be resolved in a fairly short time.
Certain features like Trading Partner Management (TPM) are not supported and will need to be rewritten. I would imagine that this can become with a generic groovy script that packs a Exchange property and then modifying the TPM UDFs.
The B2B structure in the cloud may differ slightly, requiring adjustments. Figaf has worked on this before between Seeburger and B2B Mappings.
Figaf support migration of message mappings with all the main function libraries in different ways both as Groovy and by using SAP Function Libraries objects.
No matter what solution you use for the migration you should be testing that the new documents still create the same result. That way you dont need to involve your partners in the testing. You can use Figaf for testing such cases and you will need to run for both scenarios. That way, you can ensure that the new documents work the same way as before.
We currently do not support an end to end testing of the messages, but it is something that we will be building. It is an important part of the flows.
The reason I would use Integration Content Advisor (ICA) would be to reuse build a new platform that could handle my EDI. Does your current knowledge of your platform have some idea about generic mappings? I would consider not just move each integration separately.
I would try handling a migration of the message mappings. It is not the optimal solution but it will save you a lot of time building all your integration and migrating it.
I would recommend that you try out the Figaf mitigation tool and give the current status a try. We are also looking for customers that want to help us improve the end to end experience of the migration and let us try with real scenarios.