← All features

Migration

Mapping and function library migration

Your SAP PI message mappings depend on function libraries and UDFs, and rebuilding them for Cloud Integration by hand is slow and error-prone.

Teams using SAP PI have invested a lot of effort in their message mappings, and many of them use function libraries (FL) and user-defined functions (UDF). The Figaf Migration Tool migrates the message mappings to SAP Cloud Integration together with the functions they depend on, so you keep their value instead of rebuilding them. It is used by integration developers and migration teams moving from SAP PI/PO to SAP Integration Suite.

How it works

• Mappings with their dependencies. Figaf migrates message mappings with IDoc, RFC, external definitions and message and data types, including multi mappings. For RFC lookups it creates mock functions to make migration easier.
• Function libraries to Groovy. A function library can be converted into Groovy script files that are added as shared artifacts. If you change one of the Groovy scripts, Figaf can update all iFlows that use it. Figaf escapes characters such as $ that behave differently in Groovy than in Java and gives you a warning to check the result.
• Function libraries to SAP FL objects. Since release 2308, Figaf can migrate mappings to use SAP’s function library object in Cloud Integration, which relies on SAP’s import. That import does not support parameters, “all values of a queue” or functions without input, so those can still use Groovy functions.
• Mix both. Since release 2503 you can split a function library and choose per UDF whether it goes to Groovy or to the SAP FL object, since the FL object supports features such as the container object or all values of a queue that Groovy does not.
• Local UDFs. Since release 2402, local functions in a message mapping can be extracted to a MAPPINGNAME_udf.groovy script that you edit. Figaf shows which local functions are not used, so they are easy to delete, and keeps function descriptions in the code (patch 2402.1).
• Imported archives. Function libraries that use imported archives get the archives added to the iFlow, so the functions still work. Local UDFs that use imported archives are not supported, because of how Cloud Integration compiles the mapping.
• Parameters and lookups. Bindings of variables and constants are propagated to function libraries as externalized parameters in the iFlow, and parameters in advanced functions are resolved automatically. UDFs with lookups to Trading Partner or Directory APIs that will not work in Cloud Integration are commented out (release 2504).
• What stays manual. The PI Container object does not exist in Cloud Integration, so usage of container variables must be fixed by hand. Figaf checks the migrated code and warns when a mapping has extra imports.

Business value

• Reuse instead of rebuild. Mappings built over the last decade move with their functions, so the migration budget goes to the interfaces that really need redesign.
• Fewer surprises. Warnings and code checks point to the parts that need manual work, so effort can be estimated and assigned before the project is underway.
• Easier maintenance. Shared Groovy functions are updated in one place for all iFlows, and unused local functions can be removed.
• Less dependency on Java specialists. Converted functions are readable Groovy scripts that the team can edit and test in Figaf.
• Proof that it still works. Migrated mappings can be tested with Figaf against the original results, so differences are found early.

Good to know

• Migration of message mappings with function libraries has been supported since release 2107. Support for SAP’s function library object came in release 2308, and DevOps support for FL objects and imported archives lets you transport them.
• The Migration Edition gives you 10 free migrations to try both Groovy functions and function libraries.
• Related: legacy migration of existing assets and the Groovy editor with AI.

Learn more

• Figaf Migration Tool