Connecting Ignition SCADA to SAP: Routes, IDoc and Common Pitfalls

Ignition connects to PLCs and other data sources over OPC UA, SQL databases, REST and MQTT, some of these only with add-on modules. SAP offers RFC, BAPI and IDoc. There are three routes from Ignition to SAP, and they are not mutually exclusive.

Route 1: your own code in Ignition. Ignition can be extended with scripts: it can call web services and expose its own HTTP endpoints with an add-on module. The scripting language is Python, which Ignition runs as Jython on the Java platform, so scripts can use the Java standard library. Java libraries beyond the standard library, including SAP’s, can only be added with changes to the Gateway, through a custom module or the Gateway configuration. The code then has to be maintained in the project.

Route 2: an add-on module in Ignition. Third-party modules bring RFC and BAPI access to SAP into the Gateway. They fit when Ignition is the only system that exchanges data with SAP.

Route 3: a separate integration layer. A middleware layer connects to SAP over RFC and IDoc on one side and to Ignition over SQL, OPC UA or REST on the other. Ignition then needs no SAP interface of its own. What such a layer does in general is described in What is middleware? The integration layer can publish SAP data into a Unified Namespace that Ignition reads from, or hand it to Ignition directly over SQL, OPC UA, REST or Sparkplug, whichever fits the project and the existing stack. A separate integration layer makes sense when several systems are connected to SAP, or when the link should be maintained without programming in the Gateway.

Which route fits depends on who will maintain the interface and on whether it is one of many or the only one. Just as relevant is how many places hold the connection to SAP. Each of them has to be set up, monitored and adjusted when something changes on the SAP side. With several Gateways, the connection can be bundled in one central place, for example in an integration layer, which is then one more system to operate. Two technical questions come on top. If SAP already sends IDocs to other systems, the receiving side has to handle IDoc, including the status records; if everything runs over RFC and BAPI, an RFC-capable route is enough. And if SAP pushes orders, the route needs a trigger that SAP calls; if Ignition pulls data, a client is enough.

IDoc is the SAP format for exchanging business documents asynchronously: the sender hands over a document, the receiver buffers it and processes it in turn. It is the usual format for master data and postings, while an RFC call is synchronous and fits where an answer is needed at once. How IDoc differs from RFC and BAPI is explained in SAP interfaces to external systems.

Receiving an IDoc inside the Gateway itself takes code of your own: an HTTP endpoint that SAP posts the IDoc to, or SAP’s Java library with its IDoc extension. It gets simpler when the IDoc arrives in a database that Ignition already reads.

This route is described here from the OPC Router manual.

On the SAP side, the SAP plug-in connects to SAP over RFC only, including IDoc and BAPI, either as classic RFC or as NetWeaver RFC. It supports SAP NetWeaver, ECC 6 and R/3 from release 4.0B onward, among others; in Docker, only the NetWeaver protocol is available. The SAP libraries come from SAP itself, so you need an SAP account to obtain them. The classic RFC library librfc32 has been unsupported by SAP since March 31, 2016.

The plug-in has four transfer objects and two triggers:

The IDoc trigger is set up with a program ID and a gateway service. The program ID must exactly match (case-sensitive) the program ID registered in the RFC destination in SM59. In addition, IDocs can be received over HTTP or HTTPS at an endpoint of their own, configurable with a port, basic authentication and an SSL certificate. The received IDoc can be passed on as a JSON document and written from there into the database that Ignition reads.

On the Ignition side, the layer uses interfaces that Ignition documents itself. The OPC Router can write to the SQL Server, PostgreSQL or MySQL tables that Ignition reads via JDBC. It can act as an OPC UA server that Ignition connects to as a client, and offer values that come from SAP rather than from a PLC. It can publish over Sparkplug as an edge node, or work as a Sparkplug application. And it can call or expose REST endpoints, importing an OpenAPI description instead of typing endpoints by hand. Over MQTT, it can also publish SAP data into a Unified Namespace that Ignition reads from.

Put together, one flow might read an order from SAP by RFC and write it into a SQL table that an Ignition screen displays. A second flow can pick up the confirmation from that table and send it back to SAP as an IDoc.

The OPC Router can run as a redundant pair. The second instance sets up its connections while on standby and can take over when the first one fails. For SAP, the manual recommends a separate program ID per instance for RFC and IDoc triggers, and a failover test with the SAP triggers actually in use.

According to the manual, the IDoc trigger acknowledges the incoming call immediately, before the flow runs. The OPC Router places the IDoc in a queue and takes it out on its polling cycle. No result travels back over the original call. If IDoc acknowledgment is switched on in the “Advanced” tab, the OPC Router reports the transfer result afterwards, and the roles reverse: it opens its own RFC connection to SAP and writes the IDoc status record there. The status set on success and on failure is configurable, for example 12 (“Dispatch OK”) and 11 (“Error during dispatch”).

So a successful hand-over in SAP only means the IDoc was received, not that it reached the Ignition database; the status record reports the result of the transfer. The authorizations the OPC Router’s SAP user needs, such as S_RFC for the connection, are listed in the manual.

The OPC Router’s international use cases (page dated August 2026) describe a case from Italy: at a manufacturer of polyethylene pipes, the OPC Router connects SAP S/4HANA with an MES built on Ignition. The link uses SAP IDoc, SAP RFC and Microsoft SQL Server.

Several transactions run between the two systems:

• item master data, with all characteristics of each item,
• receipt of raw material,
• production orders,
• and the feedback to SAP for each order: pieces produced, kilograms of product waste and material consumption.

The case shows a division of labor: Ignition carries the MES, the OPC Router the SAP side.

At this boundary, an asynchronous document format, values from the controller and two independently developed data models meet. The failure patterns that follow depend on how the link is built, whichever SCADA system sits below it. None of them can be solved by software alone.

Accepted does not mean posted

SAP shows an IDoc as handed over, but the order never appears in the MES. Or the other way around: the confirmation was sent, the posting is missing.

Why it happens: IDoc is asynchronous. Hand-over is one step, processing is a second, and in between a document can fail on a missing partner profile, an unknown material or a blocked batch. The first acknowledgment only confirms the hand-over.

Symptom: IDocs with an error status in SAP that nobody processes, and orders missing in the MES without any interface reporting an error.

On your side: The partner profile in WE20, the port in WE21 and the RFC destination in SM59 have to be in place, and someone has to work through the failed IDocs in SAP regularly. This needs a clear owner on the SAP team.

In the OPC Router: For IDocs that SAP sends to the OPC Router: with IDoc acknowledgment switched on, it writes a status record back after the transfer, with the configured status for success or failure. For IDocs it sends to SAP itself, the IDoc status transfer object looks up by IDoc number whether they were processed, including their messages. That makes the second acknowledgment queryable.

Quantity confirmations arrive incomplete or twice

The confirmation to SAP has the piece count, but still carries the scrap of the previous order. Or the same order is confirmed twice.

Why it happens: A confirmation consists of several values that the controller writes one after another. A read during the write catches a mixed state, and change-driven polling can see a change twice or not at all.

Symptom: Postings whose totals do not match the plant’s counters.

On your side: The controller writes all related values first and then increments a counter. That order belongs in the PLC program; no middleware can add it afterwards.

In the OPC Router: If the OPC Router reads the counter itself over OPC, from the controller or through an OPC UA server, the message trigger reacts to the counter change, takes over the record as a whole and writes a response to a response tag. The manual names “reporting quantities to ERP or MES” as an example. If the response does not come, the controller can use that to repeat. If Ignition writes the confirmation as a single row into a table, the transfer status trigger only picks it up once its flag column reads “Not transferred”. The row therefore has to be complete before its flag column gets that value.

SAP is in a maintenance window, the plant keeps running

On Sunday morning SAP is unreachable for two hours. Production runs, and afterwards those two hours of confirmations are missing.

Why it happens: A link without a buffer transfers at the moment it is triggered. If the target is unreachable, the record has nowhere to wait.

Symptom: The gap has sharp edges and lines up with an event in the ERP system, not in the plant.

On your side: Decide per data flow whether late delivery makes sense. For an order confirmation yes, for an instantaneous value no. And every record needs its own timestamp, because values delivered late do not necessarily arrive in their original order.

In the OPC Router: When the OPC Router picks up confirmations from a table, the transfer status trigger marks each record as transferred or failed once the transfer has run. Optionally, it retries failed transfers after a configurable delay; the record stays in the table. Retries stop after the configured number of attempts; set the delay and the number of attempts so that together they last longer than a maintenance window. IDocs that cannot be sent go into an IDoc queue.

Master data does not match

The material number in the MES has six digits, in SAP ten with leading zeros. Scrap is reported in kilograms, SAP expects a different unit.

Why it happens: The MES or SCADA system and ERP got their data models independently of each other. Neither is wrong; they describe the same things with different keys and units.

Symptom: IDocs stuck with an error on the material or the unit of measure, although the material exists in both systems.

On your side: Decide which system leads for which master data, and describe the mapping of keys and units once, in business terms. That is work between production and the SAP team.

In the OPC Router: The mapping is configured graphically in the flow. Which data segments of an IDoc are transferred can be selected; the IDoc transfer object can fill empty numeric fields (NUMC) with zeros automatically.

Ignition brings its own drivers and an OPC UA client; the machine data needs no second layer. An integration layer adds to that when the same data also feeds other systems, such as a historian, a cloud platform or a second MES. When SAP only exchanges data with Ignition, that argument disappears. Where the integration layer reads machine data itself, the OPC Router can do so as an OPC client over OPC UA and OPC Classic (DA); through its OPC UA server it provides an interface of its own, including NodeSets from companion specifications.

One possible division of labor: visualization and MES functions stay on the platform the operators know, and the link to SAP and other IT systems sits in a separate integration layer. How SCADA and MES are distinguished from each other is covered in What is SCADA? and What is an MES? Where both sit in the layered model is shown in What is ISA-95?

Sources on Ignition (retrieved September 21 and 22, 2026): in particular Inductive Automation documentation on the Gateway, third-party OPC servers, JDBC drivers, WebDev, scripting and store and forward. Sources on the OPC Router: OPC Router manual, in particular the chapters on the SAP plug-in, the message trigger, the database triggers and redundancy.