Architecture for ERP integration in Ignition — REST API vs MQTT vs direct DB vs UDTs (for read + write at MES scale)?

General Discussion
,
1

We're building a Perspective application for a manufacturing cell — this particular one (a barcode scan triggering a lookup) is a smaller starting example, but it's really a test case to figure out the right general pattern before we build much larger applications on top of it, including a WIP booking / MES-style system with significantly more frequent and varied data exchange with our business system (both reading and writing).

An operator scans a barcode. From that, we need to look up related data from our ERP system (backed by SQL Server) — currently accessed via an integration layer, HighByte Intelligence Hub (DataOps Software), sitting in front of the database.

We're investigating the best overall approach here, including whether a direct database connection from Ignition might actually make sense if it has a significant advantage over going through the integration layer — so genuinely open on that point, not ruling it out. Given the scale of what's coming (MES-level volume, not just occasional lookups), we want to get this pattern right early rather than retrofit it later.

Example: operator scans a barcode → we look up several related pieces of data (job status, routing information, and reference data for the part) to drive the next screen and validate inputs later in the process. At the end of the process, we also need to write results back into the ERP — so this isn't purely read-only.

We're currently calling HighByte's REST Data Server (pipelines) from a Project Library script using system.net.httpClient, triggered by a button after the scan, and that's working for this small case. Before scaling this pattern up, wanted to sanity-check it against what others are doing for similar barcode-triggered lookups and ongoing read/write integration with a business system:

  • REST API call via an integration layer (request/response, on demand) — what we're doing now
  • Direct database connection from Ignition
  • MQTT (HighByte publishing relevant data to a broker, Ignition subscribing)
  • OPC UA
  • Something else

Specifically interested in:

  • How well each of these approaches scales as request volume grows significantly (e.g. MES-style frequent transactions, not just occasional lookups)
  • Whether the transactional write-back requirement rules out some of these approaches
  • Pros/cons of going direct to the database vs through an integration layer like HighByte, especially for an ERP system with its own business logic
  • Whether request-on-demand (REST, pulling data when needed) is the wrong mental model here, versus a push model where HighByte publishes relevant state continuously (e.g. via MQTT) so the data is already available by the time something like a scan happens — and how people handle the practical question of what gets published proactively versus what stays on-demand, given the source system has far too much data to publish everything

Any real-world experience appreciated, especially from people who've scaled a similar pattern up from a small pilot to a higher-volume production system.

Apologies for the long post — wanted to give enough context to get genuinely useful answers rather than generic ones. Thanks in advance for any input.

2

I strongly prefer using a DB connection for this kind of task, for two reasons:

  • Operator interactions are quite latency sensitive. Every software layer and network hop added to the request and response makes latency worse.

  • The modern US-CERT security model places SCADA and its production DBs and similar resources on the same LAN as the operators and equipment, inside the plant. ERP/MES data should be pro-actively pushed down into the local production DB to insulate the facility's operations from accidental or malware-inspired network isolation.

(Writeback from the production DB to the enterprise layers should be some form of DB replication. Avoid having SCADA do this part.)

3

It also insulates the integrator from the ERP system. Less suspicion on the integrator if something goes terribly wrong with the ERP, even if totally unrelated.

To Phil’s point, it also would be more secure. I think about the HVAC contractor that was the back door for the massive Target data breach. Avoiding situations like that would be preferable.