SkyvvaSalesforce Adapter — Patch Update Guide
1. About this guide
Use this guide for a Patch Update: 1.2.0 → 1.2.3. The patch number is the last number in the version; it changes from 0 to 3, while 1.2 stays unchanged. Use the new adapter file for version 1.2.3 (.esa) and read its release notes to see which fixes it includes. An integration flow (iFlow) is the process that sends data between systems. Its receiver channel is the connection line that sends data to Salesforce. A patch update keeps this connection and its settings.
Both 1.2.0 and 1.2.3 provide the Username-Password Credential and Client Credential OAuth2 flow options. Keep the flow already configured in 1.2.0 when applying this patch update.
For new features that change the middle version number, such as 1.1.x → 1.2.x, follow the Version Upgrade Guide.
For the update example, use Skyvva API Version = V3 and Mode = Synchronous before and after the update. Run a successful test with these settings before changing the adapter version.
Updating the adapter file and updating a receiver channel are separate actions. Saving an integration flow version backs up its configuration; keep the previous adapter file separately.
2. Before you start
Before starting, prepare the following:
| Requirement | What you need |
|---|---|
| Source and target release | A receiver using 1.2.0 and the new adapter file for version 1.2.3 with its release notes. |
| SAP Integration Suite access | Permission to edit and save the integration flow, deploy the adapter and flow to make them available to run, and view logs. Ask your administrator to perform steps you cannot access. |
| Working configuration | The working Salesforce address, credential aliases (the names of saved credentials in Security Material), SKYVVA Integration and Interface, mode and data formats. Also record any values maintained outside the flow under Configure. Check that the credentials are deployed in Security Material. |
| Salesforce verification | Access to the intended Salesforce organization, SKYVVA processing results and resulting business records, or an administrator who can verify them. |
| Test request | Sample data, the expected Salesforce result, and a unique value that helps you find the same test in the logs and Salesforce. |
| Synchronous scenario | A working V3 interface with Mode = Synchronous. In this mode, the caller waits for the processing response. Confirm that a test succeeds before starting. |
| Recovery files | A saved version and downloaded backup of the integration flow, plus the previous adapter file. Create the flow backup in Section 3. |
| Deployment method | An administrator who knows how to replace the existing adapter file in your SAP Integration Suite environment. |
Keep the existing OAuth2 flow during this patch update. Change the sign-in method separately, after testing the update.
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. 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.
Try the procedure in a test environment first. Find all integration flows that use this adapter and agree a time for the change with their owners. Run and record a successful test before replacing the adapter, then repeat it afterwards. Test the other affected flows too.
3. Update procedure
3.1 Confirm the update scope
Check that the release notes cover 1.2.0 → 1.2.3 and the fix you need. This guide covers the receiver connection. A change listed only for the Sender does not confirm a change to the Receiver.
Confirm that the new release supports your existing 1.2 receiver settings.
If the notes require new settings or describe new processing options, ask the release provider which upgrade procedure to use.
3.2 Save the current configuration
- Open Design, then open the package containing your integration flow. Some SAP Integration Suite layouts show this page under Design → Integrations and APIs.
- Open the flow and select its SkyvvaSalesforce receiver connection. Record the settings on each tab, including OAuth2 Flow.
- Check the installed adapter version separately in the adapter details. Confirm it is 1.2.0. Check the adapter version in Integration Adapter Details rather than the receiver’s General tab.
- Choose Edit → Save as Version and enter a comment such as Before patch update to 1.2.3.
- Download a backup of the flow. Ask your administrator to retain the previous adapter file.
To check the saved flow version, return to the package’s Artifacts tab and click the flow’s version number to open Version History. This is the flow version, which may differ from the adapter version.
Record the values from your working 1.2.0 connection before updating it.
Use the actual connection, Integration and Interface values from your working flow.
| Setting | Settings to record before the update |
|---|---|
| Login Url | Existing Salesforce login address. |
| OAuth2 Flow | Existing Username-Password Credential or Client Credential selection. |
| User Credential / Client Credential | Preserve both aliases for Username-Password Credential. For Client Credential, preserve the application alias; User Credential is hidden. |
| Integration / Interface | Existing SKYVVA Integration and Interface values. |
| Skyvva API Version / Mode | V3 / Synchronous. |
| Request / Response Format | XML / XML in the illustrated scenario. |
| Skyvva App Version | Record the Salesforce SKYVVA package version actually installed. |
| Salesforce Api Version | Record the working Salesforce API version. |
| Logging / retry / timeout | Record the working values; the example defaults are Default / unchecked / 60 seconds. |
Also record values maintained under Configure and any field mapping used to prepare the request. Adapter version 1.2.3 does not replace the SKYVVA package version, V3 selection, or Salesforce API version.
Figure 1. Connection and Skyvva settings recorded before the patch update.
Figure 2. Saved integration flow version available before applying the patch release.
3.3 Deploy the patch release
- Open Design. In Integration Packages, open the package containing the existing adapter, then select Artifacts.
- On the existing 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.
- In the Integration Adapter file field, click the browse icon and select Skyvva-Salesforce-1.2.3.esa. Check that the adapter ID remains unchanged; do not edit it.
- Check the selected file and the version read from it, then click Save. This saves the uploaded file; it does not deploy it.
- Return to the adapter row and click Actions → Deploy to make the saved adapter available to run.
- Wait for deployment to finish.
In Integration Adapter Details, the Name, ID and Version fields are read-only. Select the new .esa file using the browse icon; do not type a new version into the Version field. Check the resulting adapter version after saving.
The adapter and integration flow may be in different packages.
If uploading reports that the adapter ID already exists, ask the administrator to check the existing adapter and replacement method before continuing.
Figure 3. Upload and save the new adapter file, then deploy it from the Actions menu.
Open Monitor → Manage Integration Content, find SkyvvaSalesforce, and check the deployed version and status. Confirm that version 1.2.3 is running before testing the flows that use it. Keep the previous adapter file for recovery.
Figure 4. Deployment status of the SkyvvaSalesforce 1.2.3 adapter release.
3.4 Check the existing channel
Reopen the flow and select the same receiver connection. Compare its settings with those recorded before the update, including OAuth2 Flow. If the release notes describe a screen or field correction, check it here.
Refresh the flow editor to see any field or label corrections. Keep the existing receiver connection. A patch update does not require the Update Version action used for a Version Upgrade.
Figure 5. Connection and Skyvva settings checked after the patch update.
If an expected screen correction is missing, reload the editor and confirm that the Receiver connection is selected and adapter 1.2.3 is deployed. Check the adapter version in Integration Adapter Details. For fixes that affect processing, use the tests below to check the result. Ask the administrator whether the flow needs to be deployed again for the change to take effect.
4. Test the result
Confirm the following results before using the updated adapter in production:
| Check | Expected result |
|---|---|
| Adapter release | The deployed archive is the intended 1.2.3 release; any documented UI correction is visible. |
| Release corrections | Tests for the bug fixes or corrections relevant to your scenario give the expected result. |
| Authentication | The previously selected OAuth2 flow and credential aliases still authenticate successfully. |
| Processing settings | Integration, Interface, API version, mode, data formats and values under Configure match the settings recorded before the change. |
| CPI result | The test message has no unexpected processing error. |
| Synchronous response | The response uses the expected format and reports the expected result. Check for errors for each record. |
| Salesforce result | SKYVVA shows the expected processing result. The expected Salesforce records and links between them exist. |
For this synchronous scenario, inspect the returned business result and confirm the Salesforce records as well as the CPI message status.
4.1 Validate and save any changes
Validate the flow and save any required channel changes.
4.2 Deploy saved flow changes
If the flow was changed, deploy it after the adapter deployment.
4.3 Send a test request and check CPI
Send sample data using the same request format and field mapping as before the update.
Figure 6. CPI processing result for the test request after the patch update.
4.4 Check Salesforce processing
Check the synchronous response for business errors and verify the corresponding SKYVVA result and Salesforce records.
Figure 7. Salesforce processing and business result verified after the patch update.
Confirm that authentication succeeds, the intended Integration and Interface receive the request, and the CPI log has no unexpected error. For the selected Synchronous scenario, inspect the returned business response and confirm the expected Salesforce records. Compare response handling with the previous result.
Record the deployed adapter version, test message ID and test results. Confirm that the saved settings and response handling still work as expected.
5. Restore the previous setup if needed
If a test fails, save the error details and compare the settings with those recorded before the update.
To restore the flow settings:
- Open the package’s Artifacts tab and click the flow’s version number.
- In Version History, select the version saved before the update and choose Revert.
- Validate, save and deploy the restored flow, then test again.
If the problem comes from the new adapter, ask the administrator to restore the previous adapter file and test all affected flows. Restoring the flow alone does not restore the adapter file or undo records already created in Salesforce.