Supported cases

If ICO or RD scenario has the same Interface declared several times, the migrated IFlow(s) could have some problems.

The following ICO and RD scenarios are supported for migration:

  • Standard async scenarios

  • Sync scenarios

  • Scenarios with receiver, interface, and operation-specific routing

  • Scenarios with extended receiver

  • With simple or compound XPath conditions

  • Supported operators: =, !=, EX, ≈.

  • Scenarios with message mappings

    • With schemas

      • External definition (incl. WSDL and usage of imports)

      • Message Type (incl. Data Types)

    • With User Defined Function (Function Library)

    • OM with multiple MM support

    • OM with Java mapping

      Empty groovy script will be added to the migrated IFlow.

    • OM with ABAP mapping

      There is only a warning in Migration logs. Nothing will be added to the migrated IFlow.

    • OM with XSL mapping

    • OM with Fault Mapping programs

      Fault mapping program is migrated and added to the IFlow resources but the corresponding IFlow step should be added manually.

    • OM with Java Mapping

      To support it Figaf tool adds Content Modifier with the corresponding class name and Groovy Script. The Groovy Script has an original name. Figaf tool also adds the corresponding jar as the IFlow resource.

    • MM with message split support

    • MM with parameters

    • MM with bindings

    • MM with External Message name not equaled to its root element

    • MM with sender and receiver default PI functions

      To support it, Figaf tool replaces usage of sender and receiver functions in Message Mapping by the custom groovy function getHeader that is configured to fetch CPI headers SAP_Sender and SAP_Receiver accordingly by default. It can be reconfigured after migration manually if it needs.

      When migration is done with Local Processes migration profile, special content modifiers are added to set these headers for sender flow and receiver branches.

      In case of Single Process migration profile, content modifiers are not added automatically, but it’s possible to add these content modifiers manually or send headers within the message.

      sender and receiver pi default functions

      Function getHeader is added to the MappingParameters.groovy script. If you have already had shared artifact MappingParameters.groovy, please select Overwrite shared artifact Shared artifacts mode for it before migration.

  • RD without Sender Agreement and Receiver Agreement

  • Scenarios with Technical Context Object

  • Scenarios with RFC

  • ICOs with multiple receivers in the rule

  • ICOs with file sender channel with Flat→XML and/or file receiver channel with XML→Flat content conversion at adapter level

    In the migrated IFlow, new GroovyScript step is added. This script uses the content-converter.jar downloaded from github project developed by the Figaf team. This jar is added to the migrated IFlow automatically.

    If for some reason content-converter.jar can’t be downloaded from the github project, then a jar file from the Figaf tool resources will be used instead and corresponding warning will be shown in the migration logs.

  • ICOs with MessageTransformBean conversion.

    There are two ways to migrate it: using Figaf content converter and Message Transform Bean script provided by SAP.

  • ICOs with Rest polling sender and receiver channels

    Start Timer, Request Reply and the corresponding connection with a Receiver system are added for Rest polling sender channel into the migrated IFlow.

  • ICOs with JDBC channels

    Start Timer, Content Modifier (Query SQL Statement), Request Reply and the corresponding connection with a Receiver system are added for JDBC sender channel into the migrated IFlow.

    Document Name and Update SQL Statement fields aren’t initialized on CPI.