14. How to Push Account and Contact Data via V3 Create Message Only with the SkyvvaSalesforce Adapter

This document walks through building a complete integration flow that pushes Account and Contact data from Postman into Salesforce through SAP CPI, using the SkyvvaSalesforce Receiver's native V3 path with Processing Behavior = Create Message Only. Unlike a normal push, the record is only saved by this call — it is not acted on until someone continues it afterward.

This document is a full walkthrough — Salesforce Interface setup, the CPI iFlow, the endpoint URL, a real Postman test, and how to continue a waiting message.

In this example:

Context Before You Start

In short: this is a deliberately two-step push. The first step — this document's main flow — only records that data arrived; nothing in Salesforce changes yet. The second step, done later by a person, is what actually applies the change. In between, the record sits visibly in Salesforce as "waiting," not silently queued somewhere invisible. The realistic business shape this fits: submissions that come from a source you don't yet fully trust the same way you trust an established automated feed — e.g. a partner-onboarding form, a regional sales office's own ad hoc submissions, or any input path that isn't a vetted, established automated feed. Because these submissions can contain typos, duplicates, or genuinely bad data in a way an established system's feed usually doesn't, a data steward reviews each one before it's allowed to actually touch Salesforce.

Reasons to pick this path:

• The source of this data hasn't earned full automated trust yet — a new partner integration, a manually-operated intake form, or any path where bad input is a real, ongoing risk rather than a one-time concern to fix and move past.
• You want this to be an explicit, human-in-the-loop step by design — not a temporary training-wheels phase, but the actual intended long-term control for this particular data source.

• A partner-onboarding or self-service intake path, where submissions come from outside your own trusted systems and a person should sanity-check each one before it becomes a real Account/Contact.
• Any source where "looks plausible" isn't good enough on its own — duplicate accounts, malformed data, or a submission that shouldn't have been sent at all are realistic, recurring risks worth a human gate, not just an initial pilot-phase precaution.

How the Integration Flow Works

Postman
   ↓ (XML body, same DEBMAS06 IDoc test file as Tutorial 15 §7)
HTTPS Sender
   ↓
Message Mapping (§3.1) — transforms the DEBMAS06 IDoc shape into this interface's expected shape
   ↓
SkyvvaSalesforce Receiver  (V3, Asynchronous, Create Message Only)
   ↓
Salesforce Inbound Interface — record saved, Status = "New" (waiting, not yet acted on)
   ↓   (later, manually)
Someone opens the Integration's Monitor tab → selects the message → clicks Reprocess
   ↓
Salesforce Account / Contact — now actually created/updated

⚠️ [SCREENSHOT NEEDED] Integration flow canvas: HTTPS Sender through Message Mapping to a single SkyvvaSalesforce Receiver.

Figure 1: End-to-end flow — Postman through SAP CPI (via a Message Mapping step) to a waiting Salesforce record, continued later by hand (screenshot to be added).

2. Configure the Salesforce Inbound Interface

Create (or confirm) an Integration and an Inbound Interface under it, e.g. PartnerOnboarding / Account_CPI_CreateMessageOnly_IN:

⚠️ [SCREENSHOT NEEDED] SKYVVA Inbound Interface detail page, Direction=Inbound, Processing Mode=Asynchronous, Operation Type=Upsert.

Figure 2: Inbound Interface for the Create Message Only test (screenshot to be added).

With External Mapping enabled, no manual field-mapping step is needed — <Account> and its nested <Contact> resolve node to node, straight to the Account/Contact objects by matching element name to field API name. Verify this with the test in §9 — if Contacts don't link to the right Account, this mapping is the first place to check.

3. Create the SAP CPI Integration Flow

In SAP CPI, create an integration package and a new integration flow.

Example:

• HTTPS Sender Adapter
• Message Mapping (§3.1) — transforms the source XML into the shape this interface's External Mapping expects
• SkyvvaSalesforce Receiver Adapter

⚠️ [SCREENSHOT NEEDED] Integration flow canvas showing the HTTPS Sender through a Message Mapping step to the SkyvvaSalesforce Receiver.

Figure 3: Integration flow — HTTPS Sender through Message Mapping to SkyvvaSalesforce Receiver (screenshot to be added).

3.1 Message Mapping — Transform the DEBMAS06 IDoc Shape Into This Interface's Expected Shape

Add a Message Mapping step right after the HTTPS Sender. Open its editor (double-click it on the canvas):

• Source: click Select → Add, and upload DEBMAS06_Account_Contact.xsd from this repository — the same source schema as Tutorial 15 §3.1 (root DEBMAS06, repeating IDOC, each with E1KNA1M nesting repeating E1KNVKM).
• Target: click Select → Add, and upload an XSD exported directly from this tutorial's own interface. On the Account_CPI_CreateMessageOnly_IN interface record (§2) in Salesforce, click Generate MetaData, set Format = XSD Schema, API = V4/Integrate, then download the file and upload it here as the Target.

⚠️ [SCREENSHOT NEEDED] Message Mapping editor — Source built from DEBMAS06_Account_Contact.xsd, Target built from the Account_CPI_CreateMessageOnly_IN interface's exported (V4/Integrate) XSD, fields mapped between them.

Figure 3a: Message Mapping — DEBMAS06 IDoc shape mapped onto this interface's own exported target shape (screenshot to be added).

4. Configure the HTTPS Sender Channel

4.1 General

Configure Name/Direction as usual on the General tab.

⚠️ [SCREENSHOT NEEDED] HTTPS sender channel — General tab.

Figure 4: HTTPS sender channel — General tab (screenshot to be added).

4.2 Connection

On the Connection tab, set the Address the caller will POST to (this becomes part of the deployed endpoint URL) and the Authorization/User Role the caller's credential must carry.

⚠️ [SCREENSHOT NEEDED] HTTPS sender channel — Connection tab, with Address and User Role filled in.

Figure 5: HTTPS sender channel — Connection tab (screenshot to be added).

5. Configure the SkyvvaSalesforce Receiver Channel

5.1 Connection Tab

Configure Authentication Type OAuth2, OAuth2 Flow, Login URL, and Credential(s) — the connection is the same regardless of which Processing tab option you use.

⚠️ [SCREENSHOT NEEDED] SkyvvaSalesforce Receiver channel — Connection tab.

Figure 6: SkyvvaSalesforce Receiver channel — Connection tab (screenshot to be added).

5.2 Processing Tab

This is where this scenario's configuration matters most. Set:

⚠️ [SCREENSHOT NEEDED] Processing tab — Skyvva API Version=V3, Integration/Interface filled in, Mode=Asynchronous, Processing Behavior=Create Message Only visible and selected.

Figure 7: Processing tab configured for V3 Create Message Only (screenshot to be added).

5.3 Save and Deploy

Save and deploy the integration flow.

⚠️ [SCREENSHOT NEEDED] Integration flow deployed and started.

Figure 8: Integration flow deployed (screenshot to be added).

6. Get the SAP CPI Endpoint URL

Navigate to Monitoring > Manage Integration Content, locate the deployed flow, and copy its endpoint URL.

Important: Always copy the exact endpoint URL from your own tenant's Manage Integration Content panel rather than assembling it by hand — the exact hostname shape differs between Neo and Cloud Foundry tenants.

⚠️ [SCREENSHOT NEEDED] Manage Integration Content, showing the deployed flow's endpoint URL.

Figure 9: SAP CPI endpoint URL for the deployed flow (screenshot to be added).

7. Prepare the Test Payload

Native V3 with Request Format = XML takes an XML body. For this tutorial, reuse the same test file as Tutorial 15 §7 — the real SAP DEBMAS06 customer master IDoc extract, sample-idoc-account6000/DEBMAS_Accounts_6000x10.xml:

<?xml version="1.0" encoding="UTF-8"?>
<DEBMAS06>
  <IDOC BEGIN="1">
    <EDI_DC40 SEGMENT="1">
      <TABNAM>EDI_DC40</TABNAM>
      <MANDT>100</MANDT>
      <DOCNUM>0000000000100000</DOCNUM>
      <IDOCTYP>DEBMAS06</IDOCTYP>
      <MESTYP>DEBMAS</MESTYP>
      <!-- ...remaining EDI_DC40 control fields... -->
    </EDI_DC40>
    <E1KNA1M SEGMENT="1">
      <MSGFN>004</MSGFN>
      <KUNNR>0000006000</KUNNR>
      <NAME1>Global Tech Solutions 6000 GmbH</NAME1>
      <STRAS>Hauptstrasse 1</STRAS>
      <ORT01>Munich</ORT01>
      <PSTLZ>80000</PSTLZ>
      <LAND1>DE</LAND1>
      <REGIO>BY</REGIO>
      <TELF1>+49-89-1000000</TELF1>
      <TELFX>+49-89-2000000</TELFX>
      <BRSCH>Manufacturing</BRSCH>
      <UMSAT>1000000</UMSAT>
      <E1KNVKM SEGMENT="1">
        <PARNR>0001</PARNR>
        <NAMEV>First name</NAMEV>
        <NAME1>Last name</NAME1>
        <TELF1>+49-89-...</TELF1>
        <SMTP_ADDR>contact@example.com</SMTP_ADDR>
        <!-- ...remaining E1KNVKM contact fields... -->
      </E1KNVKM>
      <!-- ...9 more <E1KNVKM> blocks for this Account... -->
    </E1KNA1M>
  </IDOC>
  <!-- ...5,999 more <IDOC> blocks... -->
</DEBMAS06>

Same file, same source shape as Tutorial 15 — this is the Message Mapping step's Source (§3.1); it does not go to the Receiver channel as-is. Message Mapping transforms it into this interface's own expected shape (its exported V4/Integrate XSD) first, which is what actually reaches the SkyvvaSalesforce Receiver.

The adapter builds integration/interface/mode/request-format/response-format as URL query params from the channel fields configured in §5, and sends the mapped XML as the request body. Treat your first test run partly as verification of the Interface's node-to-node Account/Contact mapping, not just of the Create Message Only mechanism.

For a first test, sending a trimmed single-<IDOC> version of this file is enough — the full 6,000-record file (§7 in Tutorial 15) is more useful once this smaller test confirms the mapping and Create Message Only mechanism both work.

8. Send the Request from Postman

⚠️ [SCREENSHOT NEEDED] Postman request configured and sent against the CPI endpoint.

Figure 10: Postman sending the test payload (screenshot to be added).

9. Confirm the Record Is Waiting, Not Yet Acted On

9.1 SAP CPI Side

Monitor > Monitor Message Processing — confirm the message completed from CPI's perspective (CPI's job was just to deliver the create-only request, which it did).

⚠️ [SCREENSHOT NEEDED] Monitor Message Processing showing the message completed.

Figure 11: SAP CPI Monitor Message Processing — message delivered (screenshot to be added).

9.2 Salesforce Side

Navigate to the Integration's Monitor tab in Salesforce. The new message should appear with status New — saved, but not carried out. If you check the Account object directly, you should not yet see TestAccount-CMO-1 there — that's the expected, correct outcome at this point, not a failure.

⚠️ [SCREENSHOT NEEDED] Integration's Monitor tab showing the message with Status = New, and the Account object confirmed to not yet contain the test record.

Figure 12: Message waiting with Status=New; Account not yet created (screenshot to be added).

10. Continue the Waiting Message

On the Integration's Monitor tab, select the waiting message and click Reprocess.

⚠️ [SCREENSHOT NEEDED] Monitor tab, waiting message selected, Reprocess button highlighted.

Figure 13: Continuing the waiting message via Reprocess (screenshot to be added).

Confirm the Account (and its Contact) now exist in Salesforce, and that the message's status has moved to a terminal state (e.g. Completed).

⚠️ [SCREENSHOT NEEDED] The Account record now created, with its related Contact, and the message's status updated to Completed.

Figure 14: Account and Contact created after Reprocess; message status Completed (screenshot to be added).

11. Summary

The complete flow is:

Postman (DEBMAS06 IDoc XML) → HTTPS Sender → Message Mapping → SAP CPI → SkyvvaSalesforce Receiver (V3, Async, Create Message Only) → Salesforce (waiting) → manual Reprocess → Salesforce (done)

Key configuration:

A Note on Combining with Other Receiver Configurations

Create Message Only requires Skyvva API Version = V3 with Mode = Asynchronous — it is not available, and does not apply, when the channel's Skyvva API is set to V4/integrate (that option always calls Salesforce directly with no waiting state, regardless of any Processing Behavior setting). These are two different, mutually exclusive Processing tab configurations on the same Receiver channel — pick one per channel based on whether you actually need a human-reviewed waiting state (this document) or a direct, automatic push.