9. How to create an inbound interface using Salesforce Bulk mode with SkyvvaSalesforce Adapter

Overview

This document explains how to create a SKYVVA Inbound Interface in Salesforce that loads high-volume flat record sets through Salesforce Bulk mode — the SkyvvaSalesforce receiver channel's Mode = Salesforce Bulk setting. Unlike Skyvva Bulk mode (covered in an earlier tutorial in this series), which uses SKYVVA's own basket engine, this mode routes records directly through Salesforce's own native Bulk API — the same mechanism tools like Salesforce Data Loader use for large data loads.

Note: Salesforce Bulk and Skyvva Bulk are the two bulk-capable values on the receiver channel's Mode field, and they are not interchangeable. Skyvva Bulk routes records into SKYVVA's own basket/mapping engine; Salesforce Bulk hands them directly to Salesforce's native Bulk API job for the target object, with no SKYVVA basket step in between. Pick Salesforce Bulk specifically when you want Salesforce's own Bulk API to own the load.

Note: This mode loads one Salesforce object per interface (for example, Account on its own) — it does not support the parent-child hierarchical mapping (Account with nested Contact records) used elsewhere in this series, since Salesforce's Bulk API processes one object type per job.

It covers the following steps:

1. Create and configure a SKYVVA Inbound Interface in Salesforce for Salesforce Bulk processing.
2. Create an integration flow in SAP CPI.
3. Configure the HTTPS sender channel.
4. Configure the SKYVVA Salesforce receiver channel with Skyvva API Version = V3 and Mode = Salesforce Bulk.
5. Deploy the integration flow.
6. Send a test request with a large record set from Postman through SAP CPI.
7. Monitor the Bulk job and message in SAP CPI and Salesforce.
8. Verify the resulting records in Salesforce.

Context Before You Start

In short: Salesforce Bulk mode hands the incoming records to Salesforce's own Bulk API as a job, split into batches automatically. Salesforce processes that job on its own schedule — this isn't instant the way a normal request/response call is. A background process in the adapter keeps checking the job's status, and once Salesforce finishes it, creates a follow-up record in Salesforce summarizing the result.

Reasons to pick this path:

• You're loading a large, flat record set (thousands of records) and want Salesforce's own Bulk

• You don't need SKYVVA's own mapping/workflow engine involved in how the batch gets uploaded —

Good fit for:

• Large, flat (single-object) data loads where per-record synchronous confirmation isn't needed.
• Cases where you specifically want the load to show up as a native Salesforce Bulk Data Load Job,

Note: Because completion depends on a background process continuously checking the job, a request going through this mode should not be expected to finish by the time the CPI response comes back — always confirm the final result in Monitoring rather than assuming the initial response means the records already exist.

End-to-end sequence: the steps below — create and configure the Interface in Salesforce, build the CPI iFlow (HTTPS sender → SkyvvaSalesforce receiver with Mode = Salesforce Bulk), deploy, send a test payload from Postman, then confirm the resulting records in Salesforce.

POSTMAN
   ↓
SAP CPI (HTTPS Sender → SkyvvaSalesforce Receiver, Mode = Salesforce Bulk)
   ↓
SKYVVA Inbound Interface
   ↓
Salesforce Bulk API job (batched automatically)
   ↓
Background job checker confirms completion
   ↓
Salesforce Account records + a summary message

Figure 1: End-to-end message flow using Salesforce Bulk mode (screenshot to be added).

1. Salesforce Interface Development

1.1 Create the Interface

Create a SKYVVA Inbound Interface under Integration in Salesforce (create the parent Integration record first if you don't already have one).

For this example, create the interface AccountSalesforceBulk_IN. Since this mode loads a single flat object, there's no hierarchical mapping step for this interface — configure it the same way you would for a normal Account-only interface.

Configure the interface:

Figure 3: Interface AccountSalesforceBulk_IN — Inbound Setup, External Mapping enabled with Salesforce External ID skyvvasolutions__ERP_DEBTOR_ID__c .

1.2 Configure Bulk Settings

In the Bulk Setting section of the interface, set:

Note: There's no package-size field to set for this mode — the adapter automatically splits the records into batches sized to stay under Salesforce Bulk API's own limits. The package-size fields used in the Batch/Bulk/Asynchronous tutorials elsewhere in this series don't apply here.

Note: The interface also has its own Bulk Version field, but when this interface is driven through a CPI channel with Mode = Salesforce Bulk (as this tutorial sets up), the CPI channel's Mode setting is what actually decides this at request time — leave Bulk Version at its default; it doesn't need to match what you select on the CPI side.

Figure 4: Interface Bulk Setting — Bulk Processing Mode

2. SAP CPI Development

2.1 Create the Integration Flow

Create the package in SAP CPI under Design and add the integration flow.

Example:

Figure 5: Integration flow for the Salesforce Bulk mode example .

Important: the Message Mapping step may show a warning icon. Hovering it reveals: "Http Sender Component may not pass XML or JSON message to Message Mapping. Message Mapping supports XML or JSON input only." This is CPI's design-time validator flagging that it can't statically prove the HTTPS Sender's output is XML/JSON — the standard HTTPS Sender adapter has no fixed content-type contract, so CPI can't guarantee it at design time. It doesn't block deployment: this flow deploys and runs successfully despite it. Safe to leave as-is as long as callers actually send XML/JSON matching Request Format, as this tutorial's Postman example does.

Where the target schema comes from: export it via the Interface record's Generate MetaData button — Format = XSD Schema, API = V3/Integrate. Then, inside the Message Mapping step's own editor (double-click it on the iFlow canvas), go to the Target panel → Select → Add → upload the downloaded .xsd → pick its root element as the Target Message Type. The file is stored as a resource on this specific integration flow, not somewhere interface/adapter-level or CPI-wide — any other iFlow needing it has to import its own copy.

2.2 Configure the HTTPS Sender Channel

Select the standard SAP HTTPS sender adapter.

General tab: Direction Sender, Adapter Type HTTPS, Transport Protocol HTTPS, Message Protocol None — fixed values, identical in every tutorial that uses this sender.

Connection tab:

Important: The configured User Role must already exist and be assigned to the CPI user/credential that Postman authenticates as, or the sender rejects the request with 403 Forbidden.

Figure 6: HTTPS sender channel — Connection tab .

2.3 Configure the SkyvvaSalesforce Receiver Channel

Select SkyvvaSalesforce as the receiver adapter. The receiver channel has three tabs: General, Connection, Skyvva.

General tab: Direction Receiver, Adapter Type SkyvvaSalesforce, Transport Protocol https, Message Protocol skyvva — fixed values, identical for every SkyvvaSalesforce receiver channel.

2.3.1 Connection Tab

Note: There is no separate "Client Id"/"Client Secret" pair on the current adapter — both are held inside the single Client Credential OAuth2 artifact deployed in the CPI keystore. For the full field reference see 1. SKYVVA CPI Salesforce Receiver Adapter in SAP Cloud Integration.md §3.

2.3.2 Skyvva Tab — Request Settings

Note: Processing Behavior is not shown for this configuration — it only appears when Mode = Asynchronous, not for Salesforce Bulk.

Figure 7: SkyvvaSalesforce receiver channel — Skyvva tab, Mode = Salesforce Bulk .

2.3.3 Skyvva Tab — Adapter Settings

⚠️ ** Integration flow deployed.

Figure 8: Integration flow deployed .

2.4 Get the SAP CPI Endpoint URL

Go to CPI → Monitoring → Manage Integration Content, locate the deployed integration flow, and copy its endpoint URL.

⚠️ ** Manage Integration Content — endpoint URL.

Figure 9: Manage Integration Content — endpoint URL.

Note: The endpoint URL shape depends on the tenant generation — Neo tenants use https://{{TenantId}}-iflmap.hcisbp.<region>.hana.ondemand.com/http/<Address>, current SAP BTP Integration Suite (Cloud Foundry) tenants use https://{{TenantId}}.<runtime-cluster>.cfapps.<region>.hana.ondemand.com/http/<Address>. Always copy the exact URL from your own tenant's Manage Integration Content panel rather than assembling it by hand.

3. Testing with Postman

Use the endpoint URL from step 2.4. Send a payload with enough Account records to be a meaningful test — a handful of records is enough to prove the flow works end to end, but this mode is built for volumes much larger than a normal request (thousands of records per job).

Create a new request with the following configuration:

Request Format = XML

configure the header as:

Content-Type: application/xml

Because this interface loads a single flat object, the payload is a plain list of Account records — no nested Contact elements, since this mode doesn't support the hierarchical shape used in the Batch/Bulk/Auto-Switch/Asynchronous tutorials elsewhere in this series:

<?xml version="1.0" encoding="UTF-8"?>
<Accounts>
  <Account>
    <ERP_DEBTOR_ID__c>ACC-000001</ERP_DEBTOR_ID__c>
    <Name>CPI Test Account 1</Name>
    <Phone>+49-89-2867825</Phone>
    <BillingStreet>CPI Test Street</BillingStreet>
    <BillingCity>Frankfurt</BillingCity>
    <BillingPostalCode>42098</BillingPostalCode>
    <BillingCountry>DE</BillingCountry>
  </Account>
  <!-- ... more Account elements, same shape ... -->
</Accounts>

⚠️ ** POSTMAN request and response for this tutorial's scenario. The exact
response shape returned for Mode = Salesforce Bulk hasn't been captured live yet for this
tutorial — add a real capture here once available, showing both the request and the response
body.

Figure 10: POSTMAN request and response for Salesforce Bulk mode .

A successful call confirms Salesforce accepted the batch for upload — not that any Account records exist yet. Salesforce still needs to run the Bulk job, and the adapter's own background process still needs to notice it finished, before the records are actually created or updated and a summary message appears in Salesforce. Always confirm the real outcome in **SAP CPI → Monitor Message Processing (§4.1) and Salesforce → Message Monitoring** (§4.2) rather than relying on the immediate response body — for this mode more than any other in this series, since completion can take noticeably longer than a normal request.

4. Monitoring

4.1 SAP CPI

Go to CPI → Monitor → Monitor Message Processing and verify the message completed successfully.

⚠️ ** CPI Monitor Message Processing.

Figure 11: CPI Monitor Message Processing.

4.2 Salesforce

Because this mode uses Salesforce's own Bulk API, the job also shows up on Salesforce's native Bulk Data Load Jobs page (Setup → Bulk Data Load Jobs) — this is a different place than the SKYVVA Bulk Control Board used by Skyvva Bulk mode. Once the job finishes there, check Salesforce → Message Monitoring to confirm the summary message and resulting Account records.

Note: If the interface's Bypass Message Layer setting is checked, no summary message is created in Salesforce at all for a fully successful run — leave it unchecked (the default) if you want this mode's runs to be visible in Message Monitoring.

⚠️ ** Salesforce Bulk Data Load Jobs page showing the job, and Message
Monitoring showing the processed message.

Figure 12: Salesforce Bulk Data Load Jobs and Message Monitoring .

After confirming the message, verify that the Account records were created or updated successfully.

Summary

The complete integration flow is:

POSTMAN
   ↓
HTTPS Sender
   ↓
SAP CPI Integration Flow
   ↓
SkyvvaSalesforce Receiver (Mode = Salesforce Bulk)
   ↓
SKYVVA Inbound Interface
   ↓
Salesforce Bulk API job (batched automatically)
   ↓
Background job checker confirms completion
   ↓
Salesforce Account records + a summary message

Configuration Summary