Connecting Salesforce and SAP ECC - without touching the hosting provider

Two strong systems, no connection

The client - a mid-sized German machinery manufacturer with a growing after-sales business - runs its commercial core on SAP ECC and had introduced Salesforce as its platform for sales and service. Both systems did their jobs. What was missing was the connection between them.

• New customers won in Salesforce had to be created a second time, manually, as SAP customer masters.

• Quotations were maintained in parallel in both systems.

• Orders reached order processing as e-mails and spreadsheets.

• Service technicians recorded working time in one system; someone re-typed it into another.

• Invoices existed in the SAP archive but were invisible to the service team working in Salesforce.

Each of these breaks cost time. Together, they capped how fast the company could grow its order intake and spare-parts business without growing its back office at the same rate.

Two constraints shaped the project from day one. First, the SAP landscape does not sit in the client’s own data centre: it is operated by an external hosting provider and reachable exclusively through an established IPsec tunnel that carries live production traffic. Second, an S/4HANA migration is on the long-term roadmap - the integration layer must not become the thing that blocks it.

The assignment

ZirkelTech was engaged to design and deliver the end-to-end integration platform across two workstreams:

• New customers and orders - from a won opportunity in Salesforce to customer master, quotation and sales order in SAP.

• After-sales - spare-parts quotations and orders, service time entries into SAP’s Cross-Application Time Sheet (CATS), and retrieval of invoice documents from the SAP archive (ArchiveLink) into Salesforce.

A scope extension during delivery - synchronising Salesforce quotes into SAP SD quotations - was absorbed by re-prioritising the sprint plan rather than halting the programme.

Solution architecture: event-driven by default

The platform follows three principles: decouple the systems, make every flow observable and replayable, and keep every SAP touchpoint explicit and minimal.

• Salesforce Platform Events as the trigger layer. Changes to customers, quotes and time entries are published as events - Salesforce never depends on SAP being reachable at the moment of change.

• MuleSoft CloudHub 2.0 (Private Space) as the integration layer. Applications subscribe to the events, validate and transform payloads, and orchestrate the SAP calls. The Private Space provides a dedicated network segment with controlled egress - the anchor for the VPN design below.

• SAP inbound via released, whitelisted BAPIs, executed by a dedicated technical user. Slim custom RFC modules are used only where the standard library has gaps.

• SAP outbound via ALE/IDoc. Change pointers detect relevant master-data and status changes; IDocs are dispatched to a registered RFC server hosted by the integration layer and forwarded to Salesforce - high-volume loads via Bulk API 2.0.

• Resilience by construction. Anypoint MQ decouples the processing stages; failed messages land in dead-letter queues with alerting instead of disappearing; upserts are idempotent on external keys, so replays are safe.

• A consistent three-tier landscape - development, quality assurance, production - across Salesforce, MuleSoft and SAP.

The hard part: reaching an externally hosted SAP from the cloud

Most integration projects assume the ERP is a few firewall rules away. Here it was not. The SAP landscape runs at an external hosting provider and is reachable only through an established IPsec tunnel between the client’s site and the provider - a tunnel that carries live production traffic.

The textbook answer - a second, direct VPN between the integration cloud and the hosting provider - was ruled out early. It would have meant configuration changes, contractual coordination and change windows on the provider side, and it would have put a third party into the critical path of every future adjustment.

ZirkelTech designed a transit architecture instead:

1. A site-to-site IPsec VPN connects the MuleSoft Private Space to the client’s perimeter firewall.

2. The firewall routes integration traffic onward through the already established tunnel to the hosting provider.

3. Before entering that tunnel, all integration traffic is source-NAT’d (SNAT) to an address from the client’s own network.

The effect: from the hosting provider’s perspective, integration traffic is indistinguishable from the client’s regular site traffic. Existing firewall policies, routing and contractual arrangements on the provider side remained untouched - nothing had to be requested, and nothing on the provider side can break the integration.

The design is deliberately narrow. VPN selectors and firewall rules permit exactly the SAP gateway and dispatcher ports required, in the required direction, and nothing else. The proposed IPsec parameters were hardened beyond vendor defaults before go-live.

Lesson from the SAP gateway: working RFC does not mean working IDocs

A pattern worth sharing, because it recurs across SAP integration projects: once BAPI calls into SAP succeed, teams assume the reverse direction - SAP pushing IDocs out - will work over the same connection. It does not follow.

Working RFC connectivity into SAP says nothing about SAP’s ability to push IDocs out. The outbound stack - distribution model, change pointers, partner profiles, gateway ACLs - is separate, and in a greenfield environment it is a workstream of its own.

Outbound IDoc processing sits on its own configuration stack: the ALE distribution model, change pointer activation, partner profiles and ports - and, most often overlooked, the SAP gateway’s security ACLs (reginfo/secinfo), which decide whether an external program may register as an RFC server at all.

In this project, the gateway rejected the first registration attempt of the integration layer’s RFC server with the classic error message: registration of tp … from host … not allowed.

The root cause had a twist. Because of the SNAT transit design, the SAP gateway never sees the integration platform’s address - it sees the tunnel egress address inside the client’s network. An ACL entry scoped to the obvious source would never have matched. The fix followed a disciplined path: enable gateway logging to capture the exact source host being rejected, add a minimally scoped permit rule for precisely that program ID and source, and reload the ACLs at runtime - no gateway restart, no downtime.

The broader takeaway: in a greenfield environment, IDoc enablement is a workstream of its own. Plan and budget for it explicitly - it does not hide inside “connectivity is done”.

Security by design

• A dedicated technical user for the integration - no dialog access, no shared credentials.

• A single-purpose authorisation role built on the least-privilege principle. The RFC whitelist contains exactly the function modules the interfaces call - roughly two dozen released BAPIs plus a handful of custom read modules - and nothing else.

• Gateway ACLs operate deny-by-default; every registered server program is permitted individually and scoped to its source.

• VPN selectors and firewall rules follow the same philosophy: specific subnets, specific ports, one direction.

One detail from the design phase illustrates the level of verification applied: an early interface inventory referenced a “standard” BAPI for reading quotation lists that, on inspection, does not exist in SAP ECC at all. It was replaced by a slim custom read module on the sales document tables. A small finding with a large moral - every assumed standard interface is verified against the actual system before it becomes a dependency in someone’s design.

Results

Highlighted figures are project estimates - validate against production data before publication.

• Five manual media breaks eliminated along the lead-to-cash and after-sales chain - customer creation, quotation maintenance, order entry, service time transfer, and invoice lookup.

• Six end-to-end processes integrated on a single platform - with zero configuration changes on the hosting-provider side and no interruption to the production tunnel.

• Transcription errors from manual re-keying eliminated by construction: data is validated at the interface before it ever reaches SAP.

• Customer and quotation data available in SAP in under five minutes of the Salesforce event - previously a manual process taking one to two business days.

• Roughly 15 hours per week of duplicate entry and manual transfers removed across sales, order processing and service.

Beyond the numbers: customer and order data are consistent across CRM and ERP; service time entries flow into CATS without media breaks; invoices from the SAP archive are visible to the service team directly in Salesforce; and the platform is built to take on additional processes - from automated ticket billing to bidirectional master-data flows - without re-architecting.

Outlook: built for the S/4HANA question

Because every SAP touchpoint runs through the integration layer’s explicit, versioned interfaces - not through point-to-point plumbing - a later move from ECC to S/4HANA changes the endpoint, not the architecture. Interfaces are re-mapped centrally; Salesforce and the event model remain untouched. For a mid-sized company facing that migration in the coming years, this decoupling is not an academic benefit. It is the difference between one project and two.