D365运输引擎的元数据，为什么与内部数据来源有关

运输管理引擎都在处理运输相关计算，并不表示它们必须用同一种方式解释数据。Dynamics 365 Supply Chain Management官方说明，将依赖应用内部数据的引擎与从外部系统取得计算数据的引擎分开讨论。[1] 理解元数据在这里的作用，需要先看数据来自哪里，而不是只看引擎名称是否含有运价或里程。

对依赖Supply Chain Management中定义数据的引擎，文档说明可以存在不同的数据结构。运输管理系统允许不同引擎使用同一组通用物理数据库表，而元数据用于支持运行时正确解释这些表中的引擎数据。也就是说，共用物理表不意味着所有引擎都把同一内容理解成完全相同的业务结构；解释所依据的结构信息还有独立位置。

这项描述让“数据存放在哪里”与“数据按什么结构被理解”形成清楚联系。数据库表是承载数据的对象，元数据则服务于引擎解释。本文据此作出的资料分析是，看到不同引擎共用表，不应立即推断它们没有结构差异；反过来，看到不同结构，也不能只凭这点断言它们各自必有一整套独立物理表。原文提供的正是这两者可以共同存在的组织方式。

针对“是否所有引擎配置都需要元数据”，原文回答是否定的。从外部系统获取运价计算所需数据的引擎，不需要上述这类元数据；这些数据通常可通过网络服务从外部承运系统获得。这里的否定限定在该页讨论的内部数据解释机制，不是说外部数据无需任何格式、说明或对应关系。本篇也不把一种可采用的取数方式写成任何企业已经接通外部承运商。

紧接着的Note进一步限制了产品范围：随Supply Chain Management交付的运输管理引擎依赖应用内部取得的数据，连接外部系统的引擎并不包含在其中。因而，“文档讨论外部引擎”与“标准交付已经提供外部连接”是两项不同事实。前者说明扩展模型中的一种情形，后者需要实际产品范围支持，不能省略这条注释。本文只解释数据来源与元数据之间的关系，没有配置引擎、开发连接、计算真实运费或核验合同。原页的最后更新日期不作为首次发表日期；保留交付范围，才能让技术介绍准确落在所读文档上。