UPDATE: The Migration Assessment Report feature is available now and we recommend that you start trying it out if you are in the process of migrating your SAP PI Landscape. Read more about it here.
As you know by now, we have a tool that allows you to automate SAP PI to CPI migrations. It has a good number of features to simplify the migrations and also support in test and transport to production.
In the April (2204) release, we added an overview/cockpit screen of the migration. It is the place you start to plan your migration.
The idea of this feature is to show you all the information you need about which ICO has been migrated to which IFlow and if they are in production.
We have improved it in the releases since, to make the migration process easier.
SAP PI to CPI migration assessment
Usually after I talk about the Figaf Migration Tool, I often get the question: Can we get an assessment of what can be migrated? Our goal is to be able to migrate 70% of the migration and save 50% of the migration time. Moreover, the idea is to use this page to give users an idea about what ICO can be migrated and what should be migrated manually.
I also would like to apply statistical data to the integration so you would know this interface was running 406 times last month. That way you would know what data can be migrated.
I would like your help in understanding which rules to apply for this setting.
The idea is to download all artifacts that are related to each integration and then create a list of potential problems. So you on the overview page can understand these faster in the process.
My question to you is which rules would you like to see in this.
Roadmap
My current list is the following:
- Function Lib is using the container objects
- Function Lib or UDF is using Dynamic Attributes
- Mappings that use Database Lookups
- Java mapping, ABAP, ABAP XSL is used and would require the user to handle the migration from the old script to Groovy script manually. Yes in some cases Java mapping should be easy to migrate but it will require the source code or we decompile the mapping.
- RFC Sender adapter is used. This will in most cases require you to change the sending interface. Probably RFC over SOAP/HTML is the right way to go.
- File adapter without use of FTP
- Sync-Async bridge cannot be migrated easily because
- Are there adapter modules that need to be migrated? I think this will be a list of modules that can be migrated.
- Black listed adapters
- Use of B2B Integration or TPM module. Since the new model is not aligned with the old version it may require some rework to be able to reuse it.
- Integration pattern EO, EOIO, BE/Sync, Async-Sync, Sync-Async, EDI Separator it could be useful information for planning the migration
I’m not sure we will be able to reliably create rules for all of this, but it will be interesting. For now, I think of using this per ICO. However, it’s possible to extract it as a list of the objects that state that have this ABAP mapping in 4 different integration.
Are there other adapters that will be difficult to migrate to that should become problems for the migration?
