6. How to create an inbound interface using Skyvva Bulk mode with SkyvvaSalesforce Adapter

Overview

This document explains how to create a SKYVVA Inbound Interface in Salesforce that processes high-volume record sets through Skyvva Bulk mode — the SkyvvaSalesforce receiver channel's Mode = Skyvva Bulk setting, which routes the incoming payload into SKYVVA's own in-memory basket/bulk engine (Bulk_Version__c = SKYVVA Bulk 1.0). That engine still uses the real Salesforce Bulk API under the hood, but only as a transport step to upload the data — not to write the target object directly.

It covers the following steps:

1. Create and configure a SKYVVA Inbound Interface in Salesforce, with the Bulk engine and package-size fields set for Skyvva 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 = Skyvva Bulk.
5. Deploy the integration flow.
6. Send a test request with a large record set from Postman through SAP CPI.
7. Monitor the message in SAP CPI.
8. Verify the bulk-processed records in Salesforce.

Context Before You Start

In short: Skyvva Bulk mode collects incoming records into an in-memory basket(BulkIntegrationV3Event / BulkTransformationHandlerV3) that is flushed to Salesforce once it reaches the interface's configured Bulk_Package_Size__c, rather than processing the request inline. Under the hood it does use the real Salesforce Bulk API — but only to upload the batched records as a zipped ContentVersion attachment, not to write the target object directly (that direct-to-target-object approach is the separate Salesforce Bulk mode); SKYVVA's own basket-processing engine then turns that upload into the actual Account/Contact records.

Reasons to pick this path:

• The source system sends large record sets in a single call (or a burst of calls) and processing them one-by-one inline, or even via a normal Skyvva Batch, would be slower or hit governor limits.
• You want SKYVVA's own bulk mapping/workflow engine to own the record set, not a Salesforce Bulk API job against the target object itself — SKYVVA's engine does drive its own Bulk API job in the background (a ContentVersion insert carrying the batched records as a zipped attachment), which does show up on the native Bulk Data Load Jobs page, but it's the interface's own basket-processing engine (the Bulk Control Board, see Salesforce monitoring below) that actually turns the upload into Account/Contact records.

• High-volume inbound loads where the sender can push several thousand records per call and the caller doesn't need a per-record synchronous result.
• Cases where Salesforce Bulk mode's real Bulk API job/polling overhead (CheckSFProcessingJob) is not needed or not desired.

Note: Skyvva Bulk is one of two bulk-capable values on the receiver channel's Mode field — the other is Salesforce Bulk, which drives the real Salesforce Bulk API V1/V2 and a background job-polling loop instead of SKYVVA's own basket mechanism. They are not interchangeable; pick Skyvva Bulk specifically when you want SKYVVA's own engine, not Salesforce's Bulk API.

POSTMAN
   ↓
SAP CPI (HTTPS Sender → SkyvvaSalesforce Receiver, Mode = Skyvva Bulk)
   ↓
SKYVVA Inbound Interface (Bulk_Version__c blank → SKYVVA Bulk 1.0)
   ↓
In-memory Bulk Basket (flushed at Bulk_Package_Size__c)
   ↓
Salesforce Account / Contact

Figure 1: End-to-end message flow using Skyvva Bulk mode.

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 — it's what the Integration lookup below, and the CPI receiver channel's Skyvva tab Integration field in §2.3.2, both point back to).

For this example, create the interface AccountContactSkyvvaBulk_IN. **Leave the Message Type field blank.** For a V3 Inbound interface, leaving Message Type unset is what triggers Hierarchical Mapping — there is no MetaData Provider/Repository/Message Type hierarchy to build first; the Mapping Tool derives the parent/child tree directly from Salesforce's own schema instead.

Configure the interface:

This is the main interface's own Inbound Setup section — with External Mapping enabled, set Salesforce External ID = skyvvasolutions__ERP_DEBTOR_ID__c, the Account-level external key used to match/upsert Account records:

Figure 3: Main interface AccountContactSkyvvaBulk_IN — Inbound Setup, External Mapping enabled with Salesforce External ID skyvvasolutions__ERP_DEBTOR_ID__c (Account).

1.2 Map Account → Contact in the Hierarchical Mapping Tool

Open the interface's Mapping Tool (Interface detail page → Open Mapping). Because MessageType is blank on a V3 Inbound interface, the Source tree is built live from the Account object's own schema rather than from a predefined Message Type — including its child relationships. Expand the tree down to the Contact(AccountId) child-relationship node to reach it.

With External Mapping enabled on the interface (§1.1), field-level mapping is not needed — External Mapping auto-maps fields by name on its own. All this step has to do is drag the two relationship nodes, top-down, to generate the chained sub-interface:

1. Drag the Account root node onto the target Account root first. This is required, not optional — the target tree doesn't display a Contact(AccountId) node at all until Account itself has been mapped. Expanding the target Account node beforehand shows only Account's other child relationship nodes (no individual fields are ever listed here — with External Mapping enabled, the tree doesn't expose fields for manual dragging at all), never Contact(AccountId), so there is nothing to drag the child relationship onto until the root mapping is done.
2. Expand Contact(AccountId) and drag it onto the target Contact(AccountId) node. No individual field needs to be dragged in either step — this is a node-to-node mapping, not a field-to-field one.

Important — this step is not optional and cannot be replaced by External Mapping alone. Dragging the Contact(AccountId) node auto-creates a chained sub-interface behind the scenes(internal, engine-managed — you don't create or configure it yourself), and that's the actual mechanism that makes the Account+Contact hierarchy work at runtime. External Mapping only flat-maps fields on an interface that already exists; it doesn't create this chained structure or walk into child relationships on its own. Skip this step, and posting nested Contact data will not produce Contact records, no matter how the payload is shaped.

Figure 4: Hierarchical Mapping Tool — Account → Contact(AccountId) node mapping, External Mapping handles field-level mapping.

Save the mapping. Doing so auto-generates the chained sub-interface for the child Contact object mentioned in the note above. That sub-interface has its own, separate Inbound Setup, with its own External Mapping keyed on the Contact-level external ID — skyvvasolutions__ERP_CONTACT_ID__c, not the Account-level ERP_DEBTOR_ID__c used on the main interface (§1.1). Don't confuse the two: they identify different objects, and the sub-interface's External Mapping has to be checked here independently — it is not inherited from the main interface just because External Mapping is enabled there.

Figure 5: Auto-generated sub-interface (Contact) — Inbound Setup, External Mapping enabled with Salesforce External ID skyvvasolutions__ERP_CONTACT_ID__c (Contact).

1.3 Configure the Bulk Engine

In the Bulk Setting / Basket Setting section of the interface, set the fields that control the Skyvva Bulk engine specifically:

Important: Bulk_Version__c defaults to SKYVVA Bulk 1.0 if left blank, and that default
behaves identically to setting it explicitly — leaving it blank (as this tutorial does) is the
simpler choice. Set it explicitly only if this interface is also used directly/Salesforce-natively
outside this CPI channel and you want its intent documented on the record itself. isBULKAPI__c
does not default to checked — leaving it off doesn't break Skyvva Bulk processing itself, but
it does hide the interface from the Bulk Control Board and Bulk Log view described in Salesforce
monitoring below. Note that when this interface is actually driven via a CPI
channel with Mode = Skyvva Bulk (as this tutorial sets up), the adapter overrides
Bulk_Version__c/isBULKAPI__c in memory at request time to match the channel's Mode setting
regardless of what's stored on the record — so setting these two fields here mainly documents
intent and keeps direct/Salesforce-native use of the interface consistent, rather than being
load-bearing for calls that arrive through this CPI channel.

Figure 6: Interface Bulk Setting — Bulk Version and Bulk Package Size.

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 7: Integration flow for the Skyvva Bulk mode example.

Important: the Message Mapping step in Figure 7 shows 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's not about incomplete field mapping, and it doesn't block deployment: this exact flow deploys and runs successfully (Figure 10) 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 (Bulk is just a processing tier of the same Integrate endpoint, not a separate schema). 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.

Note: this interface uses External Mapping with Message Type left blank, so the exported
schema comes from a live object describe rather than a curated tree — confirm it reflects the
nested Account → Contact structure before relying on it.

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 8: 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 Skyvva Bulk.

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

2.3.3 Skyvva Tab — Adapter Settings

Figure 10: 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.

Figure 11: 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 containing enough Account/Contact records to exercise the bulk basket — a handful of records is enough to prove the flow works, but the basket-flush behavior described in Context Before You Start only becomes visible once the record count approaches or exceeds the interface's Bulk_Package_Size__c.

Create a new request with the following configuration:

Request Format = XML

configure the header as:

Content-Type: application/xml

Because this interface's hierarchical shape (Account with nested Contact records, external IDs skyvvasolutions__ERP_DEBTOR_ID__c/skyvvasolutions__ERP_CONTACT_ID__c) is the same shape used in Tutorial 11's Auto-Switch example,the same sample payload works here too — the only difference is which interface it's addressed to, which is resolved on the CPI side via the receiver channel's Interface field (§2.3.2), not from anything in the body itself:

<?xml version="1.0" encoding="UTF-8"?>
<Accounts>
  <Account>
    <skyvvasolutions__ERP_DEBTOR_ID__c>ACC-000001</skyvvasolutions__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>
    <Contact>
      <skyvvasolutions__ERP_CONTACT_ID__c>ACC-000001-C01</skyvvasolutions__ERP_CONTACT_ID__c>
      <FirstName>Max</FirstName>
      <LastName>Mueller</LastName>
      <Email>max.mueller.1.1@example.com</Email>
      <Phone>+49-89-2719583</Phone>
    </Contact>
    <!-- ... more Contact elements for this Account ... -->
  </Account>
  <!-- ... more Account elements, same shape — enough of them to approach or exceed
       Bulk_Package_Size__c so the basket-flush behavior above actually triggers ... -->
</Accounts>

Figure 12: POSTMAN request and response.

4. Monitoring

4.1 SAP CPI

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

Figure 13: CPI Monitor Message Processing.

4.2 Salesforce

Go to Salesforce → Message Monitoring to confirm the message and resulting Account/Contact records.

Because this interface uses Bulk_Version__c = SKYVVA Bulk 1.0 (not an SFDC Bulk API version),it will also appear in the SKYVVA Bulk Control Board — provided isBULKAPI__c is also enabled on the interface, since the view's visibility filter requires both isBULKAPI__c = true and Bulk_Version__c starting with "SKYVVA Bulk" (or blank). Interfaces on SFDC Bulk API 1.0/2.0 are excluded from that view by the same filter. This is a different queue than Salesforce's own Bulk Data Load Jobs page — Skyvva Bulk does create a Salesforce Bulk API job in the background (see the Note under §1.3), but that job only uploads the data; the Bulk Control Board is where the interface's own basket-processing tracks turning it into actual Account/Contact records.

Figure 14: Bulk Control Board — Baskets tab, showing the interface's queued baskets before processing.

Summary

The complete integration flow is:

POSTMAN
   ↓
HTTPS Sender
   ↓
SAP CPI Integration Flow
   ↓
SkyvvaSalesforce Receiver (Mode = Skyvva Bulk)
   ↓
SKYVVA Inbound Interface (Bulk_Version__c blank → SKYVVA Bulk 1.0)
   ↓
In-memory Bulk Basket (flushed at Bulk_Package_Size__c)
   ↓
Salesforce Account / Contact

Configuration Summary

The basket-flush behavior is controlled entirely on the interface (Bulk_Package_Size__c) and is independent of the CPI channel's own settings — once Mode = Skyvva Bulk routes a request here, how it gets chunked into baskets is Salesforce-side configuration, not something adjusted from SAP CPI.