Configuring the Outbound RFC Destination

Last updated: August 2026

The one SAP-side setting that decides whether SAP real-time data extraction actually works: a Type G HTTP RFC destination in transaction SM59, the three fields that make or break it, and the activation step most walkthroughs skip entirely.

Everything about SAP real-time data extraction with Onibex OneConnect, business events firing, a data product modeled, a Kafka topic waiting on the other end, depends on one small piece of SAP configuration actually being correct: an outbound RFC destination in transaction SM59, pointed at the OneConnect Smart Gateway. Get the host, port, or path wrong and none of the rest of the pipeline matters, because SAP never reaches it. This is what that destination is, why it has to be this specific connection type, and what it does and doesn't turn on by itself.

Why RFC, and why Type G

Remote Function Call is SAP's interface for talking to systems outside itself, and it works in both directions: SAP can act as a server receiving RFC calls, or as a client making them. Real-time data extraction needs the second direction: SAP, as the client, calling out to an external endpoint the moment a business event fires.

SM59 supports several connection types, but only one fits this job: Type G, HTTP Connection to External Server. It's the type built for exactly this shape of integration, an SAP system calling a plain HTTP endpoint outside its own landscape, in this case the OneConnect Smart Gateway, rather than another SAP system or a legacy gateway. And because SAP is the one placing the call, the connection is outbound by definition. No inbound port gets opened on the SAP side for any of this to work.

The URL you already have, split into three fields

The destination endpoint already exists before you ever open SM59, generated by OneConnect the moment the specific SAP Link is created on the Smart Gateway. What it looks like depends on how that Smart Gateway is deployed.

A hosted, multi-tenant environment typically fronts it with a real domain:

https://{oneconnect-domain}/api/v1/saplistener/{SAP_LINK_ID}/synchronous

A dedicated or on-premise deployment installed for one client usually skips the domain entirely. A load balancer configured for that SAP Link sits behind a DNS name or a raw IP address instead, on an explicit port such as 8081:

http://{dns-or-ip}:8081/api/v1/saplistener/{SAP_LINK_ID}/synchronous

Either form splits the same way into the three fields SM59 asks for:

• Host: the domain, DNS name, or IP, e.g. {oneconnect-domain} or {dns-or-ip}
• Port: the port the endpoint listens on, typically 443 for a domain-fronted HTTPS endpoint, or an explicit port like 8081 for a load-balanced DNS or IP endpoint
• Path Prefix: /api/v1/saplistener/{SAP_LINK_ID}/synchronous (or /asynchronous)

{SAP_LINK_ID} in the path isn't a value to leave as-is. OneConnect generates a unique ID for every SAP Link when it's created, and that's what goes there, different for every SAP Link, even within the same Smart Gateway deployment. The final segment, synchronous or asynchronous, is set according to how that particular SAP Link is configured to deliver.

Pair that with a Destination Name (something identifiable, ONIBEX_ONECONNECT works fine) and the connection has an identity SAP can reference from anywhere else in the system.

Credentials that already exist somewhere else

The Logon & Security tab asks for a username and password, and the detail worth knowing before typing anything in is that these aren't new credentials to invent. They have to match the account already configured on the OneConnect side, the same workspace user set up on the Smart Gateway. Get this tab right and wrong host/port/path settings become the only remaining failure mode; get it wrong and the connection fails for a reason that has nothing to do with networking.

What a 400 and a 500 are actually telling you

SM59 includes a Connection Test button, and the response code it returns is a diagnostic, not just a pass/fail:

• 200: the connection reached the endpoint and authenticated. Nothing left to fix here.
• 400: the server wasn't detected at all. This is a host, port, or path prefix problem, not a credentials problem, don't touch the Logon & Security tab yet.
• 500: the server was reached but rejected the credentials. This is the Logon & Security tab, specifically, and the network path is already confirmed fine.

That distinction matters because it tells you which tab to go back to instead of re-checking everything. A 400 means stop looking at the password. A 500 means stop looking at the host.

Configuring the destination doesn't turn on real-time extraction by itself

This is the part that's easy to miss: a correctly configured, green-checkmark RFC destination is necessary for SAP real-time data extraction, but it isn't sufficient on its own. The destination is a path. Something still has to decide to send traffic down it, and that's a separate activation step, not a side effect of SM59.

Real-time extraction runs on SAP's business event framework, and three transactions specifically control whether those events actually fire and reach the destination you just configured:

• SWELS: activates the event monitor that tracks business events at all. Without it, events don't get raised, regardless of what's listening on the other end of the RFC destination.
• SWETYPV: activates the specific BOR event type linkages that real-time extraction depends on, per business object.
• SWEL: the event log, useful for confirming an event was actually raised when a document posts, before spending time debugging the RFC side of the pipeline.

Skip these and the symptom is confusing: the RFC destination tests green, everything on the SAP configuration side looks correct, and no data ever arrives, because nothing ever told SAP to raise the event that would have used that destination in the first place.

The order that actually saves time

Configure the RFC destination first and confirm it independently with the Connection Test button. Only once that returns 200 should the event activation transactions (SWELS, SWETYPV) enter the picture. Debugging both layers at once, "is it the connection or is it the event," is where most of the wasted time in getting SAP real-time data extraction working actually goes. Isolate the transport layer, confirm it, then isolate the event layer on top of a transport you already know works.

---

The full field-by-field walkthrough of this configuration, screen by screen, is already documented in the OneConnect documentation. If you want to see this connection tested end to end against your own SAP system, Onibex runs the 15-Hour Business Value Challenge as a no-cost proof of concept.