Migrating content with the migration tool

Migration Tooling is a wizard in the Cloud Integration capability. It reads an object from PO, maps it to an integration pattern, and generates an integration flow with its channels, mappings and resources. It is pattern-based: SAP replaced the older set of more than 30 templates with a small number of elastic patterns that add flow steps dynamically. This lesson connects the tenant, runs the wizard, and covers what the wizard leaves for you.

Connect the tenant to PO

A tenant administrator opens Settings > Integrations, the System tab, and chooses Add. Enter a System Name that developers will recognize, the Version, and for the Integration Directory the Cloud Connector Address, the technical User ID (same three PO roles as for the assessment), the password and the Location ID. Untick Same as Integration Directory only if you use a central ES Repository. SAP recommends this System tab; the alternative is a pair of BTP destinations named PO_<systemname>_DIR and PO_<systemname>_ESR, which then appear in the tab automatically.

Run the migration wizard

In Design > Integrations and APIs, create or open an integration package for the migration, choose Edit, then Migrate. Contoso uses one package per wave, such as CMC PO Migration - Procure to Pay for Wave 1.

In the Pattern step the tool preselects the pattern that fits the object. If none fits but the object is migratable, it falls back to the default pattern: a point-to-point design with empty sender and receiver channels, but with the mappings and scripts migrated so you can build around them. SAP lists the supported components as follows.

Patterns and approaches

SAP documents four patterns. Point-to-Point Asynchronous connects one sender and one receiver, decoupled by default through a JMS queue, with variants for a mapping or an idempotent receiver. Point-to-Point Synchronous covers request and response, including separate request and response mappings. Recipient List Asynchronous fits conditions where more than one can be true, so several receivers may get the message. Content-Based Routing fits conditions where only one can be true.

You also choose an approach. The standard approach creates one integration flow per scenario and suits a modest number of interfaces. The pipeline approach mirrors PO's own processing pipeline with generic, prepackaged flows and Partner Directory entries, built for migrating many scenarios.

Mappings and value mappings

With Enable Reusable Artifacts on (the default), message mappings come across as global message mapping artifacts that other flows can reuse; off, they become local resources of the one flow. The Import Method switches to Reuse when a matching artifact exists, matched on name, namespace and software component version. Function libraries and imported archives are always global. Import Only Supported Message Mappings skips mappings Integration Suite can't run; without it, unsupported ones arrive partially.

Value mappings are not migrated by the wizard. Import them as standalone artifacts: in the package choose Add > Value Mapping, then Import from Integration Directory, connect, and pick up to ten per import (PO 7.5 SP22 or later), then assign them in the message mappings that use them. For one-off pieces, the integration flow's References tab imports message mappings, operation mappings, value mappings, schemas and WSDLs from the ES Repository; an operation mapping import fails if it contains XSLT references or asynchronous interfaces.

After you choose Migrate

• Read the Migration Success page and download the PDF with Report: Channels and Resources, Artifact Details and Next Steps.
• Set the externalized adapter parameters with Configure; create RFC destinations and JDBC data sources the flow needs.
• Deploy security material first: credential names and key aliases must exist under the same names.
• Fix the schedule: a source scheduler expression is reset to run every 60 seconds.
• Simulate the flow, deploy it in development, and hand it to the regression tests in lesson 5.