Salesforce Pub/Sub Adapter for SAP Integration Suite: What It Means for Your Business and Your Developers

Quick answer: The Salesforce Pub/Sub Adapter for SAP Integration Suite is a standard, ready-to-use connector that lets SAP Integration Suite publish and subscribe to Salesforce events in real time over a modern, high-performance gRPC channel. In plain terms, it lets Salesforce and SAP talk to each other the moment something happens, whether that is a new order, an updated account, or a service case, instead of waiting on scheduled batch jobs. It ships with enterprise-grade OAuth 2.0 security and event-replay reliability, and it works across Apache Camel 2, Apache Camel 3, and the Edge Integration Cell runtime.

If your organization runs both Salesforce and SAP, this release closes one of the most common gaps in the enterprise stack: keeping your CRM and your back-office systems in sync, instantly. Below, we break the update down twice. First for business and operations leaders, then for the technical teams who will actually build with it.

Why this release matters now

For years, connecting Salesforce to SAP meant stitching together polling jobs, middleware workarounds, or the older CometD-based Streaming API. Those approaches worked, but they were slow to set up, fragile to maintain, and rarely real-time.

Salesforce’s Pub/Sub API changed the foundation. It is built on gRPC and HTTP/2, delivers compact binary event messages in Apache Avro format, and is the streaming path Salesforce is now actively investing in. It is a single interface for three jobs that used to require separate APIs: publishing events, subscribing to events, and retrieving event schemas.

The new adapter brings that modern foundation directly into SAP Integration Suite as a native, supported component. There is no custom gRPC client to hand-build and no bespoke authentication plumbing. You configure it, deploy it, and your integration flows can react to Salesforce events as they happen.

Part 1: For Business and Operations Leaders

This section is written for decision-makers who care less about protocols and more about outcomes: faster operations, fewer errors, lower integration cost, and a better customer experience.

The business problem this solves

Most companies running Salesforce and SAP have the same quiet inefficiency. The two systems hold overlapping data, but they update on different schedules. A sale closes in Salesforce, but the order does not reach SAP until the nightly sync. Inventory changes in SAP, but sales reps do not see it until the next morning. Customers feel the lag, finance reconciles by hand, and your teams build manual workarounds to bridge the gap.

Real-time, event-driven integration removes that lag. The moment a record changes in Salesforce, the relevant system downstream knows about it and can act.

What you can actually do with it

Here are practical scenarios this adapter unlocks, mapped to business value rather than technical features:

• Order-to-cash acceleration. When an opportunity closes or an order is created in Salesforce, the event flows straight into SAP for fulfillment and invoicing, with no overnight wait and no re-keying.
• Live inventory and pricing. Subscribe to Salesforce events and push back updates so reps and customers always see accurate, current information.
• Master data consistency. Use Salesforce Change Data Capture events so account, contact, and customer changes are mirrored across systems automatically, reducing duplicate and stale records.
• Operational alerts. React to platform events the instant they occur, such as a payment exception, a service escalation, or a high-priority case, and route them to the right back-office process.
• Audit and compliance signals. Capture real-time monitoring events to feed governance, security, and reporting workflows.

The bottom-line benefits

• Faster operations. Real-time event flow replaces batch delays, compressing cycle times across order processing, service, and finance.
• Lower total cost of ownership. Because it is a standard adapter delivered with SAP Integration Suite, you avoid the cost and risk of building and maintaining custom integration code.
• Built-in reliability. The adapter can replay missed events after an outage, so a dropped connection does not mean lost data. That is a critical safeguard for revenue-bearing processes.
• Enterprise-grade security. It supports multiple OAuth 2.0 authentication methods, keeping credentials managed in SAP’s secure stores rather than scattered through code.
• Future-ready. It is built on the streaming foundation Salesforce is investing in going forward, so you are aligning with the platform’s direction, not its legacy.

What to consider before you commit

A few honest planning points worth raising with your team:

• It is an integration enabler, not a finished integration. The adapter is the pipe. Your specific business flows still need to be designed, built, and tested by an experienced integration team.
• Licensing and prerequisites. The adapter is positioned as part of the standard SAP Integration Suite entitlement, but you should confirm your tenant’s licensing and runtime profile before scoping a project.
• Event design discipline. Event-driven architectures reward good design and punish sloppy ones. Deciding which events matter, how to handle duplicates, and how to recover from failures is where experienced guidance pays for itself.

For business leaders, the takeaway is simple. If Salesforce and SAP both run your business, this adapter is the most direct, lowest-friction way yet to make them work in real time, and the project is usually measured in weeks, not quarters, with the right partner.

Part 2: For Developers and Integration Architects

This section goes under the hood: architecture, authentication, configuration, replay strategy, and the operational details that matter when you are actually building.

How the adapter works: sender vs. receiver

The adapter operates in two distinct roles, and understanding the direction of initiation is the key mental model.

The sender adapter is used to subscribe to a Salesforce channel and consume events. Here, Salesforce is the initiator. Events arrive and flow into your integration process, for example into a Content Modifier and onward. This is your inbound, event-listening pattern.

The receiver adapter is used to publish events to a Salesforce channel and to retrieve event schemas. Here, SAP Integration Suite is the initiator, typically driven by a timer or an upstream step, then making an outbound call (commonly via a Request-Reply step) to Salesforce.

A single integration package can use both roles depending on whether you are reacting to Salesforce or pushing into it.

Connection essentials

The connection is established toward the Salesforce Pub/Sub gRPC endpoint. The defaults you will work with:

• Host: api.pubsub.salesforce.com
• Port: 7443
• Tenant ID: your Salesforce Organization ID
• Connection check interval: a configurable value (in milliseconds) that validates the gRPC connection’s health

Because the transport is gRPC over HTTP/2, this is not a typical REST call. It is a persistent, binary, bidirectional channel, which is exactly what makes it fast and efficient.

Authentication: three OAuth 2.0 options

The adapter supports three mechanisms, all leaning on SAP Cloud Integration’s security artifacts (User Credentials, Secure Parameters, and the Keystore) so secrets never live in your flow logic. Choose based on your security posture and operational model.

1. OAuth 2.0 Username-Password. The most straightforward to stand up. You store the Salesforce username and password as User Credentials and the Consumer Key and Consumer Secret pair as a separate credential. A Security Token (stored as a Secure Parameter) is required unless your SAP Integration Suite IP range is whitelisted in Salesforce. Quick to configure, but generally the least preferred for production hardening.
2. OAuth 2.0 JWT Bearer. The strongest choice for unattended, server-to-server integrations. Instead of a password, the adapter signs a JWT assertion with a key pair held in the SAP Keystore. You will configure an Audience (login endpoint), a Subject Alias (the Salesforce username), an Issuer Alias (the connected app’s client ID), the Keystore Alias, and an assertion expiration. This is the pattern most enterprise teams should default to.
3. OAuth 2.0 Client Credentials. Uses a deployed OAuth2 Client Credentials artifact built from a Client ID and Client Secret, with the Salesforce token endpoint as the token service URL. Clean and modern where your org supports it via an external client app.

A practical tip: match every alias name in the adapter to the exact name of the deployed security artifact in SAP’s secure stores. Mismatched aliases are the single most common cause of authentication failures here.

Setting up JWT Bearer (the short version)

For the JWT flow you will create a connected app in Salesforce with OAuth enabled and digital signatures turned on, then generate a key pair and certificate. The typical OpenSSL sequence:

1. Generate a private key (server.key).
2. Create a certificate signing request (server.csr).
3. Produce a self-signed certificate (server.crt), which is what you upload to the Salesforce connected app.
4. Package the key and certificate into a Java KeyStore (.jks) and add it to the SAP Keystore as a Key Pair with a known alias.

On the Salesforce side, set the connected app’s OAuth policy so permitted users are admin-approved and pre-authorized, and assign the appropriate profile (for example, System Administrator) or permission set.

Subscribing: replay strategy is everything

When you subscribe, the Replay ID approach decides where in the event stream you start. This is the most important reliability decision you will make, so choose deliberately:

• Latest. Start from the newest message and ignore anything already stored. Use when you only care about new events going forward.
• Custom. Start from a specific replay ID, namely the last event you successfully processed. Use to resume cleanly after a connection drop without missing or double-processing events.
• Earliest. Start from the oldest available stored event. Use to backfill or recover after a longer outage. Note that Salesforce’s event retention window is finite (high-volume platform and change events are stored for roughly 72 hours), so Earliest only reaches as far back as retention allows.

A few more processing settings deserve attention:

• Replay Preset for Invalid Replay ID is the fallback when a stored replay ID is corrupted or expired (you will see a replayid.corrupted error). It defaults to Earliest, which favors completeness. Switch to Latest if avoiding reprocessing matters more than catching up.
• Request Batch Size controls how many events are requested per fetch. The effective maximum is 100, and larger values are treated as 100. The adapter automatically requests the next batch after consuming the current one.
• Duplicate Check Expiration controls how long the adapter remembers processed events to guard against duplicates (default 3,600,000 ms, which is one hour).
• Process Errors as an Event, when enabled, writes connection and stream errors into the message exchange so your flow can handle them explicitly. When disabled, they only hit the logs.

One performance note for the sender: keep your integration flow’s execution time short. If downstream processing is heavy, decouple it, for example by handing off to an asynchronous step, so you do not hold up the event stream.

Publishing and schema retrieval

The receiver adapter exposes two operations.

Get Schema retrieves the Avro schema for a channel. Because schemas are immutable per schema ID and only change when you alter the event definition, the smart pattern is to fetch a schema once and cache it. Calling Get Schema on every event is a common, avoidable performance drain.

Publish sends events to a channel. You specify the case-sensitive channel name and provide a payload that matches the event’s schema (typed fields, including the familiar Avro union shape such as {“string”: “value”} for nullable fields). Channel names are case-sensitive throughout the adapter, which is a frequent source of silent failures, so double-check them.

A pragmatic build checklist

• Confirm runtime profile and licensing on your tenant before you start.
• Deploy security artifacts first, and name aliases to match exactly.
• Default to JWT Bearer for production server-to-server flows.
• Decide your replay strategy per channel and do not accept defaults blindly.
• Cache schemas, and never call Get Schema in a hot path.
• Watch channel-name casing on every operation.
• Enable “Process Errors as an Event” where you need resilient, explicit error handling.
• Load-test with realistic batch sizes and decouple slow downstream logic.