Open Connectors: Architecture and Use

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 10, 2026 · 16 min read

Where This Article Sits#

References#

1) The Open Connectors Landscape#

Open Connectors is the SaaS-reach capability of SAP Integration Suite. Where Cloud Integration handles process orchestration and API Management handles API exposure, Open Connectors handles the specific job of talking to third-party cloud applications — Salesforce, ServiceNow, NetSuite, QuickBooks, Eloqua, Marketo, and similar — through a normalized REST API instead of the vendor’s own SDK or REST quirks.

They are not substitutes.

2) How It Connects to S/4HANA#

   Third-party SaaS (Salesforce, ServiceNow, NetSuite, ...)
            ▲
            │ vendor REST/SOAP (varies per vendor)
            │
   ┌────────┴───────────────────────────┐
   │  Open Connectors (BTP)             │
   │   ├─ Connector (prebuilt/custom)   │  Auth: OAuth 2.0 / API key / Basic
   │   ├─ Hooks (JavaScript pre/post)   │  Override request/response behavior
   │   ├─ Transformation                │  Vendor schema → Common Resource
   │   ├─ Bulk / Events                 │  Async + webhook patterns
   │   └─ Connector Instance            │  Authenticated tenant config
   └────────┬───────────────────────────┘
            │ Normalized REST API (Open Connectors endpoint URL)
            ▼
   ┌─────────────────────────────────────┐
   │  Cloud Integration  ──  API Management  │
   │           │                              │
   │      iFlow HTTP receiver / API proxy     │
   └───────────┬──────────────────────────────┘
               │ IDoc / OData / RFC / SOAP
               ▼
        S/4HANA (on-prem or Cloud)

Key point: Open Connectors does not talk to S/4HANA directly. It sits at the SaaS edge of the Integration Suite, normalizes third-party APIs, and hands off to Cloud Integration (most common) or API Management for the trip into the SAP estate. Architecturally, treat Open Connectors as a specialized REST normalization layer in front of SaaS — not a substitute for an iFlow.

3) Maturity Map#

4) Requirements Checklist#

Tenant and contract prerequisites#

SaaS coverage and connector selection#

Authentication and secrets#

Customization (Common Resources, Hooks, Formulas)#

Observability and operations#

Licensing and sizing#

5) Decision Criteria#

The three questions to ask first#

Q1. What measurable inefficiency does Open Connectors solve, and how is it counted?

Not “we want to integrate with Salesforce.” That is a wish, not a requirement. The defensible form is: “Sales operations re-keys 300 opportunity updates per week from Salesforce into S/4HANA Sales Order; the cycle time is 2 days; we want it under 1 hour with no re-keying.” Without that quantification you cannot tell whether Open Connectors, a Cloud Integration iFlow, or no integration at all is the right answer.

Q2. Where does the data live, and who owns it during the integration?

Open Connectors holds connector-instance credentials and routes data through SAP-managed infrastructure. For regulated data (PII, financial, healthcare), confirm with security and legal that the BTP region of the Integration Suite tenant is acceptable, that audit trails on the SaaS side are sufficient, and that the customer — not SAP — is the controller of record. Do this before architecture, not after.

Q3. Who is the internal sponsor with both budget and operational authority?

A SaaS integration that lives in Integration Suite needs an owner who is accountable for vendor coordination, message-volume budget, and the inevitable connector update when the vendor changes its API. If no single person can sign for all three, the integration will drift. Name the sponsor in the requirements document.

Domain selection by project context#

Licensing and cost#

6) Common Failures#

Failure 1: Coverage assumption — “the catalog has 160+, ours must be in there”

The catalog covers the mainstream SaaS economy but not the long tail. Vertical-specific tools (industry-specific HR, niche e-commerce, regional payment processors) are often absent. The fix is a catalog check at requirements stage — open the connector catalog and confirm by name, not by category. If the vendor isn’t there, the requirement routes to Cloud Integration with an HTTP adapter or to Connector Builder, and the project plan needs that decision before architecture.

Failure 2: Observability gap underestimated

Teams that have run Cloud Integration in production assume the same Message Processing Log will be available for Open Connectors calls. It is not. Step-value logging is capped at 4 MB and can drop silently. Production troubleshooting depends on custom logging that someone has to design, build, and maintain. The fix is to scope observability work explicitly during requirements — not to discover the gap during the first incident.

Failure 3: Connector lifecycle drift

Vendor SaaS APIs change. The Open Connectors connector follows on SAP’s schedule, not the project’s. A Salesforce major release, a ServiceNow upgrade, or a vendor’s deprecation notice can break a production connector for weeks. The fix is two-sided: subscribe to vendor release notes and budget a small reserve of integration time per quarter for connector adaptation. Treating connectors as “set it and forget it” is the failure.

Failure 4: Common Resources skipped on integration #2

The architectural payoff of Open Connectors is the one-to-many pattern: one Common Resource (e.g., “Lead”) mapped to multiple SaaS systems. Teams that integrate the first SaaS without defining a Common Resource end up rebuilding when the second SaaS arrives — and second-SaaS work always arrives. The fix is to design Common Resources before the first connector goes live, even if only one connector exists today.

Failure 5: Cost surprise from shared message metric

Open Connectors API calls and Cloud Integration messages share the same Integration Suite metric. A team that budgets capacity units for “iFlows” and forgets Open Connectors discovers the gap at year-two renewal. The fix is to model all Integration Suite consumption — iFlows, API proxies, Open Connectors calls, Event Mesh — in one capacity-unit projection. Per-capability budgets are an illusion.

Failure 6: Lifecycle uncertainty ignored in long-horizon plans

Open Connectors is not deprecated, but SAP’s investment cadence here is visibly slower than in Cloud Integration or API Management. Strategic five-year plans built around heavy Open Connectors customization (many custom connectors, deep Common Resources, complex Formulas) carry a lifecycle risk that should be documented. The fix is not to avoid Open Connectors — it is to keep customization disciplined and have a written contingency for the case where SAP’s strategy shifts.

Failure 7: Hook complexity exceeds the runtime envelope

Pre-request and post-response hooks are powerful and tempting. Teams add transformation logic, enrichment lookups, and error-handling chains until the hook hits the 5 MB payload or 29 s execution cap. The fix is to keep hooks small and route heavyweight logic to Cloud Integration. If a hook is doing work that “looks like an iFlow,” it should be one.

FAQ#

Q: Is Open Connectors deprecated or going away?

No, not as of 2025/2026. The service continues to be listed in SAP Integration Suite monthly updates, no end-of-life announcement has been made, and customers are actively onboarded. What is true is that SAP’s investment cadence on Open Connectors is visibly slower than on Cloud Integration or API Management, and SAP has selectively removed individual connectors from the eligible list (KBA 3170197). Treat Open Connectors as a stable, lower-velocity capability — not as a frontier product to bet on for five-year plans.

Q: How many connectors are there really? I’ve seen “400+” quoted.

SAP-official sources (the BTP use case page, the Help Portal) state 160+ prebuilt connectors. The “400+” figure circulates in marketing-adjacent material and may include hub variations, deprecated entries, or community-built connectors. For requirements documents and project communications, use the SAP-official 160+ number and verify the specific vendor by name in the catalog rather than relying on any aggregate.

Q: When should we not use Open Connectors even if the connector exists?

Three cases. First, when payload routinely exceeds 8 MB or processing time exceeds 29 seconds — the platform caps will block production. Second, when full Cloud Integration observability (Message Processing Log, mapping debugger, replay) is required by operations or compliance. Third, when the requirement is real-time event distribution rather than request/response — Event Mesh or direct iFlow with HTTP adapter is more appropriate. Choose deliberately.

Q: How is Open Connectors billed?

Open Connectors API calls count as messages within the unified SAP Integration Suite metric. Messages are sized in 250 KB increments and sold in blocks of 10,000. The same capacity-unit pool funds Cloud Integration messages, API Management calls, and Open Connectors calls. There is no separate Open Connectors line item. Practically, this means modelling year-one and year-two volume across all Integration Suite usage, not per capability.

Q: How do we document an Open Connectors requirement properly?

Each integration needs: (1) target SaaS vendor and confirmed catalog entry, (2) required operations (read, write, bulk, events) explicitly listed, (3) authentication mode and credential ownership, (4) volume estimate in messages per month, (5) named sponsor with vendor-coordination authority, (6) observability strategy beyond the platform default, (7) Common Resource mapping if more than one SaaS will reach the same SAP process, and (8) contingency plan if the connector is retired or the vendor changes API. A one-line “we’ll use Open Connectors” in a requirements document is not enough — that line is where most production incidents start.

Q: When should we descope an Open Connectors integration from the project?

Descope when any of the following is true: the SaaS vendor is not in the catalog and Connector Builder cost exceeds the integration’s value; the volume forecast pushes capacity-unit cost above the business case; observability requirements exceed what Open Connectors offers and Cloud Integration is therefore needed anyway; or no internal sponsor will accept ongoing operational ownership. In any of these cases, “yes but later” or “no, we’ll handle it differently” is a stronger answer than forcing the fit.

Q: Does Open Connectors work with on-premise SAP, or only S/4HANA Cloud?

Both, indirectly. Open Connectors itself runs on BTP Cloud Foundry and exposes a normalized REST endpoint. Whether that endpoint reaches an S/4HANA Cloud tenant or an on-premise S/4HANA system depends on the receiving Cloud Integration iFlow (which uses the SAP Cloud Connector for on-prem). Open Connectors is on-premise-agnostic; the connectivity decision is downstream.

Summary#

SAP Open Connectors is a specialized REST-normalization layer for SaaS integration inside SAP Integration Suite — over 160 prebuilt connectors organized into hubs, with Common Resources, Formulas, JavaScript hooks, Bulk and Events to harmonize third-party APIs behind a single normalized endpoint. The runtime is production-stable; the hard caps (8 MB payload, 5 MB JS, 29 s execution, 6 GB streaming) are well documented; and the architectural payoff is real when Common Resources are used to abstract multiple SaaS behind one schema. The honest constraints are observability that is thinner than Cloud Integration, a vendor-driven connector lifecycle that adds maintenance, and an SAP investment cadence that is slower than the rest of Integration Suite. The consultant value is the catalog check before the architecture conversation, the discipline to route oversized or under-observable workloads to Cloud Integration, and the willingness to document a contingency plan for the cases where Open Connectors is the wrong tool for the requirement.

What to Read Next#