- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
4 hours ago
Most Zero Copy Connector for ERP setups that stall are not broken in any deep way. Something is missing, or pointed at the wrong place, and the symptom (usually a dead heartbeat) does not tell you which. This article maps the common causes back to what you are seeing, in the order a setup tends to hit them. How to configure each piece is in the docs and the other articles here.
MID Server not configured for the connector
On-premise RFC/BAPI traffic runs through a MID Server, and two things on it are easy to miss. The MID Server record has to include Zero Copy Connector for ERP in both its Supported applications and its Capabilities. Without that, a healthy MID Server still leaves the RFC heartbeat dead, because no ERP work gets routed to it. The mid_user account also needs the sn_erp_integration.erp_mid_server role, which is what lets it write data back through the ImportSet API. A connection that looks configured but never reaches the instance usually comes down to that role.
Cloud is different. S/4HANA Cloud and SuccessFactors connect over OData with no MID Server involved, so there is nothing to set up here and nothing to debug.
JCo library (on-premise RFC)
RFC depends on SAP's Java Connector, loaded onto the MID Server as JAR files and in place before you install the connector. Expect the MID Server to restart a few times as it picks the files up. If the RFC heartbeat will not come up and the MID Server settings above are correct, JCo is the next thing to check. The install steps are in the Doc's, and the connector's requirements page says which files go where.
Choosing RFC or OData
ECC and S/4HANA on-premise support both, and plenty of systems use both at once, so there is no default to reach for. It is a per-entity choice. What matters at setup is that the two paths need different things: RFC wants the MID Server and JCo above, OData wants a service that is actually exposed on the SAP side. A red HTTP heartbeat is more often a missing or misnamed OData service than a connector fault.
Heartbeat failures
RFC and HTTP each have their own heartbeat. BAPI and table retrieval run over RFC, OData over HTTP, so read the tab for whichever path you are using. The connector re-pings about every five minutes, and when it can tie a failure to a known cause it drops the error text and a KB link onto the heartbeat tab. Restart data retrieval on the system record forces a refetch.
On a load-balanced connection, SAP System Number has to be empty. Filled in, the connection will not come up, because load balancing routes through the message server, system ID, and logon group instead. The SAP load-balancing article walks those fields.
An authentication error means the credential does not match the SAP service user exactly, or that user is missing its RFC authorisations. Check the roles and permissions here It lists those authorisation objects in full.
A ServiceNow role assigned without its scope grants nothing at all. It has to be sn_erp_integration.erp_admin, not erp_admin.
Nothing in Model Manager after connecting
A working connection does not populate Model Manager by itself. An admin has to switch on sn_erp_integration.enableModelModification on the right scope, which is what pulls the table and BAPI catalog in. It is set separately for non-production and production, so enable it where you are actually building. Greyed-out Clone and Manage Model buttons, after a good connection, point straight to this.
OData timeouts on large reads
Less a setup issue than one that shows up later. OData responses time out at 100 seconds by default. If large reads fail intermittently, raise the timeout and cap how many records a single GET returns, so you are not pulling back more than the flow needs.
The Quick-Start Guide covers the full path from install to a first use case. Everything else is in the Zero Copy Connector for ERP docs.