Make enterprise-ready iFlows from your migration to Integration Suite

[DG]

Regarding the migration from SAP PI/PO to Integration Suite, we have worked tirelessly on making it possible to migrate as many use cases as possible. Moreover, find solutions to allow developers to focus on the things that cannot be automated.

The capability of automating many portions or your migration to Integration Suite in the heart of the Figaf DevOps Suite, Migration Edition. With the free Migration Edition, you can perform tests of the migrated iFlows to check if they produce the same result in Integration Suite as they would in SAP PI/PO.
I really think this tool should be a part of your migration effort.

Automate your PI to Integration Suite

Even after winning the SAP Hack2Build competition with our initial Figaf Migration Tool (now included in the Migration Edition as a trial), we have been diligently improving our migration capabilities and functionalities. We know there is a need to speed up processes and over the last few months, we have been adding some powerful features to make the migration process more straightforward.

The goal has been to make the migration as smooth as possible, so you can automate as much as possible.

You first select what iflow you want to migrate. And how you want to perform the migration. What profile do you want to use, the Old (Default) or the new Beta? (We probably need to find a good name for it).

You can also filter receivers, so you don't need to send to all receivers and how map the channels to the Cloud Integration.

Overview of the migration

 

In the latest release, we now generate iflows with local processes for each receiver. This makes it a lot easier for you to manage and improve the options for error handling. We have added some already, but we will improve this with your feedback.

Each receiver is processed in a local process.

Retry of messages that fails via JMS. So if a message fails, it will only be put in a JMS queue if it fails. This makes it possible to retry single messages. There are ways we can improve this and would like to get your input.

Error handling part of the Flow

For message mappings, the following is supported.

• Message mappings that contain Function Libraries. Here the FL are converted into Groovy scripts. There is some difference, like the container object is changed.


• RFC Lookups is also migrated, but you must write your own RFC lookup code in Groovy.


• Mapping parameters are converted, added as a Groovy script, and mapped as external properties.


• Multiple mappings are supported by setting up the Message payload and splitting afterward.


• Migrated artifacts are remembered, so next time, you can reuse the migrated artifact and not have to perform the same correction again.


• Once you have migrated, you can, of course, try to test the migration.

With the migration edition this is a free trial of the tool, where you can try the migration tool and see how it performs in your integration. If you want it for your migration, it will cost 100 EUR pr ICO/receiver Deterimaion.

Starting with our free migration edition makes sense if you plan a migration project. You can run it on your laptop on SAP BTP. This will allow you to:

• Create an assessment of your landscape with some different data than SAPs. It may save you from some potential problems


• Test your migration by taking SAP PI/PO messages and using them on Cloud Integration


• Give you an overview of the migration


• Then you can try our migration tool and see which cases make sense.

You can see the tool in action here.