这些也是我们最喜欢回答的问题 – EDI 的世界是复杂、不透明和神秘的，但它也非常强大，支撑着世界经济的很大一部分。
问题在于，没有任何好的、以开发人员为中心的资源可以帮助从头开始理解 EDI。结果是，这个非常丰富的生态系统被锁定在更广泛的技术世界中正在发生的全面变化之外。
我们有幸将许多人从零培养到对整个 EDI 图景如何组合在一起的扎实工作知识。从最高级别开始并随着你的进展变得越来越具体。
贸易
在最基本的层面上，地球上有成千上万的企业;这些企业为最终消费者提供各种各样的商品和服务。由于很少有企业拥有资源或希望完全自给自足，因此他们必须在彼此之间交换商品和服务才能交付成品。这种机制称为 trade(贸易)。
当两家企业希望进行交易时，他们必须交换某些商业文件或交易，其中包含开展手头业务所需的信息。有数百种可以想象的交易类型适用于各种情况;有些在许多行业中很常见，例如采购订单和发票，有些则特定于某一类业务，例如装载或提单，它们仅与物流有关。
企业过去常常交换纸质交易并将这些交易记录到一本称为分类账的手写簿中（这就是为什么我们将会计称为“账簿”，将使用会计系统工作的人称为“簿记员”），但现代企业使用一个或多个软件应用程序（称为业务系统）来促进运营。业务系统有多种类型，从 Oracle、SAP 和 NetSuite 等通用软件套件到服务于某些特定行业的垂直特定产品，例如用于医疗保健、农业或教育的专用系统。
每个业务系统使用不同的内部事务格式，这使得无法直接将事务从一个业务系统导入到另一个业务系统;即使两家企业都使用完全相同的 SAP 版本（比如 SAP ERP 6.0），一连串的配置和自定义选项（每个选项都会影响系统的事务格式）也使得直接互操作性的可能性极不可能。这些情况需要在将数据从一种格式转换为另一种格式之前，然后再摄取到新系统。
数据转换
最流行的数据转换方法是人工数据输入。客户 A 在 NetSuite（其业务系统）中创建采购订单 n，并通过电子邮件将采购订单 n 的 PDF 发送给供应商 B。供应商 B 雇用的文员将采购订单 n 中的数据输入到 SAP（其业务系统）中。职员根据需要将数据从一种格式“映射”到另一种格式 – 例如，如果客户 A 的 PDF 包含一个名为“PO No.”的字段，而供应商 B 的业务系统需要一个名为“Purchase Order #”的字段。
人们很聪明——你可以把一个人想象成有点像 AI，只不过它实际上是有效的——并且能够在几乎不需要培训的情况下即时处理这类映射。但是手动数据输入成本高昂、容易出错，并且在大批量时不切实际，因此企业通常选择寻求某种交易自动化或贸易合作伙伴集成方法，以便以编程方式摄取交易并避免手动数据输入。
由于每个企业都有多个贸易伙伴，并且每个贸易伙伴都在不同的业务系统上运营，因此这些交易的“点对点”集成（即，将沃尔玛的内部数据库格式直接映射到 QuickBooks JSON API）将要求接收者详细了解许多不同的交易格式——例如，一家公司向在 NetSuite 上运行的三个客户销售产品。 SAP 和 QuickBooks 分别需要了解 NetSuite XML、SAP IDoc 和 QuickBooks JSON。保持对如此多系统的熟悉是不切实际的;为了避免这种复杂性的爆炸式增长，企业转而使用普遍接受的中介格式，这些格式被广泛称为电子数据交换 （EDI）。
EDI
EDI 是许多用于交换企业对企业交易的不同“标准化”框架的总称，但它通常与两个最流行的标准同义使用 – X12（主要在北美使用）和 EDIFACT（在整个欧洲普遍使用）。重要的是要注意，EDI 并不是为了解决 B2B 交易交换的所有问题而设计的;相反，它旨在仅消除贸易伙伴能够理解其每个贸易伙伴的内部语法和词汇的不切实际的要求。
像 X12 和 EDIFACT 这样的框架提供了高度结构化、有主见的替代方案，旨在减少与贸易伙伴成功集成所需的知识表面积，而不是使用许多不同的语法（例如 JSON、XML、CSV）和词汇表（例如 PO 编号和采购订单 #）。符合给定标准的所有文档都遵循该标准的语法，从而允许该标准的采用者对同样采用该语法的所有贸易伙伴仅使用一种语法。
此外，标准会尽可能减少词汇和字段位置的变化。例如，X12 标准具有一个元素类型 92，它枚举了采购订单类型代码;枚举值 Dropship 反映了 X12 的选项，即枚举值为Drop ShipDrop ShipmentDropship的 PO，这限制了被接收方可能必须考虑的词汇。同样，X12 已将 850 采购订单的 BEG03 元素（即 850 采购订单事务集中 BEG 段的第三个位置提供的值）指定为指定采购订单编号的适当位置。这减轻了将交易映射到接收方业务系统或从接收方的业务系统映射的一些负担;只需映射一个代发值和一个 PO 编号位置。
当然，绝大多数字段都无法标准化到这种程度。以采购订单上行项目的产品标识符为例 – 虽然 X12 指定应使用 850 采购订单的 PO107 元素来指定产品标识符值，但该标准不可能强制要求应使用哪种类型的产品标识符。一些公司使用 SKU（库存单位），而另一些公司使用零件编号、UPC（通用产品代码）或 GTIN（全球贸易项目编号）;总而言之，X12 标准指定了一个字典，其中包含 544 个不同的可能产品标识符值，这些值可以在PO106元素中填充。
标准的问题
我们在这里看到的是，虽然标准可以对文档的结构和字段的命名有主见，但它不能对业务交易的内容有主见——业务交易的内容是由业务本身的特质决定的。如果标准没有提供足够的灵活性来说明特定企业的具体情况，企业将选择不加入该标准。因此，像 X12 这样的标准并没有提供交易的固执己见的定义——它提供了一个包含所有可能的商业价值的结构化超集。
中介格式（即 EDI）通过限制企业必须与广泛的贸易伙伴合作必须理解的不同格式的数量，使生活变得更加轻松;一个向数十家美国零售商销售产品的美国品牌可能只需要使用 X12 格式。但是，该品牌仍然需要考虑每个零售商使用 X12 的不同方式。同样，X12 只是一本可能值的字典——因为沃尔玛和亚马逊以不同的方式（和不同的业务系统）经营他们的业务，它们对 X12 中介格式的实现也会有所不同。
一个简单的例子是，沃尔玛允许客户在订单级别添加礼品赠言（“生日快乐 – 圣诞快乐！”），而亚马逊允许其客户在订单项级别指定礼品赠言（订单项 #1 上写着“生日快乐”，订单项 #2 上写着“圣诞快乐！礼品信息实施的这种差异意味着，同时向亚马逊和沃尔玛销售产品的品牌在将相应字段“映射”到其业务系统时，需要考虑这些差异。
这种每个贸易伙伴的细微差别是无法避免的——因为不同的企业以不同的方式运作，所以不太可能存在单一的、规范的、极端固执己见的表示，比如采购订单。换句话说，每个贸易伙伴的设置过程是由固有的复杂性驱动的，即手头问题不可避免的情况所必需的复杂性。而且，由于诸如此类的字段映射会影响现实世界的事务，因此无法通过概率机器学习方法完成它们;例如，将“发货人地址”映射到“发货地址”将导致订单被运送到发货人自己的仓库，而不是客户各自的地址。虽然构建企业对企业集成的方法有很多，但任何解决方案都必须考虑涉及每个贸易合作伙伴、人工驱动的字段映射的设置过程。
EDI 中还有其他固有的复杂性领域。由于业务会随着时间的推移而变化，因此企业各自业务系统的配置也必须发生变化;例如，零售商将 DHL 添加为运输选项，而以前只提供 FedEx。必须将这些更改传达给贸易合作伙伴，以便可以适当地更新字段映射;由于此类通信和更新涉及人类的“最大努力”，因此其中一定比例的通信和更新将被遗漏或错误完成，从而导致后续交易的集成失败。即使没有业务间的更改，也会发生错误 – 例如，业务系统的 API 密钥可能会过期，或者系统可能会遇到间歇性停机。此类错误需要审查、重试和解决。正如每个解决方案的设置过程始终需要每个贸易伙伴、人工驱动的字段映射一样，每个解决方案还必须提供管理控制平面上的配置更改和数据平面上的间歇性错误的功能。
商业现状
因此，商业宇宙的“物理定律”如下：
- 有许多企业，这些企业必须进行企业对企业的贸易，以提供最终产品和服务;
- 这些业务在大量但数量有限的业务系统上运行;
- 由于业务实践的异构性，这些业务系统提供的配置选项会导致不同配置的数量不受限制;
- 配置的异构性使得不可能采用单一的统一格式，因此需要每个贸易伙伴的设置过程;
- 不正确设置的业务影响需要人工参与设置;
- 业务不是静态的，因此配置会随着时间的推移而变化，再次需要人工输入;
- 业务系统并非完全可靠;
- 因为人工输入和业务系统都不是完全可靠的，所以间歇性错误会持续发生;
- 必须解决错误才能维持可靠的业务流。
任何通用业务集成系统都必须考虑所有这些约束。所谓的充足多样性定律很好地总结了这一点：“为了确保稳定性，控制系统必须至少能够表示它所控制系统的所有可能状态。如果做不到这一点，它必须以某种方式限制范围——例如，仅处理交易类型、行业、业务系统或用例的子集。但是，由于限制范围在定义上意味着限制市场规模，因此任何足够雄心勃勃的开发业务集成系统的努力都不能限制范围：它必须提供机制，以处理任何行业、任何行业、300+ 企业对企业交易类型、任何格式的任何配置，并为未来可能发展的任何演变做好准备。
这就是开发通用业务集成系统的挑战。
一个熟悉的问题
好消息是，这种情况（一组无限的异构、复杂、任务关键型、Web 规模的使用案例）并不是业务集成所独有的，它们反映了更广泛的软件开发世界中的情况。
如果不是着手创建用于开发业务集成的软件应用程序，而是着手创建用于开发软件应用程序的软件应用程序，则会遇到相同的挑战 – 要继续遵循充足多样性定律，用于开发软件的系统需要能够表示它希望开发的软件的所有可能状态。
当然，这是不合理的 – 设计单个软件应用程序来开发软件应用程序是不可行的。像 Amazon Web Services 这样的成功平台不是单个应用程序，而是提供了一系列许多小型、相对简单的构建块 – 基元 – 这些构建块几乎可以组合成代表任何更大的应用程序。因此，可以将 AWS 视为用于开发软件应用程序的软件应用程序目录。使用 AWS 的一系列产品，今天的软件开发人员可以使用更少的代码和对基本概念的了解来构建 Web 规模的应用程序。
EDI 的适用场景
三种类型的客户场景：
- 需要构建集成以支持其自身业务的客户（例如，希望与供应商交换 EDI 文件的电子商务零售商）;
- 需要将 EDI 功能构建到自己的软件产品中的客户（例如，希望将自助 EDI 集成嵌入其平台的数字货运代理、运输管理系统或履行提供商）;
- 需要对其技术堆栈进行现代化的 EDI 提供商或 VAN（例如，希望替换传统基础设施或工具的零售特定 EDI 软件提供商）。
评论 (0)