Understanding “Process Error as an Event” in the Salesforce Sender Adapter

Estimated read time 12 min read

Introduction

As an SAP Integration Suite (SAP CI) consultant, I regularly work with customers looking to connect their SAP landscape with third-party platforms, and Salesforce integrations come up often given how widely it’s used for managing customer relationships, sales processes, and service operations. Salesforce lets organizations store customer data, track interactions, automate workflows, and derive insights through powerful analytics – but making that data flow reliably into and out of SAP systems requires the right integration approach.

To simplify integration with Salesforce, SAP Integration Suite provides the Salesforce Sender Adapter, which is specifically engineered to support an important Salesforce capability known as Platform Events. The adapter enables the consumption of these events by subscribing to event channels and continuously listening for incoming messages. In this blog, we will focus on one specific and often misinterpreted feature of the Salesforce Sender Adapter “Process Error as an Event.” This feature is available for all supported Salesforce event types, including Platform Events, Change Data Capture (CDC), and PushTopic events.

What are Platform Events in Salesforce?
Platform Events in Salesforce enable communication between systems using an event-driven architecture. These events are published whenever significant actions or changes occur within the system. To consume these event streams, the Salesforce adapter provides a mechanism to subscribe to event channels and continuously monitor them in near real time.

Subscribing Mechanism of the Salesforce Sender Adapter
Platform Events in Salesforce follow a publish-subscribe model, where external systems like SAP Integration Suite consume events using the Salesforce Sender Adapter. The adapter leverages the CometD protocol to establish a long-lived HTTP connection with Salesforce, using long polling to avoid continuous requests. This mechanism allows the client to maintain an open connection held until new events are available.

Once configured, SAP CI internally manages the CometD session lifecycle, including subscription handling, connection persistence, and automatic reconnections. This ensures reliable and near real-time delivery of Platform Events, triggering the corresponding iFlow as soon as events are received.

However, this continuous connection also introduces an important consideration: what happens when something goes wrong, such as temporary or intermittent issues on the Salesforce server? Connectivity errors can occur, such as:

403: Unknown Client – Salesforce no longer recognizes the CometD client, which can happen due to session expiry, idle timeout, or Salesforce-side session invalidation.Session timeouts – the CometD session becomes invalid after a period of inactivity.Network interruptions – transient network issues between SAP CI and Salesforce.Salesforce maintenance or pod restarts – causing temporary unavailability of the event busToken or OAuth credential expiry – leading to authentication failures mid-subscription

It is important to highlight that the Salesforce Sender Adapter is designed to handle these connectivity errors gracefully. Upon encountering such an error, the adapter automatically resubscribes to the Platform Event channel without any manual intervention or delay, ensuring continuity of event consumption. By default, these failures are logged internally but are not surfaced in the Message Processing Log (MPL), since the adapter recovers on its own.

“Process Errors as an Event” – What It Really Means
In real-world scenarios, connectivity failures within the subscription lifecycle are inevitable. As described above, the adapter handles these internally. But what if you want to make these errors visible for monitoring or diagnostic purposes?

This is where the “Process Errors as an Event” feature becomes relevant. When this checkbox is enabled in the Salesforce Sender Adapter configuration, connectivity errors that occur during subscription — such as a 403: Unknown Client error — are captured and surfaced as messages in the SAP CI Message Processing Log (MPL).

Connectivity Error in Subscription: The 403: Unknown Client Scenario
A 403: Unknown Client error means that Salesforce no longer recognizes the CometD client. This can happen due to multiple reasons, including session expiry, a Salesforce platform restart, or idle connection timeout.

When this occurs, the adapter automatically resubscribes to the Platform Event channel. This recovery happens in the background without any disruption to the iFlow runtime. If you wish to see or manage these connectivity errors in MPL, you can enable the “Process Errors as an Event” checkbox. When enabled:

The connectivity error is captured as a message entry in MPLThe error can be routed to a dedicated error-handling iFlow for further action or alertingOperational teams gain visibility into transient errors that would otherwise be silent

Important: The presence of such an error in MPL does not mean that the subscription is inactive or that events are being missed. It simply indicates that a connectivity error occurred during subscription. The adapter internally recovers from this error by resubscribing to the Platform Event channel. The subscription remains active and event consumption continues.

When Should You Use It?
The general recommendation is to keep the “Process Errors as an Event” checkbox disabled by default, as the Salesforce Sender Adapter is designed to automatically recover from connectivity errors by resubscribing to the Platform Event channel. However, there are specific situations where enabling this feature provides clear value:

Troubleshooting connectivity issues: When recurring errors such as 403: Unknown Client or session timeouts are observed, enabling this feature makes them visible in MPL, helping to diagnose and confirm the root cause.
Validating adapter recovery behavior: If there is a need to confirm that the adapter is resubscribing correctly after a connectivity error, enabling this feature provides the necessary visibility into those recovery events.Custom error monitoring or alerting: When there is a requirement to route connectivity errors to a dedicated error-handling iFlow or an external monitoring system, this feature enables that by surfacing errors as MPL messages.
Operational awareness: When integration teams need to track the frequency of subscription interruptions for reporting or SLA purposes, this feature provides the data points needed.

Keep in mind that enabling this feature may generate a higher volume of MPL entries during periods of transient connectivity instability. These entries do not indicate that event consumption has stopped — they simply reflect that the adapter encountered and recovered from a connectivity error. Enable it only when there is a clear operational reason to monitor or act on these errors.

Final Takeaway
The “Process Errors as an Event” feature in the Salesforce Sender Adapter is a useful capability that requires thoughtful use. The Salesforce Sender Adapter is engineered to automatically recover from connectivity errors by resubscribing to the Platform Event channel — without any loss of events or manual intervention.

Enabling “Process Errors as an Event” simply makes them visible in MPL. When you see such an error in the MPL, it is not an indication that the subscription has stopped; it is a notification that a transient error occurred and the adapter has already recovered.

The real value of this feature lies in giving integration teams a window into adapter-level events that are otherwise silent. Enable it when there is a clear reason to monitor connectivity errors – whether for troubleshooting, validation, or operational alerting. In all other cases, the general recommendation is to leave it disabled and trust the adapter’s built-in resilience.

As every good integration consultant would advise not every internal error needs to become a visible event – but every important connectivity pattern should be understood.

 

​ IntroductionAs an SAP Integration Suite (SAP CI) consultant, I regularly work with customers looking to connect their SAP landscape with third-party platforms, and Salesforce integrations come up often given how widely it’s used for managing customer relationships, sales processes, and service operations. Salesforce lets organizations store customer data, track interactions, automate workflows, and derive insights through powerful analytics – but making that data flow reliably into and out of SAP systems requires the right integration approach.To simplify integration with Salesforce, SAP Integration Suite provides the Salesforce Sender Adapter, which is specifically engineered to support an important Salesforce capability known as Platform Events. The adapter enables the consumption of these events by subscribing to event channels and continuously listening for incoming messages. In this blog, we will focus on one specific and often misinterpreted feature of the Salesforce Sender Adapter “Process Error as an Event.” This feature is available for all supported Salesforce event types, including Platform Events, Change Data Capture (CDC), and PushTopic events.What are Platform Events in Salesforce?Platform Events in Salesforce enable communication between systems using an event-driven architecture. These events are published whenever significant actions or changes occur within the system. To consume these event streams, the Salesforce adapter provides a mechanism to subscribe to event channels and continuously monitor them in near real time.Subscribing Mechanism of the Salesforce Sender AdapterPlatform Events in Salesforce follow a publish-subscribe model, where external systems like SAP Integration Suite consume events using the Salesforce Sender Adapter. The adapter leverages the CometD protocol to establish a long-lived HTTP connection with Salesforce, using long polling to avoid continuous requests. This mechanism allows the client to maintain an open connection held until new events are available.Once configured, SAP CI internally manages the CometD session lifecycle, including subscription handling, connection persistence, and automatic reconnections. This ensures reliable and near real-time delivery of Platform Events, triggering the corresponding iFlow as soon as events are received.However, this continuous connection also introduces an important consideration: what happens when something goes wrong, such as temporary or intermittent issues on the Salesforce server? Connectivity errors can occur, such as:403: Unknown Client – Salesforce no longer recognizes the CometD client, which can happen due to session expiry, idle timeout, or Salesforce-side session invalidation.Session timeouts – the CometD session becomes invalid after a period of inactivity.Network interruptions – transient network issues between SAP CI and Salesforce.Salesforce maintenance or pod restarts – causing temporary unavailability of the event busToken or OAuth credential expiry – leading to authentication failures mid-subscriptionIt is important to highlight that the Salesforce Sender Adapter is designed to handle these connectivity errors gracefully. Upon encountering such an error, the adapter automatically resubscribes to the Platform Event channel without any manual intervention or delay, ensuring continuity of event consumption. By default, these failures are logged internally but are not surfaced in the Message Processing Log (MPL), since the adapter recovers on its own.“Process Errors as an Event” – What It Really MeansIn real-world scenarios, connectivity failures within the subscription lifecycle are inevitable. As described above, the adapter handles these internally. But what if you want to make these errors visible for monitoring or diagnostic purposes?This is where the “Process Errors as an Event” feature becomes relevant. When this checkbox is enabled in the Salesforce Sender Adapter configuration, connectivity errors that occur during subscription — such as a 403: Unknown Client error — are captured and surfaced as messages in the SAP CI Message Processing Log (MPL).Connectivity Error in Subscription: The 403: Unknown Client ScenarioA 403: Unknown Client error means that Salesforce no longer recognizes the CometD client. This can happen due to multiple reasons, including session expiry, a Salesforce platform restart, or idle connection timeout.When this occurs, the adapter automatically resubscribes to the Platform Event channel. This recovery happens in the background without any disruption to the iFlow runtime. If you wish to see or manage these connectivity errors in MPL, you can enable the “Process Errors as an Event” checkbox. When enabled:The connectivity error is captured as a message entry in MPLThe error can be routed to a dedicated error-handling iFlow for further action or alertingOperational teams gain visibility into transient errors that would otherwise be silentImportant: The presence of such an error in MPL does not mean that the subscription is inactive or that events are being missed. It simply indicates that a connectivity error occurred during subscription. The adapter internally recovers from this error by resubscribing to the Platform Event channel. The subscription remains active and event consumption continues.When Should You Use It?The general recommendation is to keep the “Process Errors as an Event” checkbox disabled by default, as the Salesforce Sender Adapter is designed to automatically recover from connectivity errors by resubscribing to the Platform Event channel. However, there are specific situations where enabling this feature provides clear value:Troubleshooting connectivity issues: When recurring errors such as 403: Unknown Client or session timeouts are observed, enabling this feature makes them visible in MPL, helping to diagnose and confirm the root cause.Validating adapter recovery behavior: If there is a need to confirm that the adapter is resubscribing correctly after a connectivity error, enabling this feature provides the necessary visibility into those recovery events.Custom error monitoring or alerting: When there is a requirement to route connectivity errors to a dedicated error-handling iFlow or an external monitoring system, this feature enables that by surfacing errors as MPL messages.Operational awareness: When integration teams need to track the frequency of subscription interruptions for reporting or SLA purposes, this feature provides the data points needed.Keep in mind that enabling this feature may generate a higher volume of MPL entries during periods of transient connectivity instability. These entries do not indicate that event consumption has stopped — they simply reflect that the adapter encountered and recovered from a connectivity error. Enable it only when there is a clear operational reason to monitor or act on these errors.Final TakeawayThe “Process Errors as an Event” feature in the Salesforce Sender Adapter is a useful capability that requires thoughtful use. The Salesforce Sender Adapter is engineered to automatically recover from connectivity errors by resubscribing to the Platform Event channel — without any loss of events or manual intervention.Enabling “Process Errors as an Event” simply makes them visible in MPL. When you see such an error in the MPL, it is not an indication that the subscription has stopped; it is a notification that a transient error occurred and the adapter has already recovered.The real value of this feature lies in giving integration teams a window into adapter-level events that are otherwise silent. Enable it when there is a clear reason to monitor connectivity errors – whether for troubleshooting, validation, or operational alerting. In all other cases, the general recommendation is to leave it disabled and trust the adapter’s built-in resilience.As every good integration consultant would advise not every internal error needs to become a visible event – but every important connectivity pattern should be understood.   Read More Technology Blog Posts by Members articles 

#SAP

#SAPTechnologyblog

You May Also Like

More From Author