2. SkyvvaSalesforce Receiver Adapter — Minor Upgrade Guide

This guide covers two ways to upgrade an existing receiver channel: automatic migration with Update Version, or manual recreation when CPI cannot migrate the channel. Confirm the supported upgrade path and required setting changes in the release instructions or with SKYVVA support before replacing the adapter.

This guide updates an existing, working receiver connection. If you are new to CPI, follow the steps with the administrator who manages your integration environment. Have the flow name, adapter package and release file ready before starting.

Procedure at a glance: record and back up the working setup → upload and deploy the target adapter archive → migrate the receiver with Update Version or recreate its connection manually → restore and review settings → save, deploy and test each affected iFlow. Experienced CPI users can start at Before you start.

1. About this guide

A minor upgrade changes the middle number of the adapter release while keeping the first number unchanged. The release instructions describe the supported upgrade paths and any required configuration changes.

An integration flow (iFlow) is the process that sends data between systems. Its receiver channel is the connection line that sends data to Salesforce. First deploy the new adapter software, then update each receiver channel that needs the new configuration version. Update Version migrates the selected channel automatically when compatible. Otherwise, recreate that receiver connection and enter its settings manually. Deploying the adapter alone leaves existing channels on their earlier configuration versions.

Identify changes in your target release

Use the release instructions to compare your current configuration with the target release:

The processing examples in this guide use Skyvva API Version = V3, Mode = Synchronous, and JSON / JSON. Use your own working settings where supported by the target release. Synchronous means that the caller waits for the processing response; for another mode, agree how to verify completion with the flow owner before testing.

For a patch-only update within one minor release, use the Patch Update Guide and the applicable release instructions.

Which upgrade steps should I follow?

Open your integration flow and select the connection line that sends data to Salesforce. Click its information icon to check the connection's version. If you cannot find it, ask your CPI administrator—the person who manages your integration environment.

Choose the method for each channel using the release instructions and CPI’s result. Compatibility can depend on its saved configuration and earlier upgrade history. CPI accepting a migration confirms that the configuration can be migrated; successful runtime and business processing still require testing.

What does “contains incompatible changes” mean? CPI cannot automatically carry this channel's saved configuration into the target component. Added, removed or reorganized settings can be a reason, but the message alone does not establish the cause. Keep the error and source/target versions. Manual recreation can address configuration migration; it does not make an unsupported operation or runtime compatible. Ask SKYVVA support if an existing capability has no supported equivalent in the target release.

The Update Version button’s availability depends on whether CPI offers a newer component version for the selected channel and runtime profile. A patch update within the same component minor version does not require this action.

Check the target offered by Update Version before continuing. If it differs from the planned component version, confirm the intended release and supported path with the administrator or release provider before accepting it.

Throughout the steps below, current version means the version you recorded before the change, and target version means the specific release and receiver component you have selected for this upgrade. The archive release and receiver component version must be recorded separately; their displayed numbers need not be identical.

What if I keep the earlier channel version?

If you deploy the new adapter archive without using Update Version or recreating a channel, that channel retains its earlier configuration version and settings screen. It uses the updated shared runtime, while settings introduced only in the newer component remain unavailable on that channel.

Where the target release supports the earlier configuration, the iFlow can continue using it. Follow the release instructions for any required redeployment or reconfiguration and test the existing scenario. To use the newer component’s settings, follow one of the two migration paths below.

Does updating one iFlow update all existing iFlows?

No. Separate the shared adapter deployment from changes to individual channels:

For example, if three iFlows each have one receiver to upgrade, deploy the archive once, update or recreate all three channels, then save, deploy and test each iFlow separately. Repeat the deployment and checks in every target tenant.

An existing iFlow whose channel has not been migrated retains its earlier component configuration, but it still uses the shared adapter runtime. Confirm in the target release notes whether that configuration remains supported and whether redeployment or reconfiguration is required. Include unchanged channels in the upgrade tests. If staged migration is supported, test both migrated and remaining flows during the rollout.

Terms used in this guide

SAP Cloud Integration is the integration service in SAP Integration Suite. This guide also calls it CPI. Your tenant is your organization's Cloud Integration environment, such as test or production.

How to read the adapter version in SAP CPI

SAP uses Major.Minor.Micro. Micro is also called patch.

The table uses 1.3.0 to illustrate the version numbers. For your upgrade, record two versions separately:

• Adapter archive release: the full number, such as 1.3.0, in Integration Adapter Details and Monitor → Manage Integration Content.
• Receiver component version: the configuration version shown by the receiver's information icon and the Update Version action, for both the current and intended target component.

The package version and the integration flow version saved with Save as Version are separate again. Saving an integration flow version backs up its configuration; retain the previous adapter .esa file separately.

2. Before you start

Before starting, prepare the following:

Keep the existing authentication method and credential aliases where the target release supports them. If a method has changed or been removed, obtain the required authentication migration instructions before proceeding.

Check bug fixes and new features on the SKYVVA website

On the SKYVVA website, open the release notes for the target version. Confirm that the entry applies to the SkyvvaSalesforce adapter running in SAP CPI and matches the version of the new adapter file.

Read the fixes, new features, supported versions and required setting changes. Also read the notes for any releases between your current and new versions. Follow the documented upgrade sequence, including any required intermediate releases. Choose tests that cover the changes you use.

If the notes for your adapter version are unavailable, ask SKYVVA support or the person supplying the adapter file. Check the notes for the CPI adapter, as the Salesforce SKYVVA package has separate release notes.

Use a test environment first. The deployed adapter software is shared by flows using it, so replacing it can affect more than the flow shown in this guide. Find all integration flows that use this adapter across packages and agree a time for the change with their owners. Track each flow and receiver channel, its current component version, chosen upgrade method, configured parameter values, deployment status and test result. Include any required sender-channel checks if those flows also use the same adapter runtime. Before replacing the adapter, follow the steps in Test the result to record a successful baseline: the working configuration, test request, CPI message ID, returned response and Salesforce result. Repeat equivalent tests after the update. Test the other affected flows too.

3. Update procedure

3.1 Record the existing configuration

1. Open Design, then open the package containing your integration flow. Some SAP Integration Suite layouts show this page under Design → Integrations and APIs.

1. Open the flow and select its SkyvvaSalesforce receiver connection. Record its current component version using the information icon, then record settings on all available tabs, including authentication and processing settings. Tab names depend on the component version.

Figure 1. Existing receiver settings recorded before the minor upgrade.

Record the actual authentication method, login address and credential aliases from the working flow. Where the component offers Username-Password Credential, record User Credential and Client Credential. Where it offers Client Credential, record the application alias. Record the fields applicable to your selected method.

Record these processing settings, where available, so you can compare them after the upgrade. Record your actual values alongside these examples:

Skyvva App Version, Skyvva API Version, Salesforce Api Version, and the adapter version refer to different things. Upgrading the adapter does not mean entering its release number in any of those three processing fields.

Also record values maintained under Configure and any field mapping used to prepare the request. Confirm that the saved credential names exist in Security Material.

1. Open the package containing the adapter, select Artifacts, then choose the adapter row’s Actions → View Metadata to open Integration Adapter Details. Record its version. Also check the running version under Monitor → Manage Integration Content. If these differ, ask the administrator which release is active before continuing.

1. Return to the integration flow. Choose Edit, then Save as Version and enter a comment such as Before minor upgrade, including the actual current and target archive versions. To confirm the saved version, return to the package’s Artifacts tab and click the flow’s version number to open Version History.

Figure 2. Saved integration flow version available for recovery before the upgrade.

Save as Version keeps a snapshot of the iFlow inside CPI, including its receiver connection, saved settings and resources. Keep the separately recorded Configure values available for recovery too. Save it before changing or recreating the receiver so you can return to that configuration if testing fails. The iFlow version does not need to match the adapter version.

1. Return to the package’s Artifacts tab and use the integration flow’s Download action to keep a ZIP backup. Ask your administrator to retain the previous adapter .esa file separately.

3.2 Deploy the new adapter

The adapter and integration flow may be in different packages. Package names and versions do not identify the installed adapter release; check the adapter’s own version inside its package.

1. Open Design. In Integration Packages, open the package containing the existing adapter, then select Artifacts.

1. On the SkyvvaSalesforce adapter row, open Actions (the three dots …) and choose View Metadata. Open the details for editing if needed. Ask your administrator if you cannot edit them.

1. In the Integration Adapter file field, click the browse icon and select the approved target SkyvvaSalesforce .esa file. The Name, ID and Version fields are read-only. Check that the ID matches the existing adapter; do not edit it.

If you see Add Integration Adapter with an Add button, cancel that fresh-installation dialog and return to the existing adapter’s Actions → View Metadata.

1. Check the selected file and the version read from it, then click Save. This saves the uploaded file; it does not deploy it. Verify the adapter version after saving.

Figure 3. Select and save the target adapter archive in Integration Adapter Details.

If uploading reports that the adapter ID already exists, ask the administrator to check the existing adapter and replacement method before continuing.

1. Return to the adapter row and click Actions → Deploy to make the saved adapter available to run.

1. Open Monitor → Manage Integration Content and find SkyvvaSalesforce. Confirm that the exact target archive release is deployed and running before updating the receiver connection.

Figure 4. Target SkyvvaSalesforce adapter deployed and running before upgrading the integration flow’s receiver channel.

If deployment fails, open its error details and have the administrator resolve the failure before continuing. Test the other flows that use this adapter before applying the change in production.

3.3 Update the receiver channel version

Follow this section for channels that need the target component version. If you are retaining an earlier supported component, complete the applicable settings review and release-specific deployment and tests instead.

Choose the procedure for your receiver channel:

• Automatic migration: follow the steps under Open the integration flow in Edit mode through Check the updated connection below.
• Manual recreation: if CPI blocks migration as incompatible, go to Manual recreation when migration is incompatible.

After either procedure, continue with Review Connection and Processing settings, then Test the result.

3.3.1 Open the integration flow in Edit mode

Return to the backed-up integration flow and choose Edit. If the newly deployed adapter is not reflected in the editor, save pending changes, reload the page and reopen the flow.

3.3.2 Select the receiver connection

Click the SkyvvaSalesforce connection line to the Receiver in the diagram. Check its information icon and compare the current component version with your pre-upgrade record. Review the existing settings before starting migration.

Figure 5. Existing receiver connection and current component version selected before migration.

If the version differs from your record, resolve the difference before continuing. The steps below apply only when the intended target is available and CPI permits migration of this channel.

3.3.3 Choose Update Version

In the selected connection's settings panel, choose Update Version.

Figure 6. Update Version action for the existing receiver channel.

If the action is missing, check whether the channel already uses the intended target component. If it does, continue with Review Connection and Processing settings. Otherwise, confirm that the target archive is deployed, reload the editor and have the administrator check the flow's runtime profile and available receiver component.

A missing action alone does not prove incompatibility. If the target receiver is available for new connections but migration is unavailable, confirm with the administrator or release provider whether to use Manual recreation when migration is incompatible. If the target component itself is unavailable, resolve deployment or runtime-profile compatibility first.

3.3.4 Confirm the offered target version

Check that the offered target matches the planned receiver component version. The component version and full archive release are separate checks. If CPI offers a different target, confirm the upgrade path with the administrator before accepting.

Choose OK if CPI asks for confirmation. If CPI reports contains incompatible changes, continue with Manual recreation when migration is incompatible instead of treating the migration as successful.

Figure 7. Target component version confirmed for the selected receiver connection.

After migration, compare all existing values with your saved configuration and review any newly displayed fields before saving and deploying the flow.

3.3.5 Check the updated connection

Select the connection again. Confirm that its component version matches the intended target. Check the configuration tabs and settings against that release’s instructions. Continue with Review Connection and Processing settings to compare the saved values and any new settings before saving and deploying.

Repeat the migration and settings review for each receiver connection you intend to upgrade.

3.3.6 Manual recreation when migration is incompatible

If CPI reports contains incompatible changes, stop the automatic migration attempt and retain the error, source/target component versions and deployed archive version. Confirm that the target release supports the existing operation before recreating its channel.

Here, manual recreation means creating a replacement receiver connection inside the existing iFlow. You reuse the installed SkyvvaSalesforce adapter. You do not need to create another adapter artifact or rebuild the entire iFlow.

1. Confirm the backup and configuration record. Complete Record the existing configuration before deleting anything. Include the channel's name, source processing step, destination Receiver participant, authentication, processing values, expressions and externalized parameter references. Record their actual values under Configure separately; the new channel's defaults are not a substitute for your working settings.
2. Rehearse in a test environment. Use a copy or imported backup of the iFlow. Give a test copy a distinct inbound address where required and control any scheduled or subscribed source so it does not process production messages alongside the original flow. Test success in the copy does not update the original iFlow.
3. Remove only the old receiver connection from the test flow. Keep its source processing step, Receiver participant, mappings, scripts and other business steps. These remain part of the existing process.
4. Draw a new receiver connection from the same processing step to the same Receiver participant. Select SkyvvaSalesforce as the receiver adapter. Check the new channel's information icon to confirm that the new connection uses the intended target component version. If CPI creates another version, resolve the available component/version with the administrator before proceeding.
5. Restore the recorded settings. Enter the authentication method, login address and credential aliases. Select the target release's supported equivalent of the existing processing operation. Where the component offers these selectors for a SKYVVA integration, use Processing Type = Skyvva and Operation = Skyvva Integration. Restore the Integration, Interface, API versions, mode, formats, logging, retry and timeout. Use Review Connection and Processing settings to review all applicable fields. Resolve any missing setting with the release provider before deploying.
6. Restore parameter references and configured values. Reapply expressions and references such as {{LoginUrl}}, then check Configure for missing parameters, changed names and unintended defaults. Confirm that the destination tenant has the referenced Security Material aliases. Check that the source step still calls the intended Receiver.
7. Save, validate, deploy and test the test iFlow following Test the result. Compare the request, response and Salesforce result with the baseline. A channel that saves successfully has not yet proved successful business processing.
8. Apply the verified replacement to the original iFlow during the agreed change window, retaining its identity and production source configuration. Review that tenant's Configure values, then save, deploy and test the original flow. Repeat for every other channel that requires recreation and record each result. Stop or undeploy any temporary test copy when it is no longer needed.

If the target release cannot support the existing operation, retain or restore the supported setup and obtain an upgrade path from SKYVVA support. Recreating a channel cannot replace a missing runtime capability.

3.4 Review Connection and Processing settings

Complete this review after either automatic migration or manual recreation. Migrated values and newly created channel defaults both need comparison with the saved working configuration.

3.4.1 Preserve the Connection settings

Open Connection and compare it with the pre-upgrade record.

Figure 8. Existing authentication settings preserved after the upgrade.

If the target release no longer supports the recorded sign-in method, complete the documented authentication migration with the administrator before deploying. Reuse the existing credential aliases only where they meet the target method's requirements.

3.4.2 Select the equivalent processing operation

Locate the target component’s processing settings. For an existing SKYVVA integration, where these selectors are available, check:

1. Processing Type = Skyvva.
2. Operation = Skyvva Integration.

These labels illustrate a component that provides a Processing tab. Other versions may organize settings differently; follow their release instructions to preserve the same business operation. Select and test new Salesforce or Platform Event operations separately from the upgrade.

3.4.3 Compare the processing values

Figure 9. Target receiver settings reviewed against the recorded SKYVVA integration configuration.

If Skyvva API Version shows V2 after migration but the working flow used V3, restore the recorded V3 selection if supported. If it is unavailable, resolve the supported equivalent with SKYVVA support before testing. The adapter release number does not replace the SKYVVA package version, Skyvva API Version or Salesforce API version.

For a V2 scenario, also compare Skyvva API and Apex Method with the saved configuration. If a previously used operation, including V4/integrateWithIMessage, is unavailable, ask SKYVVA support to confirm support in the target release before deploying the flow. Do not substitute a different operation to complete the upgrade.

4. Test the result

Confirm the following results for your actual source configuration and target release before using the updated adapter in production. Follow the target release instructions for any required setting changes:

First, repeat the test that worked before the upgrade. If you later select Salesforce processing or Platform Event publishing, test that new scenario separately. For this synchronous scenario, inspect the returned business result and confirm the Salesforce records as well as the CPI message status.

4.1 Save and validate

Save the flow and run validation. Resolve any reported configuration errors.

4.2 Deploy the integration flow

Return to the package’s Artifacts tab and choose the integration flow’s Deploy action after the target adapter is deployed. Do this for every iFlow whose channels you changed; there is no tenant-wide channel migration from deploying one iFlow. Check Monitor → Manage Integration Content and confirm that the flow is running before sending a test.

Figure 10. Deployment status of the integration flow using the upgraded receiver channel.

4.3 Test and check CPI processing

1. Send a test through the same source application or test tool used for the successful pre-update test. Use equivalent sample data and preserve the working request format and field mapping. Choose a unique test reference so you can find the result in both systems.
2. In CPI, open Monitor → Monitor Message Processing. Filter by the integration flow and the time of your test, then open the matching message.
3. Record the message ID, processing status and any error details. Compare them with the pre-update result. If no message appears, check with the flow owner that the request reached the intended flow.

Figure 11. CPI processing result for the test request sent after the version upgrade.

1. Keep the response returned to the caller and use it for the Salesforce checks below.

4.4 Check Salesforce processing

1. For this synchronous example, inspect the response returned to the caller. Check for errors for individual records, even if CPI reports successful delivery.
2. In the target Salesforce organization, find the corresponding SKYVVA processing result using the test reference or identifiers returned in the response. Ask the Salesforce administrator to locate it if you do not have access.
3. Open the resulting business records, such as the test Account, and compare their values and relationships with the expected result. Record the result and any error details.

Figure 12. Salesforce processing and business result verified for the upgraded receiver channel.

For other processing modes, use the completion check agreed with the flow owner before the update.

Confirm each result:

1. Salesforce authentication succeeds with the intended user and credential aliases.
2. The request reaches the intended SKYVVA Integration and Interface.
3. The CPI message log and adapter response contain no unexpected error.
4. The synchronous response and corresponding Salesforce result confirm successful business processing.
5. The expected Salesforce records and relationships exist, and any response-handling steps still work.

A successful HTTP response or CPI message status alone does not confirm that Salesforce processed every record. Check the response for errors and verify the expected Salesforce records. Record the test message ID, adapter version, upgrade confirmation and Salesforce result before applying the change in production.

5. Restore the previous setup if needed

If a test fails, save the error details and compare the settings with those recorded before the upgrade.

Revert returns the iFlow to the saved configuration, including the receiver connection as it was at that time. For example, if you deleted and recreated the receiver after saving the version, reverting restores the earlier connection and its saved settings.

To restore the flow settings:

1. Open the package’s Artifacts tab and click the flow’s version number.
2. In Version History, select the version saved before the upgrade and choose Revert.
3. Compare Configure with the pre-upgrade record and restore any changed parameter values. Validate, save and deploy the restored flow, then test again.

Reverting does not change the deployed adapter runtime or restore Security Material credentials. The restored flow needs a compatible adapter runtime and the referenced credentials. To return fully to the previous adapter release, coordinate recovery with the owners of all affected flows. Restoring the original .esa changes the shared runtime for the tenant; newly migrated channels may also need their earlier iFlow versions restored. Ask the administrator to restore and deploy the previous archive, then deploy and test the compatible restored flows and other affected flows. Restoring the flow does not undo records already created in Salesforce.