How to Connect Your ERP System to a Unified Namespace

If you've been following the Unified Namespace conversation, you've probably noticed something: most of the discussion focuses on machines. Connecting PLCs, sensors, and SCADA systems to an MQTT broker is relatively straightforward. There are established protocols, off-the-shelf connectors, and a growing ecosystem of edge devices designed exactly for this purpose.

But the real value of a Unified Namespace emerges when shopfloor data meets business context. And that context lives in your ERP system.

The machine tells you that 47 parts came off the line in the last hour. But which production order are those parts for? Which customer is waiting for them? Are you ahead of schedule or behind? Is the quality acceptable for the specification this customer requires?

These questions can only be answered when machine events are anchored to ERP data. And building that connection — what we call the ERP-UNS Bridge — is where most organizations get stuck.

Why This Is Harder Than It Looks

Connecting machines to a UNS is relatively forgiving. A sensor publishes temperature readings every second. If one message gets lost, another arrives a moment later. The data is inherently redundant.

ERP systems are different. They manage transactional data — discrete business events that change state permanently. When a production order is released, or a customer order is confirmed, that's not a continuous stream of updates. It's a single, critical event that must be captured correctly.

This fundamental difference creates three challenges:

1. Different data rhythms. Machines generate continuous streams. ERP systems work in transactions. Mixing them requires careful design.

2. Authority and ownership. Your ERP system is the "source of truth" for business data. Any integration must respect that authority without accidentally corrupting it.

3. Semantic mismatch. Machines speak in physical units — temperatures, pressures, cycle counts. ERP systems speak in business abstractions — orders, operations, routings, work centers. Translating between these worlds requires explicit mapping.

The Bridge Pattern: Start as Observer, Grow Into Participant

When building ERP-UNS integration, we recommend starting with a read-only approach: observe first, then participate.

Your ERP system has been managing production for years. It handles costing, inventory, capacity planning, and financial reporting. These are complex, interconnected processes that have been refined over time. Jumping straight into automated postings without understanding the data quality and edge cases is risky.

The bridge pattern starts strictly read-only from the ERP's perspective. It watches what's happening in both systems and creates a unified view. This lets you validate data quality, build trust, and understand edge cases before enabling automated transactions.

Once you've established that the execution data is reliable, the next step becomes possible: using shopfloor facts to drive ERP postings. Output quantities reported from machines can trigger consumption postings. Cycle times can feed into more accurate cost calculations. Downtime events can update capacity availability.

This progression — from observer to participant — is intentional. It means you can deploy a UNS integration, prove its value, and then gradually extend its authority as confidence grows.

The bridge pattern: machines publish to UNS, bridge enriches with ERP context

What Flows Through the Bridge

To understand the bridge, let's trace what happens when a machine produces a part.

Step 1: The machine publishes an event

{
    "topic": "factory/lineA/cell1/cnc-mill",
    "payload": {
        "cycleComplete": true,
        "partCount": 1,
        "cycleTime": 42.3,
        "timestamp": "2025-01-27T14:32:15Z"
    }
}

At this point, the message has no business context. It's just a machine saying "I finished a cycle."

Step 2: The bridge adds context

The bridge subscribes to machine topics. When it sees this event, it looks up the current production order running on that work center. It consults its mapping table to translate the UNS topic (factory/lineA/cell1/cnc-mill) to an ERP work center code (WC-CNC-01).

It then queries the ERP API: "What production order is currently running on work center WC-CNC-01?"

Step 3: The bridge creates an anchored execution event

{
    "messageId": "550e8400-e29b-41d4-a716-446655440000",
    "orderNo": "PO-12345",
    "operationNo": "20",
    "workCenter": "WC-CNC-01",
    "qtyProduced": 1,
    "cycleTimeSec": 42.3,
    "sourceTimestamp": "2025-01-27T14:32:15Z",
    "source": "cnc-mill-01"
}

Now the event has meaning. We know this part belongs to production order PO-12345, specifically to operation 20 in the routing. We can aggregate these events to answer questions like "How many parts has this order produced today?" or "Is this operation running faster or slower than planned?"

Step 4: The ERP stores and acts on execution facts

The ERP receives this event through its API and stores it in a dedicated execution facts table. In the initial phase, this is purely for visibility — production planners can see real-time progress, and supervisors can spot delays before they become crises.

As trust in the data grows, the ERP can start acting on these facts: posting output quantities, triggering material consumption, or updating actual costs based on real cycle times. The architecture supports both modes.

The complete flow: from raw machine event to anchored execution record

The Mapping Problem

One of the trickiest aspects of the bridge is mapping. The UNS organizes data by physical location: factory, area, line, cell, device. The ERP organizes data by business logic: production orders, routings, operations, work centers.

These hierarchies don't align naturally. A UNS topic like factory/lineA/cell3/laser-cutter might correspond to work center WC-LASER-01 in the ERP — but that relationship isn't obvious from either side.

The bridge needs an explicit mapping table that says: "When you see events from this UNS topic, they should be associated with this ERP work center."

This mapping table lives in the ERP system, not in the bridge code. This is important: it means production engineers can add new machines to the UNS without requiring code changes. They simply add a row to the mapping table.

Some organizations want to go further and have the ERP "discover" new topics automatically. While this sounds convenient, it introduces ambiguity. What if a new topic appears that could map to multiple work centers? Auto-discovery can work for suggesting mappings, but a human should confirm them before they become active.

The data model: how UNS topics connect to ERP production orders via work centers

Handling the Messy Reality

Real-world integration is messy. Messages arrive out of order. The network drops packets. Machines restart and replay old events. The bridge needs to handle all of this gracefully.

Idempotency: The same message twice should be harmless

Every execution event carries a unique messageId. When the ERP receives an event, it checks: have I seen this ID before? If yes, it acknowledges the message but doesn't process it again. This makes the entire pipeline safe for retries — which is essential when you're dealing with unreliable network connections on the shopfloor.

Time ordering: Old news shouldn't overwrite new facts

Every event carries a sourceTimestamp — the moment the event actually occurred according to the source system's clock. The ERP tracks the latest timestamp it has seen for each production order operation. If an older event arrives after a newer one has been processed, the older event is stored for audit purposes but doesn't update the summary fields.

This sounds like a minor detail, but it's critical for systems where events might take different network paths and arrive out of sequence.

Idempotency: duplicate messages are safely ignored

Time ordering: late-arriving old events don't overwrite newer data

Explicit failure: When in doubt, reject and explain

What happens when the bridge receives an event for work center WC-CNC-01, but there are two production orders currently assigned to that work center? Or zero?

The system has a choice: guess, or ask for clarification.

We strongly advocate for the second approach. The bridge should reject the event with a clear error message: "Cannot resolve: work center WC-CNC-01 has 2 active production orders. Please specify orderNo explicitly."

This might seem inconvenient, but it prevents a far worse outcome: silently attributing production to the wrong order. When you're reconciling month-end inventory or investigating a quality issue, you need to trust that your data is correct — even if that means fixing some rejected events along the way.

What the ERP Side Needs

For this architecture to work, your ERP system needs to provide (or you need to build) a few capabilities:

1. An API endpoint for receiving execution events

The bridge needs somewhere to send its enriched events. This is typically a REST API endpoint that accepts JSON payloads and stores them in an execution facts table.

2. Reference data APIs

The bridge needs to query production orders, routing lines, work centers, and items to do its job. These are typically read-only endpoints.

3. A mapping configuration UI

Someone needs to maintain the topic-to-work-center mappings. A simple list page in the ERP with add/edit/delete functionality works fine.

4. Extension fields for visibility

If you want production planners to see real-time progress on their existing screens, you'll need to add extension fields to production order pages. These display derived KPIs (total quantity produced, current availability, etc.) without modifying the underlying tables.

Open-Source Implementation for Business Central

For Microsoft Dynamics 365 Business Central users, we've built a complete open-source implementation of everything described in this article. The UNS Bridge Connector provides:

• API endpoints for receiving execution events
• The topic-to-work-center mapping table
• Visibility extensions for production order pages
• Idempotency and time-ordering handling
• Full source code you can customize

The technical documentation goes deeper into implementation details, including database schema design, API specifications, and deployment patterns.

The Bridge Itself: Where Does It Run?

The bridge is a separate service — not part of the ERP, not part of the edge devices. It runs as middleware that connects to both worlds.

Architecturally, it needs to:

• Subscribe to relevant MQTT topics from the UNS
• Maintain a connection to the ERP API
• Cache reference data for performance (work centers, active orders)
• Transform machine events into ERP execution events
• Handle failures and retries gracefully

You can build this in any language that supports MQTT and HTTP clients. Python is popular for prototypes. Go or Rust work well for production deployments where resource efficiency matters. Node.js is fine if your team is already comfortable with it.

The bridge can run on-premises, in the cloud, or on an edge gateway — wherever it can reach both the MQTT broker and the ERP API. For organizations with strict network segmentation, running it on a dedicated gateway in the OT network (with outbound-only connections to the ERP) is a common pattern.

Typical deployment: bridge in OT zone with outbound-only connection to cloud ERP

What You Gain

When the bridge is operational, several things become possible that weren't before:

Real-time production visibility. Planners see order progress as it happens, not as of the last manual data entry. This enables faster reaction to problems and more accurate delivery estimates.

Execution facts at the ERP level. Some data from the shopfloor is directly relevant to ERP processes. Actual cycle times enable more accurate cost calculations. Real output quantities can feed variance analysis. Machine availability affects capacity planning. This isn't about replacing MES — it's about making execution facts available where they're needed for business decisions.

Audit trail by default. Every execution event is stored with its source timestamp and message ID. You can trace exactly what happened, when, and why.

Foundation for automated postings. Once execution data flows reliably and you trust its quality, the path to automated output posting and consumption booking becomes much shorter. The infrastructure is already in place.

What It Doesn't Do

To keep expectations realistic, let's be clear about what this architecture does not do:

• It does not replace MES. If you need workflow enforcement, detailed work instructions, or real-time production scheduling, you still need an MES. This architecture makes execution facts visible in the ERP — it doesn't control execution.
• It does not handle master data maintenance. Work centers, routings, and items are created and maintained in the ERP as usual. The bridge only reads this data.
• It does not solve all data quality problems. If your production orders are incorrect in the ERP, the bridge will faithfully report progress against incorrect data. Garbage in, garbage out.

Getting Started

If you're ready to build your own ERP-UNS bridge, here's a practical sequence:

1. Start with one work center. Pick a machine that already publishes events to your UNS. Connect it to one production order in your ERP. Make sure you can trace a cycle event all the way through to an execution record.

2. Build the mapping infrastructure. Create the topic-to-work-center mapping table. Decide whether you want auto-discovery with confirmation, or purely manual mapping.

3. Handle the edge cases. Test what happens when a message arrives twice. Test what happens when a work center has no active order. Test what happens when the ERP API is unavailable. These scenarios will occur in production.

4. Add visibility to the ERP. Once execution data is flowing, extend your production order screens to display it. This is where stakeholders start to see value.

5. Expand gradually. Add more work centers, more production lines, more data points. Each addition should be incremental and reversible.

For those using Microsoft Dynamics 365 Business Central, our open-source UNS Bridge Connector handles steps 2-4. You build the bridge service (step 1) and configure it for your specific UNS topology. The extension provides the ERP-side infrastructure — API endpoints, mapping tables, and visibility extensions.

For implementation details, data model documentation, and deployment guides, see the Shopfloor Execution Bridge documentation.

Conclusion

The Unified Namespace is often discussed as a shopfloor technology — a way to get machines talking to each other and to analytics systems. That's true, but it's only half the story.

The full value of a UNS emerges when operational data meets business context. When cycle counts become production progress. When machine events become order status. When sensor data becomes decision-relevant information.

Building that bridge requires care. ERP systems are critical infrastructure with complex, interconnected processes. Start by observing, build trust in the data, then extend authority as confidence grows.

Whether you build this yourself or use our open-source components, the principles remain the same: respect the ERP's authority, map explicitly between worlds, handle edge cases gracefully, and let the integration mature from visibility to automation.

The machines are already talking. It's time to help your ERP listen.

The UNS Bridge Connector for Business Central is open-source and available on GitHub. For technical documentation, see the Shopfloor Execution Bridge docs. For help implementing this pattern in your organization, get in touch.