Get started

1. Channel Mapping Templates configuration

Since of 2309 Figaf Tool supports channel mapping templates management. So PItoCPIMigrationTemplates repository is deprecated.

To configure template:

  1. Go to PI to CPI migration → Channel Mapping Templates page.

  2. Click on plus to create new template.

    You can copy existing template clicking on copy full of related template.

    It will open the dialog:

    channel mapping template dialog

    1. Fill Name

    2. Select PI Channel (or Direction and Adapter Type). Once you select PI Channel, PI Channel XML value will be set. Then you can Run template to check configuration.

    3. Select Enable Cloud Connector value. Supported values are Not Available, Available, Available by default.

    4. Select CPI IFlow and Message Flow Step Id. Click on Generate template, then XSLT Template will be generated.

    5. Save the template.

  3. To modify or delete custom template click on details full or red trash.

    Only custom templates can be modified or deleted. Default templates can be browsed only.

2. Configuration

To migrate objects from PI to CPI you have to configure agents for the usage:

  1. Go to PI to CPI migration → Configuration page:

    configuration

  2. Configure PI Agents used for source objects (required)

  3. Configure CPI Development Agents used for migrated objects (required)

  4. Configure CPI Production Agents

  5. Configure Location ID that will be applied to all Cloud Connector-enabled channel mapping templates.

  6. Configure Parameter Value Replacement table to replace externalized properties in the generated IFlows.

    Empty value of the cell means that the replacement rule will not be applied.

    JMS Queue Name can be replaced as well.

  7. Configure Modules Replacement table to replace custom or EDI modules with the corresponding groovy script belong to a Script Collection. By default, Script Function Name is processData, but it can be overridden.

    If a module name in the model has a localejbs/ prefix, this prefix will be omitted (so it’s considered as equal with the module name without this prefix).

    If a module has parameters, a separate Content Modifier in the IFlow before a groovy script will be created. If it has a password parameter, it will be set to empty value.

    In case of an asynchronous ICO, modules before sender and before receiver will be replaced.

    In case of a synchronous ICO, modules before sender, before receiver, after receiver, after sender will be replaced.

    The groovy scripts used to replace modules during migration are taken from the Figaf-provided FigafMigration script collection by default. You can point the migration to a custom script collection (for example, to apply updated migration scripts faster) via the irt.config.pi-to-cpi-migration-script-collection-technical-name application property.

  8. Configure B2B Migration Settings:

    1. Enable B2B Migration to migrate Operation Mappings to B2B Scenarios.

    2. Deploy MainFlow immediately after migration to automatically deploy IFlow after migration.

    3. Activate TPM Agreement immediately after migration to automatically activate agreement after migration.

    4. Configure SWCs for B2B migration which will be shown on Overview page.

      If the SWCs aren’t configured, all Operation Mappings will be shown on Overview page.

3. Delete migration records

Since 2606, on the Overview page you can permanently remove migration records that you no longer need. Select one or more records using the checkboxes in the overview table and click the delete button:

  • Delete Links (A2A objects) - removes the link between the PI object and the CPI IFlow. The ICO reappears as a not-migrated row, so you can re-link or migrate it again.

  • Delete Records (B2B objects) - removes the B2B migration record from Figaf Tool. To make it migrated again, re-run the migration.

A confirmation dialog shows how many records will be deleted. In both cases nothing is deleted in SAP - only the Figaf Tool migration record or link is removed.

The delete function is available only for users with the administrator (IRTAdmin) role.

4. E2e migration of PI Integration object (from Overview page)

To migrate PI Integration object from Overview page:

  1. Go to Overview page:

    overview

  2. Click on details button of PI object that you are going to migrate. You’ll be migrated to Migration page with predefined data:

    migration with predefined data

  3. Select CPI Agent

  4. Select CPI Package

  5. Type Name prefix for Inbound IFlow if profile is Pipeline All or target IFlow Name (Display name) for other profiles.

  6. Type ID prefix for Inbound IFlow if profile is Pipeline All or target IFlow ID (Technical name) for other profiles.

  7. Select Profile Type. The value could be:

    1. Single Process - migrated IFlow has one Integration Process. Neither subprocess nor exception handling isn’t supported by default.

    2. Local Processes - migrated IFlow is enterprise ready: local Integration Process is created for each receiver/interface, subprocess is created for every branch, exception handling is supported.

      It’s required to deploy script collection for error handling (see script content for error handling).

      If Local Processes profile is selected, select Retry Type. The value could be None or JMS: None - migrated IFlow doesn’t include retry process; JMS - migrated IFlow includes retry process. If JMS type is selected, JMS Queue Name can be configured.

    1. Pipeline All migrates to Inbound Processing, Inbound Conversion and Outbound IFlows, generates and uploads Receiver and Interface Determinations XSLTs and InboundConversionEndpoint string parameter to Partner Directory.

      There are some details about Pipeline All migration profile:

      • It’s possible to Regenerate Names for all IFlows after change of values used for displayed and technical names (e.g. Name prefix, ID prefix, Sender, etc.).

      • It supports Point-to-Point scenario (P2P Scenario for XSLT Mode) for scenarios with only one sender and one receiver interface. Enable it if you want to improve runtime behavior bypassing the two pipeline steps receiver determination and interface determination.

      • It supports pipeline concept 1.0.8 (Single XSLT for XSLT Mode) so it improves runtime behavior bypassing the pipeline step interface determination.

      • It supports pipeline concept 1.0.9 (PIPX01 for Inbound processing queue name if XSLT Mode is Single XSLT) so it improves runtime behavior.

      • It supports pipeline concept 1.0.11 (alternative partner usage).

      • It doesn’t support sync scenarios.

      • Local Receiver Rules and Extended Receiver are supported in scope of Receiver Determination XSLT generation.

      • If ICO has neither CSV to XML conversion nor custom modules replacement, Inbound Conversion IFlow will not be generated and InboundConversionEndpoint string parameter will not be uploaded to Partner Directory.

      • Outbound IFlows use a process-direct sender default template for a sender adapter.

    2. Pipeline Inbound Processing - migrated IFlow is Inbound Processing IFlow and has sender message flow, a couple of headers modifiers, and idempotent call.

    3. Pipeline Inbound Conversion - migrated IFlow is Inbound Conversion IFlow and has CSV to XML conversion and custom modules replacement steps.

    4. Pipeline Outbound - migrated IFlow is Outbound IFlow and has headers modifiers, mappings process, modules replacement converter, unique ID content modifier, and idempotent call. If a message mapping has splitter and/or filter elements, they will be placed in the main process.

      There are some details about Pipeline Outbound migration profile:

      • It doesn’t support sync scenarios.

      • If a source ICO has multiple mappings, only one of them can be used. All others will be excluded. By default, only the first mapping will be included. You can see it at the Receivers/Interfaces table.

      • It uses a process-direct sender default template for a sender adapter.

  8. Runtime Profile for the migrated IFlow(s).

  9. Click on Check in order to build target IFlow model

  10. Once the operation is completed, you are allowed to configure migration settings and check migration logs:

    configure xslt mapping file paths for channels and check migration logs

    1. Only Pipeline All profile Sender value is used for a Sender component name of the Inbound IFlow.

    2. Only Pipeline All profile Sender, Interface and Partner Id values are taken from the ICO sender part and used for Inbound IFlow displayed and technical names, in the Inbound IFlow headers.

    3. Only ICOs with a wildcard (*) sender Sender Agreement selects the linked Sender Agreement whose sender channel is migrated. The first agreement is preselected; to migrate the channel of another agreement, select it and run Check again. The field is shown for the Single Process, Local Processes, Pipeline Inbound Processing and Pipeline Inbound Conversion profiles (see Wildcard sender).

    4. Only Pipeline All profile XSLT Mode defines mode for generated XSLT files:

      1. P2P Scenario improves runtime behavior bypassing the two pipeline steps receiver determination and interface determination. It’s supported for scenarios with only one sender and one receiver interface.

      2. Single XSLT generates one XSLT with all interfaces and receivers in it. It improves runtime behavior bypassing the pipeline step interface determination.

        If XSLT mode is Single XSLT, Inbound processing queue name can be configured either PIPX01 (default) or PIPQ01.

      3. Multiple XSLTs generates separate XSLT for interfaces and each receiver. It is legacy behaviour. It passes through the pipeline steps receiver determination and interface determination.

    5. File Content Conversion Mode defines a way to handle content conversion, visible if there is at least one channel with File Content Conversion. Available options are:

      1. Figaf Converter adds a Groovy script step with the Figaf content converter to the migrated IFlow (see File Content Conversion migration).

      2. Message Transform Bean uses new community package (see article).

    6. Try to deploy after migration enables automatic deploy of migrated IFlow(s).

    7. Channels Mapping configures xslt mapping file paths for channels. If corresponding template isn’t found, then HTTP is used for sender and ProcessDirect is used for receiver.

    8. Receivers/Interfaces configures which receivers/interfaces should be migrated from PI Integration Object.

      For Pipeline All profile there are more configurations:

      1. Service value(s) is(are) configurable and used in the part of the Outbound IFlow name. The value is used for XSLT generation of Interface and Receiver Determinations.

      2. Displayed name, Technical name and URL of Outbound IFlows are configurable in related dialog shown by click on edit button.

      3. For an ICO with a wildcard (*) sender, the Inbound IFlows table lists one Inbound Processing IFlow per linked Sender Agreement with its Sender (see Pipeline All profile).

    9. Cloud Integration Resources manages shared artifacts modes:

      1. Reuse shared artifact - existing shared artifact will be used during migration

      2. Overwrite shared artifact - existing shared artifact will be overwritten using current state of related PI object

      3. Create as local object - existing shared artifact will not be used during migration.

        If source object is Message Mapping with defined functions, checkbox Extract UDFs into a separate script will be shown. If the checkbox is enabled, local functions from a message mapping will be extracted into a separate groovy script. If the checkbox is disabled, functions will not be extracted.

        Please use Overwrite shared artifact or Create as local object mode, when you change Extract UDFs into a separate script value.

      4. Use migrated CPI function library (only for Script resource type) - existing CPI function library will be used during migration. So migrated IFlow will be linked with the CPI function library. If related CPI function library doesn’t exist on CPI system, then Function Library conversion algorithm will be used.

      5. Use custom CPI script (only for ARCHIVE_PROGRAM) - existing CPI script from Script Collection should be selected.

      6. Map functions individually (only for Script resource type) - individual configuration for each function in the function library. Either existing CPI function library or Figaf groovy script can be used.

        Particular PI Function will be found in the CPI Function Library automatically. It is matched by the key.

    10. Migration logs shows migration warnings and advices.

  11. Once everything is configured, migrate the object clicking on Migrate.

    Example of migrated IFlow (Single Process profile):

    migrated iflow example

    Example of migrated IFlow (Local Processes profile):

    migrated iflow example beta

  12. Configure the IFlow

  13. Deploy it if you want to run test cases

  14. Once PI object is migrated, there is the information with migrated IFlow on Overview page:

    overview after migration

  15. Then you can migrate PI object test case clicking on the row and then clicking on Migrate Test cases button. You will be navigated to Agent Test Cases tab on Integration Object Details page. Then Follow Migrate test cases from PI to CPI feature.

If some issue occurs during checking the state, please download archive for debugging and send it to us by email [email protected].

5. E2e migration of PI Integration object (from Migration page)

To migrate PI Integration object from Migration page:

  1. Go to Migration page.

  2. Select PI Integration Object.

    Selected object should be licensed for Migration (see Configure Object Licenses for details).

  3. Select CPI Agent

  4. Select CPI Package

  5. Type Name prefix for Inbound IFlow if profile is Pipeline All or target IFlow Name (Display name) for other profiles.

  6. Type ID prefix for Inbound IFlow if profile is Pipeline All or target IFlow ID (Technical name) for other profiles.

  7. Select Profile Type. The value could be:

    1. Single Process - migrated IFlow has one Integration Process. Neither subprocess nor exception handling isn’t supported by default.

    2. Local Processes - migrated IFlow is enterprise ready: local Integration Process is created for each receiver/interface, subprocess is created for every branch, exception handling is supported.

      It’s required to deploy script collection for error handling (see script content for error handling).

      If Local Processes profile is selected, select Retry Type. The value could be None or JMS: None - migrated IFlow doesn’t include retry process; JMS - migrated IFlow includes retry process. If JMS type is selected, JMS Queue Name can be configured.

    1. Pipeline All migrates to Inbound Processing, Inbound Conversion and Outbound IFlows, generates and uploads Receiver and Interface Determinations XSLTs and InboundConversionEndpoint string parameter to Partner Directory.

      There are some details about Pipeline All migration profile:

      • It’s possible to Regenerate Names for all IFlows after change of values used for displayed and technical names (e.g. Name prefix, ID prefix, Sender, etc.).

      • It supports Point-to-Point scenario (P2P Scenario for XSLT Mode) for scenarios with only one sender and one receiver interface. Enable it if you want to improve runtime behavior bypassing the two pipeline steps receiver determination and interface determination.

      • It supports pipeline concept 1.0.8 (Single XSLT for XSLT Mode) so it improves runtime behavior bypassing the pipeline step interface determination.

      • It supports pipeline concept 1.0.9 (PIPX01 for Inbound processing queue name if XSLT Mode is Single XSLT) so it improves runtime behavior.

      • It supports pipeline concept 1.0.11 (alternative partner usage).

      • It doesn’t support sync scenarios.

      • Local Receiver Rules and Extended Receiver are supported in scope of Receiver Determination XSLT generation.

      • If ICO has neither CSV to XML conversion nor custom modules replacement, Inbound Conversion IFlow will not be generated and InboundConversionEndpoint string parameter will not be uploaded to Partner Directory.

      • Outbound IFlows use a process-direct sender default template for a sender adapter.

    2. Pipeline Inbound Processing - migrated IFlow is Inbound Processing IFlow and has sender message flow, a couple of headers modifiers, and idempotent call.

    3. Pipeline Inbound Conversion - migrated IFlow is Inbound Conversion IFlow and has CSV to XML conversion and custom modules replacement steps.

    4. Pipeline Outbound - migrated IFlow is Outbound IFlow and has headers modifiers, mappings process, modules replacement converter, unique ID content modifier, and idempotent call. If a message mapping has splitter and/or filter elements, they will be placed in the main process.

      There are some details about Pipeline Outbound migration profile:

      • It doesn’t support sync scenarios.

      • If a source ICO has multiple mappings, only one of them can be used. All others will be excluded. By default, only the first mapping will be included. You can see it at the Receivers/Interfaces table.

      • It uses a process-direct sender default template for a sender adapter.

  8. Runtime Profile for the migrated IFlow(s).

  9. Click on Check in order to build target IFlow model.

  10. Once the operation is completed, you are allowed to configure migration settings and check migration logs:

    configure xslt mapping file paths for channels and check migration logs

    1. Only Pipeline All profile Sender value is used for a Sender component name of the Inbound IFlow.

    2. Only Pipeline All profile Sender, Interface and Partner Id values are taken from the ICO sender part and used for Inbound IFlow displayed and technical names, in the Inbound IFlow headers.

    3. Only ICOs with a wildcard (*) sender Sender Agreement selects the linked Sender Agreement whose sender channel is migrated. The first agreement is preselected; to migrate the channel of another agreement, select it and run Check again. The field is shown for the Single Process, Local Processes, Pipeline Inbound Processing and Pipeline Inbound Conversion profiles (see Wildcard sender).

    4. Only Pipeline All profile XSLT Mode defines mode for generated XSLT files:

      1. P2P Scenario improves runtime behavior bypassing the two pipeline steps receiver determination and interface determination. It’s supported for scenarios with only one sender and one receiver interface.

      2. Single XSLT generates one XSLT with all interfaces and receivers in it. It improves runtime behavior bypassing the pipeline step interface determination.

        If XSLT mode is Single XSLT, Inbound processing queue name can be configured either PIPX01 (default) or PIPQ01.

      3. Multiple XSLTs generates separate XSLT for interfaces and each receiver. It is legacy behaviour. It passes through the pipeline steps receiver determination and interface determination.

    5. File Content Conversion Mode defines a way to handle content conversion, visible if there is at least one channel with File Content Conversion. Available options are:

      1. Figaf Converter adds a Groovy script step with the Figaf content converter to the migrated IFlow (see File Content Conversion migration).

      2. Message Transform Bean uses new community package (see article).

    6. Try to deploy after migration enables automatic deploy of migrated IFlow(s).

    7. Channels Mapping configures xslt mapping file paths for channels. If corresponding template isn’t found, then HTTP is used for sender and ProcessDirect is used for receiver.

    8. Receivers/Interfaces configures which receivers/interfaces should be migrated from PI Integration Object.

      For Pipeline All profile there are more configurations:

      1. Service value(s) is(are) configurable and used in the part of the Outbound IFlow name. The value is used for XSLT generation of Interface and Receiver Determinations.

      2. Displayed name, Technical name and URL of Outbound IFlows are configurable in related dialog shown by click on edit button.

      3. For an ICO with a wildcard (*) sender, the Inbound IFlows table lists one Inbound Processing IFlow per linked Sender Agreement with its Sender (see Pipeline All profile).

    9. Cloud Integration Resources manages shared artifacts modes:

      1. Reuse shared artifact - existing shared artifact will be used during migration

      2. Overwrite shared artifact - existing shared artifact will be overwritten using current state of related PI object

      3. Create as local object - existing shared artifact will not be used during migration.

        If source object is Message Mapping with defined functions, checkbox Extract UDFs into a separate script will be shown. If the checkbox is enabled, local functions from a message mapping will be extracted into a separate groovy script. If the checkbox is disabled, functions will not be extracted.

        Please use Overwrite shared artifact or Create as local object mode, when you change Extract UDFs into a separate script value.

      4. Use migrated CPI function library (only for Script resource type) - existing CPI function library will be used during migration. So migrated IFlow will be linked with the CPI function library. If related CPI function library doesn’t exist on CPI system, then Function Library conversion algorithm will be used.

      5. Use custom CPI script (only for ARCHIVE_PROGRAM) - existing CPI script from Script Collection should be selected.

      6. Map functions individually (only for Script resource type) - individual configuration for each function in the function library. Either existing CPI function library or Figaf groovy script can be used.

        Particular PI Function will be found in the CPI Function Library automatically. It is matched by the key.

    10. Migration logs shows migration warnings and advices.

  11. Once everything is configured, migrate the object clicking on Migrate.

    Example of migrated IFlow (Single Process profile):

    migrated iflow example

    Example of migrated IFlow (Local Processes profile):

    migrated iflow example beta

  12. Configure the IFlow.

  13. Deploy it if you want to run test cases.

  14. Once PI object is migrated, there is the information with migrated IFlow on Overview page:

    overview after migration

  15. Then you can migrate PI object test case clicking on the row and then clicking on Migrate Test cases button. You will be navigated to Agent Test Cases tab on Integration Object Details page. Then Follow Migrate test cases from PI to CPI feature.

If some issue occurs during checking the state, please download archive for debugging and send it to us by email [email protected].

6. E2e migration of Operation mapping to existent IFlow

To migrate Operation mapping from Migration page:

  1. Go to Migration page.

  2. Switch Operation Mapping.

  3. Select Operation Mapping.

    Selected object should be licensed for Migration (see Configure Object Licenses for details).

  4. Select CPI IFlow.

  5. Configure Embed into IFlow as a local process. If it’s enabled, Operation Mapping is added as a new local process in the bottom of the existing IFlow. If it’s a synchronous Operation Mapping, two local processes are added: for the Request part and for the Response part.

  6. Click on Check in order to build target IFlow model.

  7. Migrate the object clicking on Migrate. As a result objects linked with Operation mapping are migrated to the IFlow.

If some issue occurs during checking the state, please download archive for debugging and send it to us by email [email protected].

7. E2e migration of Operation mapping to B2B Scenario (from Overview page)

Requirements:

Enable B2B Migration on Configuration page.

To migrate Operation mapping from Overview page:

  1. Go to Overview page.

  2. Enable B2B switch.

  3. Click on details button of PI object that you are going to migrate. You’ll be migrated to Migration page with predefined data.

  4. Configure Company/Subsidiary, Partner Profile, Communication Partner (optional), Agreement Template, B2B Scenario, My Company Details and Trading Partner Details.

    If Communication Partner is selected, Agreement Template list is filtered accordingly.

    Repeat migration of several operation mappings or one operation mapping with the same Company/Subsidiary, Partner Profile and Agreement Template configuration isn’t supported if B2B Scenario is changed.

  5. Click on Check in order to build target IFlow model and TPM objects.

  6. Migrate the object clicking on Migrate. As a result IFlow, Agreement and B2B Scenario are created.

If some issue occurs during checking the state, please download archive for debugging and send it to us by email [email protected].

8. E2e migration of Operation mapping to B2B Scenario

Requirements:

Enable B2B Migration on Configuration page.

To migrate Operation mapping from Migration page:

  1. Go to Migration page.

  2. Switch B2B.

  3. Select Operation Mapping.

    Selected object should be licensed for Migration (see Configure Object Licenses for details).

  4. Select CPI Agent.

  5. Configure Company/Subsidiary, Partner Profile, Communication Partner (optional), Agreement Template, B2B Scenario, My Company Details and Trading Partner Details.

    If Communication Partner is selected, Agreement Template list is filtered accordingly.

    Repeat migration of several operation mappings or one operation mapping with the same Company/Subsidiary, Partner Profile and Agreement Template configuration isn’t supported if B2B Scenario is changed.

  6. Click on Check in order to build target IFlow model and TPM objects.

  7. Migrate the object clicking on Migrate. As a result IFlow, Agreement and B2B Scenario are created.

If some issue occurs during checking the state, please download archive for debugging and send it to us by email [email protected].

9. E2e migration of Operation mapping. Generic mapping usage

Requirements:

Enable B2B Migration on Configuration page.

To migrate Operation mapping from Migration page:

  1. Go to Migration page.

  2. Switch B2B.

  3. Select Operation Mapping.

    Selected object should be licensed for Migration (see Configure Object Licenses for details).

  4. Select CPI Agent.

  5. Enable Create generic mapping.

  6. Configure Generic postfix, Company/Subsidiary, Agreement Template.

  7. Click on Check in order to build target IFlow model and TPM objects.

  8. Migrate the object clicking on Migrate. As a result generic IFlow is created.

  9. When you migrate the same Operation Mapping again, enable Use generic mapping to use this generic IFlow and create Agreement and B2B Scenario during migration or don’t enable Use generic mapping if you need to create IFlow, Agreement and B2B Scenario.

If some issue occurs during checking the state, please download archive for debugging and send it to us by email [email protected].