操弄Dynamics 365 Supply Chain Management者，率皆于工场设专司之制造执行系统（MES）。生产之令更新，库藏之动，质验之测，及追踪之数据，皆于其间络绎不绝。其合须速（工场之运以秒计，非以时计），须畅（峰时每分钟数百事），须信（失讯则失追踪）。

评估之中，有三法相合。其二，已载其败状。

其不适于制造之选

每夜批处理之务，依数据管理之构。此构为量移数据而设，非为实时传讯。生产之令，竟在D365知之数时之前已毕。实时之库存观，恒有迟滞。可溯之数据，至批次已发之后方至。

循环式定制OData轮询，每数秒即询MES。此法徒增轮询之冗，无减延迟之益，且MES系统多未设以应繁重轮询之能。复添定制代码之倚，需勤加修持。

于MES数据库设库级触发器，直推至F&之数据库。尽废可持之能。D365 F&O乃一托管平台——直书数据库者，非所宜也，亦非可升之安，每微软更制其式，则必溃矣。复酿一危局于安（MES得专权，可书F&O之数据库乎？）。

唯 Azure 中介，介于二系统间，乃合乎所求之策。

此乃 Azure 之原生法式。

逻辑应用或服务总线为MES与D365之间之中介，辅以F&D365 之商务活动。

每物所为之事：

Azure服务总线，为保送递送、有序消息而设。生产顺序状态更新，库存移转，质量测试结果，皆流经服务总线队列，依生产顺序以先进先出之序排列。

Azure逻辑应用，主于分支与变通。MES发来拣选完毕之讯，触发逻辑应用，化其负载，更D365之库，复引生产流转之讯回MES。

F&O商贾之讯，主于D365之侧发布。生产之令既立，既发，既成于F&O，商業之會，發於服務巴士或事務網格。MES之訂閱者，取之。

定製服務於F&O，為內入者——當MES有狀態之變，D365須記之，則邏輯應用（或函數）呼定製服務之端點於F&O。定製服務，為低延遲之鎖定寫，異於數據實體之批處理。

可追溯架构

可追溯性，于制造尤为具体——监管者与顾客须知原材何物入何成品批次。D365之批次追踪，合MES之车间批次记录，以成全然源流。此集成之效，在：

• MES 追踪实体之动（机X处理批Y于时Z）
• D365 载录 ERP 层级批次（生产订单 B 消耗原料批次 A 生成成品批次 C）
• 整合关联二者，依批次号与生产订单引证
• 追溯情境可自售出成品溯至源材，或自疑材料推及受影响成品

此整合非仅移数据，乃存关联于万变之故也。

高通量之考量

于制造之规模（大厂多线，每分钟发诸事），通量之筹谋，实属要务。

• 服务总线规模配置——标准层级足矣应对多数部署；唯当消息量逾标准层级之吞吐单位时，方需选用高级层级
• 逻辑应用并发配置——依工作流分别设定，默认为二十并发运行；高吞吐量流程需更高配置
• F&写入能力——定制服务较数据实体于单记录写入为速；批量处理适于MES聚合多更新
• 死信监控——当服务总线DLQ得非零条目则警；通常示转换之误需人检视

可靠性模式

制造业不容消息之失。架构承：

• 逻辑应用遇瞬断则指数退避重试
• 毒消息置入死信队列
• 自制服务调用加幂等键以防重录
• 关联ID贯穿全程以助跨系调试
• 监测各队列吞吐与迟滞之仪表

指向性特定之范式

每向之流，形各异焉。

MES至D365（自车间更新ERP）：

• MES向服务总线主题发布
• 逻辑应用订阅，转换，调用F&客之服也
• 非也。&更新库存、生产订单状态、质量记录

D365 → MES（问题工作至车间）：

• 非也。&生产订单下达之商务事
• 事流于服务之枢纽
• MES订阅者取工单，分派于线

双向关联：

• 标题中关联ID
• 关键状态转换之握手模式（如“指令备妥”→“指令为线所纳”）

自制代码之适位

非尽为逻辑应用。时有：

• Azure Functions以达复杂之变通，逻辑应用难洁其辞
• F&O中定制之服务，为标准实体所不及之写入
• 持久函数用于长时序编排（多日生产流程）

各有所用。当陈述式工具遇限，方取之，非为常法。

何船与架构偕行

一有效之MES至D365之整合具：

• 服务总线队列与主题，依生产次序或线路分区
• 每向流应用逻辑，具变通之理
• 生产订单生命周期中所发布之商务活动
• 定制服务于F&愿得MES之入书也
• 死信队列监控与告警
• 溯源验证——每季抽查召回场景
• 新增MES模块时扩展集成之运行手册

此法为架构之典范，盖因制造系统不容简略之选。Azure中介件乃所支持、可伸缩、可维护之中道也。