MES integration with D365 Supply Chain: Azure middleware pattern

Manufacturers running Dynamics 365 Supply Chain Management almost always also run a dedicated Manufacturing Execution System (MES) on the shop floor. Production order updates, inventory movements, quality tests, and traceability data flow between them continuously. The integration has to be low-latency (shop floor runs on seconds, not hours), high-throughput (hundreds of events per minute at peak), and reliable (lost messages mean lost traceability).

Three integration patterns come up in evaluations. Two have documented failure modes.

The options that don't fit manufacturing

Nightly batch jobs via Data Management Framework. Designed for bulk data movement, not real-time signaling. Production orders complete hours before D365 knows about it. Real-time inventory view is always lagging. Traceability data arrives after the batches have shipped.

Custom OData polling with a loop that queries MES every few seconds. Introduces polling overhead for no latency benefit, and MES systems aren't typically designed to handle heavy poll loads. Also creates a custom code dependency that needs maintenance.

Database-level triggers on the MES database pushing directly to F&O's database. Breaks supportability completely. D365 F&O is a managed platform - direct database writes aren't supported, aren't upgrade-safe, and will break the next time Microsoft changes schema. Also creates a security nightmare (MES has privileged write access to F&O's database?).

The only answer that fits the requirements is Azure middleware between the two systems.

The Azure-native pattern

Logic Apps or Service Bus as middleware between MES and D365, with F&O Business Events on the D365 side.

What each piece does:

Azure Service Bus for the guaranteed-delivery, ordered messaging. Production-order status updates, inventory moves, quality-test results flow through Service Bus queues with FIFO ordering per production order.

Azure Logic Apps for the orchestration where branching and transformation happen. A pick-complete event from MES fires a Logic App that transforms the payload, updates inventory in D365, and triggers the next production-flow message back to MES.

F&O Business Events for the D365-side publishing. When a production order is created, released, or completed in F&O, a business event fires to Service Bus or Event Grid. MES subscribers pick it up.

Custom Services on F&O for the inbound - when MES has a state change D365 needs to record, the Logic App (or Function) calls a custom service endpoint on F&O. Custom services are designed for low-latency targeted writes, unlike data entities which are bulk-optimized.

Traceability architecture

Traceability is specific in manufacturing - regulators and customers need to know which raw materials went into which finished-goods batch. D365's batch tracking combines with MES's shop-floor batch recording to produce the full lineage. The integration ensures:

• MES tracks the physical movement (machine X processed batch Y at time Z)
• D365 records the ERP-level batch (raw material batch A consumed in production order B producing finished batch C)
• Integration correlates the two via batch numbers and production order references
• Recall scenarios can trace backward from sold finished goods to source materials, or forward from suspect materials to affected finished goods

The integration isn't just about moving data - it's about keeping the correlation intact under all failure modes.

High-throughput considerations

At manufacturing scale (large plants with multiple lines, each firing events per minute), throughput planning matters:

• Service Bus sizing - standard tier suffices for most deployments; Premium only when message volumes exceed the standard tier's throughput units
• Logic Apps concurrency - configured per workflow, default is 20 concurrent runs; high-throughput flows need higher
• F&O write capacity - custom services are faster than data entities for single-record writes; batching is appropriate when MES aggregates multiple updates
• Dead-letter monitoring - alerts when Service Bus DLQ gets non-zero entries; usually indicates transformation errors that need human review

Reliability patterns

Manufacturing can't afford lost messages. The architecture carries:

• Retry with exponential backoff in Logic Apps for transient failures
• Dead-letter queues for poison messages
• Idempotency keys on custom service calls so retry doesn't double-record
• Correlation IDs flowing end-to-end for cross-system debugging
• Monitoring dashboards on message throughput and latency per queue

Direction-specific patterns

Flows in each direction have different shapes:

MES → D365 (updates ERP from shop floor):

• MES publishes to Service Bus topic
• Logic App subscribes, transforms, calls F&O custom service
• F&O updates inventory, production order status, quality records

D365 → MES (issues work to shop floor):

• F&O business event on production order release
• Event flows to Service Bus
• MES subscriber picks up the work package, distributes to lines

Bidirectional correlation:

• Correlation IDs in headers
• Handshake patterns for critical state transitions (e.g., "order ready" → "order accepted by line")

Where custom code fits

Not everything is Logic Apps. Sometimes:

• Azure Functions for complex transformations Logic Apps can't express cleanly
• Custom services in F&O for writes standard entities don't cover
• Durable Functions for long-running orchestrations (multi-day production runs)

Each has a clear use case. Reach for them when the declarative tool hits a limit, not as default.

What ships with the architecture

A working MES-to-D365 integration has:

• Service Bus queues and topics partitioned by production-order or line
• Logic Apps for each directional flow with transformation logic
• Business events published on production order lifecycle
• Custom services on F&O for inbound writes from MES
• Dead-letter queue monitoring with alerting
• Traceability validation - spot-check recall scenarios quarterly
• Runbook for extending the integration when a new MES module is added

The pattern is architect-grade because manufacturing systems won't tolerate the simpler options. Azure middleware is the supported, scalable, maintainable middle.