20. Migrate SAP PO Customer Mapping to CPI with SKYVVA V4/integrate

Overview

Migrate an existing ERP → SAP PI/PO → Salesforce customer interface to SAP Cloud Integration (CPI). Reuse its supported PO Message Mapping, keep the agreed SKYVVA V2 XML output, and configure SkyvvaSalesforce → Skyvva → V2 → V4/integrate. For the asynchronous business execution used here, also verify the V2 interface's Inbound Processing Behavior as described in section 2.

Keep the Message Mapping step because ERP continues sending its original customer structure. Reuse the existing business rules so Salesforce receives the same customer information after migration.

This guide uses fictional customer data to illustrate a migration procedure. Bring the existing PO mapping, its schemas and dependencies, and a working sandbox copy of the Salesforce configuration. Use the sample requests only when they match that mapping's contract.

Context Before You Start

Example Manufacturing maintains customer master data in ERP. Its existing PO mapping translates KUNNR, NAME1, ORT01, and TELF1 into Salesforce Account fields. A standard SKYVVA V2 interface applies Upsert using the ERP customer number. Sales representatives rely on these Accounts for quotations and customer visits.

The ERP application and Salesforce matching rules stay the same. The middleware route and mapping runtime move from PO to CPI.

Current:
ERP source XML → PO Message Mapping → Legacy V2 Account XML
               → SKYVVA PO adapter → Salesforce

Target:
ERP source XML → Imported PO Message Mapping in CPI → Legacy V2 Account XML
               → SkyvvaSalesforce V2 / V4/integrate
               → Existing SKYVVA interface → Salesforce Accounts

This baseline covers normal V2 integrate processing. If the PO channel uses batch/bulk flags, automatic switching, ordered delivery, or other receiver-module behavior, evaluate those separately before selecting V4/integrate. Reusing the mapping alone does not migrate those capabilities or PO delivery and ordering guarantees.

The XML is a fictional project-specific customer export, not a standard IDoc. If the existing source uses IDoc, XI, SOAP, or SFTP, migrate that actual sender contract and transport rather than relabeling this HTTPS exercise. An IDoc sender uses its own adapter/protocol configuration; a PO tRFC destination is not interchangeable with a CPI HTTPS endpoint.

Terms Used in This Guide

The additional mapping-dependency terms are explained in section 4.1. The PO/CPI developer performs those checks; the business owner confirms that customer data and processing outcomes remain correct.

1. Capture the Working PO Interface

In the PO Integration Directory, locate the customer integration's ICO or equivalent configuration. Identify its sender channel, interface/operation, assigned Operation Mapping, and receiver channel/module chain. In ESR, open the Operation Mapping and identify the Message Mapping programs it executes, in order.

Before importing or building the CPI flow, confirm access to the PO design, a Salesforce sandbox, and a CPI tenant with the required mapping features. Have the administrators verify a compatible adapter/package combination and the necessary permissions. Record each environment's versions; section 11 repeats these checks for production.

Collect this evidence before changing the design:

Retain the original PO design using its approved transport/export procedure. Do not assume the resulting PO archive can be uploaded as a CPI mapping ZIP.

In a PO receiver module configuration, interface routing can come from targetObject, while the integration can come from channel/module settings. The CPI V2-through-V4 bridge reads both fromSystem and targetObject from its input XML. Compare the actual payload and module settings. If the old mapping omitted a routing value, add the agreed value through an explicit mapping/envelope adjustment and test it; do not assume an unchanged PO mapping always supplies the complete CPI contract.

Migration Assessment does not inspect the internal code or detailed settings of custom adapters/modules. Review those responsibilities separately.

Figure 1. Existing PO customer interface and assigned mapping sequence.

2. Verify the Existing Salesforce Configuration

Retain the proven interface and matching behavior. Perform these checks in a sandbox copy before production. The field and interface names below belong to the fictional migration baseline; substitute the actual existing values consistently.

2.1 Verify the Account Matching Key

In Salesforce → gear icon → Setup → Object Manager → Account → Fields & Relationships, verify the existing field or create it in the training sandbox:

Keep the ERP number as text to preserve leading zeros. Account Name is descriptive data; it is not the matching key.

Give the integration user API access, Account read/create/update permissions, and access to these fields. Check required fields, record types, duplicate rules, and validation rules in the sandbox.

Choose one sandbox starting state: leave both sample ERP numbers unused to demonstrate two inserts, or seed only the first Account to demonstrate one update and one insert:

Record its Salesforce ID. Leave 0000100452 unused. Existing production Accounts without ERP IDs must be reconciled before cutover, otherwise the first Upsert can create additional Accounts.

Figure 2. ERP customer number configured as the Account matching key.

2.2 Verify the Existing V2 Interface

In Salesforce → App Launcher → SKYVVA, open the Integration and Interface used by the working PO flow. For the fictional training scenario, these are ERP_Customer_Migration and Account_ERP_V2_In. Review their saved settings. Create equivalent sandbox records only if you are preparing a separate training environment.

Verify that the sandbox baseline matches the following configuration. Treat a difference in the existing production interface as a migration decision to review, rather than changing it automatically:

When creating an equivalent interface in v2.51, selecting V2 disables the Message Type lookup. This exercise does not require creating a V3 message type or repository.

In the interface's Inbound Setup, verify External Mapping is enabled for this baseline. When creating the sandbox equivalent, enable it. If the creation screen requires Connect with Middleware to expose that option, enable it for that setup, then save the interface. That checkbox is not the CPI connection or authentication configuration.

Verify that the interface's Salesforce External ID contains ERP_Customer_ID__c for this baseline. Set it when creating the sandbox equivalent. This selection tells the standard external-mapping processing which field identifies an existing Account; merely creating the field on Account is insufficient.

For this asynchronous example, verify Inbound Processing Behavior = Asynchronous as well as the selected operation. Preserve the existing production behavior unless a change has been agreed. Confirm completion in SKYVVA monitoring and the Account records rather than relying only on the sender response.

The XML already uses Salesforce API field names. With External Mapping enabled, standard SKYVVA processing can derive mappings from these names:

The training baseline uses Mapping in Salesforce = disabled if that option is exposed. Preserve the existing production setting during migration; interfaces with hybrid transformations need their own mapping review.

External Mapping means that the business field mapping is performed outside Salesforce. It can be performed by the migrated Message Mapping in CPI. The checkbox does not mean that raw ERP data can bypass the required transformation.

Figure 3. Existing V2 Account interface and customer matching settings.

3. Compare the Source and Target Contracts

3.1 ERP Request Before Mapping

Use erp-customers-source.xml for the fictional contract below. For an actual customer mapping with a different schema, use a sanitized original ERP request conforming to that mapping's source definition; do not change the customer's source contract just to accept this sample.

<?xml version="1.0" encoding="UTF-8"?>
<Customers>
    <Customer>
        <KUNNR>0000100451</KUNNR>
        <NAME1>Northstar Parts Training</NAME1>
        <ORT01>North Training City</ORT01>
        <TELF1>+1-202-555-0101</TELF1>
    </Customer>
    <Customer>
        <KUNNR>0000100452</KUNNR>
        <NAME1>Riverside Service Training</NAME1>
        <ORT01>River Training City</ORT01>
        <TELF1>+1-202-555-0102</TELF1>
    </Customer>
</Customers>

3.2 Expected Output of the Migrated Mapping

Compare the mapping simulation with expected-v2-accounts.xml:

<?xml version="1.0" encoding="UTF-8"?>
<ns1:ISTRUCTURE_Account
    xmlns:ns1="http://soap.sforce.com/schemas/class/skyvvasolutions/IServices">
    <fromSystem>ERP_Customer_Migration</fromSystem>
    <targetObject>Account_ERP_V2_In</targetObject>
    <ListOfAccounts>
        <Account>
            <ERP_Customer_ID__c>0000100451</ERP_Customer_ID__c>
            <Name>Northstar Parts Training</Name>
            <Phone>+1-202-555-0101</Phone>
            <BillingCity>North Training City</BillingCity>
        </Account>
        <Account>
            <ERP_Customer_ID__c>0000100452</ERP_Customer_ID__c>
            <Name>Riverside Service Training</Name>
            <Phone>+1-202-555-0102</Phone>
            <BillingCity>River Training City</BillingCity>
        </Account>
    </ListOfAccounts>
</ns1:ISTRUCTURE_Account>

The target paths are relative to ISTRUCTURE_Account. The mapping also supplies one root-level fromSystem and targetObject using the agreed integration/interface values. Repeat Account in the Customer context; do not place both customers' fields into one record.

Use the actual ESR source/target definitions for migration. These sample files describe the fictional contract; they do not replace those definitions or prove that an imported mapping executes correctly.

4. Prepare and Migrate the PO Mapping

Use the customer's existing supported Message Mapping. The example name MM_ERP_Customers_To_SKYVVA_V2 represents the existing customer mapping. Select its actual name and version in your landscape.

4.1 Review Mapping Dependencies

Before importing, ask the PO developer to review the existing mapping and record which of these features it actually uses. After import, repeat the check against the imported resources. A simple field-to-field mapping may not use any of them.

Record each item as Not used, Ready, or Adjustment required, with an owner for any adjustment. Review support for the actual functions in the target tenant; do not assume every UDF or parameter needs rewriting.

If the Operation Mapping executes several transformations, preserve their order and intermediate results. Importing one Message Mapping does not import the rest of the processing sequence or channel modules.

Keep the source/target definitions and required dependencies with the mapping. If a feature needs redesign, compare the resulting business values with the working PO output before accepting the change.

4.2 Choose the Mapping Migration Approach

Choose the route matching the available artifacts after the dependency review. Every route must preserve the source and target contracts and pass the comparison below.

Upload an already prepared CPI mapping

In the package, choose Add → Message Mapping → Upload, select the CPI-compatible mapping artifact ZIP, then inspect, save, and deploy it. Add the global reference and assign the mapping step as described in section 5.

This option requires a mapping already prepared for CPI. Renaming a PO .tpz file to .zip does not convert its contents into a CPI mapping artifact.

Reimplement an unsupported mapping

Obtain the original schemas, mapping expressions, constants, UDF behavior, lookup rules, value mappings, and representative PO input/output pairs. Create a CPI Message Mapping artifact with the agreed schemas and reproduce those rules using supported components. Deploy it and assign it in section 5.

For this document's simple customer contract, reproduce the four field assignments and the two envelope routing values in section 3. Preserve the repeating Customer context. A customer's actual mapping may contain additional conditions and dependencies; the sample assignments are not a substitute for inspecting them.

Validate normal records, missing/empty values, repeated records, identifiers with leading zeros, and any lookups or conditional rules against PO results. Obtain business acceptance before cutover. Record that this route reimplements the transformation rather than importing the original mapping.

If you upload or reimplement the mapping, skip section 4.3 and continue with the comparison in section 4.4. If you use direct ESR import, complete section 4.3 first.

The receiver remains Skyvva → V2 → V4/integrate for all approaches above. Only the way the business mapping is brought into CPI changes.

4.3 Import from ESR

Before importing, ask the BTP/PO administrator to confirm the following setup. Use your landscape's actual hosts, destinations, and access permissions.

This is a design-time connection for importing mapping content. The ERP sender uses a separate runtime connection to CPI. If the repository is unavailable, use the appropriate option in section 4.2 instead of repeatedly retrying the import.

Open the CPI integration package and choose Add → Message Mapping → ES Repository. Connect, select the existing mapping, review dependent resources, and complete the import. Inspect, save, and deploy the mapping artifact before referencing it in the iFlow. The imported artifact has its own CPI ID; record that ID for section 5.

SAP Migration Tooling is another option for supported whole-scenario migrations. It can assist with integration-object migration, but custom receiver behavior still requires the checks in section 1.

Figure 4. Selection of the existing PO mapping and its dependencies for the ESR import path.

4.4 Compare Mapping Results

Run the same sanitized source request through PO and the imported CPI mapping. Compare field values, namespaces, record contexts, routing elements, empty values, and output counts. XML prefix spelling or formatting alone is not the comparison target.

For the worked scenario, two source Customers must produce two Accounts with each customer's name, city, and phone kept together. Preserve leading zeros in the customer number.

Figure 5. Comparison of ERP customer input and migrated mapping output.

5. Build the CPI Integration Flow

In SAP Integration Suite → Design, open your training package and create ERP Customers - V2 XML via V4. Open the iFlow in Edit mode.

Use a sender participant ERP, a receiver participant Salesforce, and these process steps:

flowchart LR
    ERP[ERP or Postman] --> H[HTTPS Sender]
    H --> S[Receive ERP Customers]
    S --> M[Map ERP Customers to V2 Accounts]
    M --> R[Send Customers to SKYVVA]
    R --> E[End Submission]
    R -->|SkyvvaSalesforce| SF[SKYVVA V2 Account Interface]
    SF -->|Submission response| R

Figure 6. Customer migration flow with Message Mapping before the SKYVVA receiver.

Connect Start → Message Mapping → Request Reply → End. Connect Request Reply to the Salesforce receiver using SkyvvaSalesforce.

Add Message Mapping between Start and Request Reply. Reference the mapping artifact selected and deployed in section 4:

1. Select the iFlow's empty canvas and open References → Global → Add References → Message Mapping.
2. Select the deployed artifact chosen in section 4 and confirm.
3. On the Message Mapping step, use Assign, select Global Resources, and choose that referenced artifact.

Designer labels may vary. Importing, uploading, or creating a package artifact does not automatically add or assign it to the iFlow.

Figure 7. Selected mapping referenced by the iFlow and assigned to its Message Mapping step.

Send the original ERP XML into this flow. Use the mapped legacy XML as the receiver input. Preserve any required validation or normalization from the original PO sequence.

5.1 Configure the HTTPS sender

Use an authorized technical caller. Disabling CSRF protection is a choice for this controlled exercise, not the SAP default or a general production recommendation. If your environment requires CSRF protection, retain it and use the tenant's token-fetch procedure. Have the administrator confirm the caller's assigned role and authentication before testing.

5.2 Configure the receiver connection

Use your approved Salesforce authentication configuration. For the Client Credential option used in the existing receiver tutorials:

In Monitor → Manage Security → Security Material, deploy this alias as User Credentials, with User = Salesforce OAuth client ID and Password = OAuth client secret. Configure the Salesforce OAuth application's Client Credentials flow and run-as integration user. Confirm the applicable SKYVVA inbound license is valid in the target organization and the user has the required package permissions; this route invokes SKYVVA processing, not the adapter's direct Salesforce option.

The CPI inbound caller's authentication is separate from this Salesforce receiver authentication. See the receiver adapter guide for the broader setup.

5.3 Configure receiver processing

Open the receiver's Processing tab; older screens may call it Skyvva.

The integration and interface come from the mapped XML routing elements. Keep their values aligned with the existing Salesforce configuration in section 2.

This uses SKYVVA's standard interface processing. The adapter's separate Processing Type = Salesforce path does not execute this SKYVVA interface.

If the V4 operation choices are missing, verify the installed adapter and the receiver configuration version. Use a supported build with the required capability and follow that release's upgrade instructions. SKYVVA V2, the V4 endpoint, and the Salesforce platform API version are distinct settings.

Figure 8. Receiver settings for V2 customer processing with V4/integrate.

5.4 Agree the Sender Response and Recovery Contract

This flow responds after the request has been mapped and submitted. It does not store incoming requests for later automatic resend, and it does not return the final asynchronous business result to ERP.

Agree these outcomes with the ERP team:

Retain the request's business identifier, customer IDs, timestamp, and CPI message ID for reconciliation. Do not assume one identifier is automatically propagated to every system.

For this baseline, allow mapping and submission exceptions to fail the iFlow and verify the actual HTTP status/body returned to the caller. If you add an Exception Subprocess for logging, use an Error End event to retain a Failed execution status, and verify its sender response. An ordinary End event can mark a handled execution Completed; do not mistake that for successful business processing.

Record the deployed receiver timeout and retry settings, and check whether a retry can resubmit records or a whole request. A unique matching key helps Account Upsert but does not remove uncertainty about earlier work or prevent repeated automation side effects.

If the old PO interface acknowledged only after durable persistence, agree a persistence/retry design in CPI before cutover; this simple HTTPS → mapping → receiver flow does not reproduce that guarantee by itself.

6. Confirm Readiness for the End-to-End Test

Before sending the ERP request, confirm:

Use the existing PO results as the comparison baseline. Resolve any differences before continuing to the end-to-end test.

7. Deploy and Send the Original ERP Request

1. Confirm that the compatible adapter and selected mapping artifact are deployed.
2. Save and deploy the iFlow containing the Message Mapping step.
3. Copy the actual deployed HTTPS endpoint.
4. Send the source XML, not the mapping output.

Postman replays the ERP source contract for the migration test. The production sender is ERP. In this example, the incoming body contains KUNNR, NAME1, ORT01, and TELF1; Salesforce field names appear after the selected mapping executes. For a customer's different source contract, send that contract's original field names and structure instead.

Retain the HTTP status, timestamp, CPI message ID, and agreed source business identifier. The submission can return an empty body; final Account processing results are verified in SKYVVA and Salesforce.

Use temporary tracing only with approved sanitized test data to compare the output immediately after Message Mapping and before the receiver. Disable tracing when the comparison is complete. Do not include credentials in the payload.

Figure 9. ERP source request submitted to the CPI migration endpoint.

8. Verify Both Accounts

Open SAP Integration Suite → Monitor → Monitor Message Processing and inspect the execution and receiver submission result. The mapped body is available only if the chosen trace/logging configuration captured it; ordinary message monitoring does not automatically retain every payload. In Salesforce, open the SKYVVA integration/interface and its message monitoring. Follow both customer records to their final processing result, then inspect the Accounts by ERP ID. Do not run the address-change exercise until this initial processing has completed successfully.

If you seeded the first Account, its Salesforce ID must remain unchanged. The second Account should be newly created. In an initially empty sandbox, both are new.

Use Salesforce's Account list or this read-only SOQL in your approved query tool:

SELECT Id, ERP_Customer_ID__c, Name, Phone, BillingCity
FROM Account
WHERE ERP_Customer_ID__c IN ('0000100451', '0000100452')
ORDER BY ERP_Customer_ID__c

Expect one Account per ERP number. Inspect SKYVVA's record-level results as well: a transport response or CPI Completed status alone is not proof that every business record succeeded. Successful SKYVVA messages may be cleared according to the interface's retention/cleanup settings. Agree the evidence needed before testing; a missing retained success message does not by itself establish failure. Use Account readback and the available processing/log evidence together.

Figure 10. CPI execution, SKYVVA processing results, and the two verified Accounts.

9. Replay an ERP Customer Change Through the Mapping

After the initial asynchronous processing completes, record the Salesforce ID of 0000100451. Send erp-customer-update.xml to the same CPI endpoint:

<?xml version="1.0" encoding="UTF-8"?>
<Customers>
    <Customer>
        <KUNNR>0000100451</KUNNR>
        <NAME1>Northstar Parts Training</NAME1>
        <ORT01>West Training City</ORT01>
        <TELF1>+1-202-555-0103</TELF1>
    </Customer>
</Customers>

Verify that the mapping produces an Account with the same ERP ID, phone +1-202-555-0103, and billing city West Training City. Then follow the asynchronous business result and verify:

• The existing Account retains its Salesforce ID.
• For the fields in this example, Phone and Billing City change while Name and ERP Customer ID retain their expected values. Review audit fields and any Salesforce automation separately against the agreed PO baseline.
• Exactly one Account matches 0000100451.
• The second Account retains its previous values.

If matching fails or a duplicate appears, compare the source and mapped ERP ID, External ID field definition, interface matching selection, and target interface routing. Confirm that this request actually passed through the imported mapping.

Figure 11. Customer change applied to the existing Account while preserving its ERP matching key.

10. Follow Asynchronous Processing to Completion

Keep Skyvva API = V4/integrate for both the initial customer request and the address-change request. Follow each submission through SKYVVA monitoring to its final business result.

For the asynchronous setup used here, a successful sender response confirms submission rather than final processing of every customer. An empty response body can be normal. Check the business results before sending the next change or retrying an earlier request.

If a customer remains pending or fails, inspect its SKYVVA message details and the interface's asynchronous processing setup. Correct and reprocess according to the agreed operating procedure; do not repeatedly resubmit both customers without reconciling the earlier attempt.

Confirm the final SKYVVA outcome and Salesforce records after each request before considering the transaction complete.

If the migrated flow also maintains Contacts, include the related interfaces and Account relationships in a separate acceptance test. This guide's Account-only checks do not establish that Contacts are correctly linked.

10.1 Rehearse with the Actual ERP Sender

After the Postman tests pass, have the ERP team send a controlled request from the non-production ERP system through its configured CPI connection. Use approved test customer IDs and record the expected values before sending; do not overwrite the earlier test state without accounting for that change.

1. Verify the ERP destination, authentication, and certificate trust for the non-production CPI endpoint.
2. Trigger the normal customer export or customer-change process in ERP.
3. Record the ERP dispatch result, business identifiers, and timestamp.
4. Locate the corresponding CPI execution and verify that the intended mapping and receiver are used.
5. Follow SKYVVA processing and compare the resulting Accounts with the ERP request and agreed PO behavior.

This rehearsal must establish that the actual ERP sender can authenticate and send the expected customer structure. A Postman request alone does not verify ERP connectivity or source-system behavior. Complete this check before redirecting production traffic.

11. Review the Tenant Before Production Deployment

Check the CPI runtime, adapter build, SKYVVA Salesforce package, and receiver configuration in both test and production. Use a supported compatible combination.

If deployment succeeds in test but fails in production, compare the installed versions and saved configuration with the adapter provider. Complete deployment before testing customer updates. Changing the customer payload does not resolve an incompatible installation.

12. Complete the Migration Checks

For the production cutover, preserve the existing interface behavior until equivalence has been demonstrated. Agree and record:

Proceed with cutover only after the PO/CPI developer, ERP owner, and Salesforce/business owner accept the relevant checks. Any unresolved mapping, delivery, or recovery difference needs an agreed resolution before production traffic is redirected.

If dispatch cannot be paused, agree an equivalent routing boundary and reconciliation plan before cutover. Do not run both routes against the same customer changes without an agreed duplicate/ordering strategy. Upsert does not prevent an older address change from overwriting a newer one. Restoring an older route does not reverse Salesforce updates already committed.

For support, collect versions, sanitized XML and receiver settings, CPI message ID, timestamp/timezone, SKYVVA message or batch ID, record-level results, and expected versus actual Account values. Remove credentials, tokens, and real customer information before sharing.

Migration tooling supports pattern-based migration; imported artifacts still require validation of their dependencies and business behavior.