1. SkyvvaSalesforce Receiver Adapter in SAP Cloud Platform Integration

This document introduces the SkyvvaSalesforce Receiver Adapter, which is used to send data from SAP Cloud Integration (SAP CPI) to Salesforce.

The adapter is configured on the receiver side of an integration flow. It supports communication with Salesforce through the SKYVVA Integration Suite and provides configuration options for authentication, API selection, request processing, logging, retry behavior, and timeout settings.

The following example shows a simple end-to-end integration flow:

Figure 1. End-to-end sample integration flow using the SkyvvaSalesforce receiver adapter.

Context Before You Start

In short: this adapter is the entry point on the SAP CPI side for calls going into Salesforce — an iFlow's receiver channel, configured to call one of SKYVVA's inbound REST APIs (legacy V2 or the fuller V3 Integration Service model) so that data reaching CPI ends up processed by a Salesforce interface.

Reasons to reach for it:

You already have an iFlow where SAP CPI is the caller and Salesforce is the target, and you need a receiver channel that speaks SKYVVA's own protocol rather than a generic Salesforce REST/SOAP call built by hand.
It centralizes authentication (OAuth2), API selection, and request/response shape in one channel config, instead of re-implementing SKYVVA's REST contract per iFlow.

Good fit for:

Any inbound-to-Salesforce scenario in this tutorial series — single-record push How to Create a SKYVVA Inbound Interface Using the Integrate() with the SkyvvaSalesforce Adapter?, synchronous request/response ( How to create an inbound synchronous interface using integrateSynchronous() with SkyvvaSalesforce Adapter?), or batch ( How to create an inbound interface using integrateBatch() with SkyvvaSalesforce Adapter) — this document is the shared field-by-field reference all three build against.
Teams that need to understand every tab/field on this channel before wiring up their first (or their tenth) integration flow, not just copy one example verbatim.

End-to-end sequence: the sections below walk tab by tab — General, Connection, then Skyvva (Request Settings for V2 vs. V3, and Adapter Settings) — covering what each field does and how it's actually consumed at runtime.

2. Receiver Adapter Configuration

Select SkyvvaSalesforce as the receiver adapter in the SAP Cloud Integration integration flow.

The receiver adapter includes the following main configuration areas:

General
Connection
Skyvva

The Connection tab is used to configure authentication and the Salesforce connection. The Skyvva tab contains the request and adapter settings.

Figure 2. Selecting SkyvvaSalesforce as the receiver adapter type.

The General tab identifies the channel itself, once SkyvvaSalesforce has been selected as the receiver adapter:

Parameter	Description
Name	The channel's display name in the iFlow. Editable free text.
Direction	Fixed to `Receiver` — determined by which side of the iFlow the channel is placed on, not user-selectable here.
System	Fixed to `Receiver`, matching Direction.
Description	Optional free-text notes about the channel.
Adapter Type	Fixed to `SkyvvaSalesforce` — identifies which adapter is handling this channel.
Transport Protocol	Fixed to `https`.
Message Protocol	Fixed to `skyvva`.

The Direction/System/Adapter Type/Transport Protocol/Message Protocol values are all fixed by the adapter registration itself — only Name and Description are actually editable on this tab.

Figure 3. SkyvvaSalesforce receiver channel — General tab (Direction = Receiver, Adapter Type = SkyvvaSalesforce).

3. Connection Tab

The Connection tab is used to configure authentication for the Salesforce connection.

Configure the following settings:

Parameter	Description
Authentication Type	Defines the authentication mechanism used to connect to Salesforce.
OAuth2 Flow	Defines the OAuth2 flow used for authentication.
Login URL	Specifies the Salesforce login URL.
User Credential	Specifies the User Credential artifact when using the Username-Password Credential flow.
Client Credential	Specifies the OAuth2 Client Credentials artifact when using the Client Credential flow.

Figure 4. SkyvvaSalesforce receiver channel — Connection tab (OAuth2 Flow = Client Credential).

3.1 Authentication Type

The Authentication Type is currently fixed to: OAuth2

3.2 OAuth2 Flow

Select one of the following OAuth2 flows:

Username-Password Credential
Client Credential

The Client Credential field is always shown on this tab, regardless of which flow is selected — it isn't hidden or shown based on this dropdown. What the OAuth2 Flow selection actually controls is the User Credential field:

OAuth2 Flow	Fields shown	Fields to fill in
`Username-Password Credential`	User Credential and Client Credential	Both — see §3.4 and §3.5.
`Client Credential`	Client Credential only	Client Credential only.

3.3 Login URL

Enter the URL of the Salesforce organization.

Examples:

Environment	Login URL
Sandbox	`https://test.salesforce.com`
Production	`https://login.salesforce.com`
My Domain	Your Salesforce My Domain URL

3.4 User Credential

The User Credential field is displayed when: OAuth2 Flow = Username-Password Credential

Enter the name of the User Credential artifact deployed in SAP CPI.

The credential is configured under: Monitoring → Manage Security→ Security Material

The User Credential contains the Salesforce username, password, and security token when required.

Figure 5. SkyvvaSalesforce receiver channel — Connection tab (OAuth2 Flow = Username-Password Credential), showing the User Credential field alongside Client Credential.

3.5 Client Credential

The Client Credential field specifies the OAuth2 Client Credentials artifact deployed in the SAP CPI keystore.

The credential contains the Salesforce Connected App or External Client App credentials, including:

Consumer Key
Consumer Secret

This field is always shown, regardless of the selected OAuth2 Flow — it is not conditionally hidden the way User Credential is, and it is always required, not just displayed.

When OAuth2 Flow = Client Credential: this is the only credential needed.
When OAuth2 Flow = Username-Password Credential: this field is still shown alongside, and required together with, User Credential (§3.4). This is expected OAuth2 behavior, not a UI quirk — the Username-Password ("resource owner password") grant authenticates both the calling app (Consumer Key/Secret, i.e. Client Credential) and the Salesforce user (username/password/token, i.e. User Credential) in the same token request. Leaving Client Credential blank on this flow will fail authentication even though the flow's name only mentions the user.

4. Skyvva Tab

The Skyvva tab contains two main sections:

Request Settings
Adapter Settings

The available request settings depend on the selected Skyvva API Version.

5. Request Settings

The Skyvva API Version determines which request configuration fields are available.

The adapter supports:

5.1 Skyvva API Version

Select the SKYVVA API version that matches the integration scenario.

API Version	Description
`V2`	Uses a selected SKYVVA API and HTTP method to define how the request is processed.
`V3`	Uses the SKYVVA Integration Suite configuration, including Integration, Interface, Mode, processing behavior, request format, response format, and additional settings.

This choice should be driven by what the integration scenario actually needs, not just picked as a technical default:

Scenario	Choose	Why
A new inbound integration going through SAP CPI	`V3`	Gives access to the full Integration/Interface/Mode model — Synchronous, Asynchronous, Skyvva Batch, Skyvva Bulk, Salesforce Bulk, or Auto-Switch processing — plus request/response format control per interface. This is the standard choice for new work.
A simple, one-off call to an existing Apex REST resource (e.g. a legacy `Integrate` or `integrateBatch` endpoint already in use)	`V2`	V2 only needs a Skyvva API + Apex Method on this adapter — there's no Integration/Interface field here the way V3 has (§7.1–7.2). Instead, the target Integration and Interface are identified as fields inside the request body itself (e.g. `integrationid` + `interfacename`, built by the iFlow's message mapping) — see §6. Appropriate for a single predictable call, not a channel managing many different interfaces.
An existing, working V2-based receiver channel	Keep `V2`	No need to migrate a working configuration just because V3 is newer — move to V3 when the scenario needs a V3-only capability (e.g. batch/bulk processing modes, richer response handling), not as a standalone effort.

In short: default to V3 for new integrations; stay on V2 only when the scenario is a simple, already-defined Apex call or an existing configuration that still meets its purpose.

Figure 6. SkyvvaSalesforce receiver channel — Skyvva tab, Request Settings and Adapter Settings (Skyvva API Version = V2, Skyvva API = integrateBatch).

6. Request Settings for V2

When Skyvva API Version is set to: V2

the adapter provides the following request settings:

Skyvva API
Apex Method

Unlike V3, V2 does not provide a separate Mode, Request Format, or Response Format setting on this adapter — those fields only render when Skyvva API Version is V3. The selected Skyvva API determines how the request is processed, and the request body's own format (JSON or XML) must match what that Apex REST resource expects — it isn't chosen here.

Important — Integration and Interface still have to be identified, just not on this adapter. V2 has no Integration/Interface fields because that information isn't adapter configuration — it's part of the request body itself. The message mapping upstream in the iFlow must build the JSON (or XML) payload with the target Integration and Interface identified as body fields, alongside the actual data in messages, before it reaches this channel.

The exact required keys depend on the selected Skyvva API:

Skyvva API	Required body keys (in addition to `messages`)
`Integrate`	`integrationid`, `interfacename`, and `batchmode` (`"true"`/`"false"` — picks batch vs. single-record processing inside this one endpoint)
`IntegrateSynchronous`, `integrateBatch`	`integrationid`, `interfacename` (no `batchmode` — these endpoints don't fork on it)

If a required key is missing from the body, the Salesforce-side REST resource rejects the call outright — it has no other way to know which Integration/Interface to route the message to, or (for Integrate) which processing path to take.

6.1 Skyvva API

Select the SKYVVA API to use for the integration.

The field provides predefined API values and also allows a custom value to be entered when required.

API	Description
`Integrate`	Processes a standard inbound integration request asynchronously.
`IntegrateSynchronous`	Processes the request synchronously and returns the response in the same call.
`integrateBatch`	Processes incoming records using SKYVVA batch processing.
`SearchService`	Retrieves Salesforce records based on the configured search criteria.
`V4/integrate`	Processes a standard inbound integration request using the V4 API.
`V4/integrateSynchronous`	Processes the request synchronously using the V4 API and returns the response in the same call.
`V4/integrateBatch`	Processes incoming records using batch processing through the V4 API.

6.2 Apex Method

Select the HTTP method used for the SKYVVA API request.

Available methods include:

GET
POST
PUT
PATCH
DELETE

For most inbound integration scenarios using the following APIs, the method is:

Integrate
IntegrateSynchronous
integrateBatch

The recommended method is:POST

7. Request Settings for V3

When Skyvva API Version is set to:V3

the adapter switches to the SKYVVA Integration Suite configuration.

The V2 fields Skyvva API and Apex Method are replaced by the V3 configuration fields.

Figure 7. SkyvvaSalesforce receiver channel — Skyvva tab, Request Settings and Adapter Settings (Skyvva API Version = V3).

The V3 configuration includes:

Parameter	Description
Integration	Specifies the SKYVVA Integration.
Interface	Specifies the SKYVVA Interface.
Mode	Defines how the integration request is processed.
Processing Behavior	Defines additional processing behavior for asynchronous requests.
Request Format	Defines the request message format.
Response Format	Defines the response message format.
Skyvva App Version	Specifies the SKYVVA application version.
Salesforce API Version	Specifies the Salesforce API version.

7.1 Integration

Enter the name of the SKYVVA Integration record in Salesforce that this channel should call.

The Integration identifies the Salesforce integration configuration used for the request.

7.2 Interface

Enter the name of the SKYVVA Interface record in Salesforce that this channel should call.

The Interface identifies the specific inbound interface associated with the selected Integration.

7.3 Mode

The Mode setting defines how the integration request is processed.

Available options include:

Mode	Description
`Asynchronous`	The request is queued and processed asynchronously.
`Synchronous`	The request is processed immediately, and the result is returned in the same call.
`Skyvva Batch`	The incoming records are collected into a batch and processed together.
`Skyvva Bulk`	Uses SKYVVA bulk processing for high-volume record sets.
`Salesforce Bulk`	Uses Salesforce Bulk API processing for high-volume record sets.
`Auto-Switch`	Automatically selects the appropriate processing method based on the configured thresholds.

Select the mode according to the integration requirements.

Note: Synchronous is the default mode.

7.4 Processing Behavior

The Processing Behavior field is available when:Mode = Asynchronous

Available options include:

Processing Behavior	Description
`None`	Default behavior with no additional asynchronous processing.
`Batch Apex - Large Message (non-transactional)`	Processes a large message using Batch Apex outside a single Salesforce transaction.
`Create Message Only`	Creates the SKYVVA message without immediately triggering further processing.

This setting controls how asynchronous messages are handled.

7.5 Request Format

Select the format of the request message sent to Salesforce.

Available formats:

JSON
XML

JSON is the default.

The selected format should match the message format used by the source system and integration flow.

7.6 Response Format

Select the format of the response message returned from Salesforce.

Available formats:

JSON
XML

JSON is the default.

7.7 Skyvva App Version

Specifies the SKYVVA application version installed in the target Salesforce organization.

Example:2.48.0

Use this setting when the adapter configuration requires compatibility with a specific SKYVVA application version.

7.8 Salesforce API Version

Specifies the Salesforce API version used for the V3 request.

Example:53.0 Select the Salesforce API version supported by the target Salesforce organization and integration configuration.

8. Adapter Settings

The Adapter Settings section applies regardless of the selected SKYVVA API Version — it appears at the bottom of the Skyvva tab in both Figure 6 (V2) and Figure 7 (V3) above.

The following settings are available:

Parameter	Description
Logging Option	Defines the logging level used by the adapter.
Enable Retry for Fatal Connectivity Errors	Enables automatic retry for connectivity-related failures.
HTTP Client Timeout	Defines how long the HTTP client waits for a response.

8.1 Logging Option

Select the logging level for the channel.

Available options:

Logging Option	Description
`Default`	Normal adapter logging. This is the default value.
`Trace level`	Provides the most detailed diagnostic logging. Use only when troubleshooting.
`Debug level`	Provides detailed diagnostic information for troubleshooting.
`Info level`	Logs general informational events.
`Warning level`	Logs warning-level events and more severe events.
`Error level`	Logs error-level events only.

Use Default during normal operation.

Use Trace or Debug only when troubleshooting because these levels generate additional log data.

8.2 Enable Retry for Fatal Connectivity Errors

This option is disabled by default.

When enabled, the adapter retries requests that fail because of connectivity problems.

Value	Description
Disabled	Connectivity failures cause the message to fail without automatic retry.
Enabled	The adapter automatically retries connectivity-related failures before failing the message.

This option is intended for temporary transport-level connectivity problems, such as connection failures or connection interruptions.

It does not replace normal error handling for application-level HTTP errors returned by Salesforce or SKYVVA.

8.3 HTTP Client Timeout

The HTTP Client Timeout defines the number of seconds that the adapter waits for a response from Salesforce or the SKYVVA service.

Example:60 seconds

Increase the timeout when processing requests that may require additional time, such as large messages or long-running operations.

9. Summary

The SkyvvaSalesforce Receiver Adapter enables SAP Cloud Integration to send data to Salesforce through the SKYVVA Integration Suite.

The main configuration areas are:

Configuration Area	Purpose
Connection	Configures OAuth2 authentication and Salesforce connection details.
Request Settings	Configures the SKYVVA API version and request processing.
V2	Uses a selected SKYVVA API and HTTP method; Integration/Interface are identified inside the request body itself, not configured on this adapter.
V3	Provides Integration, Interface, Mode, processing behavior, and message format configuration directly on this adapter.
Adapter Settings	Configures logging, retry behavior, and HTTP timeout.

The adapter supports different integration scenarios, including:

Standard asynchronous integration
Synchronous integration
SKYVVA batch processing
SKYVVA bulk processing
Salesforce Bulk API processing
Automatic processing mode selection