为什么 CommerceML 已被弃用以及如何替换它

三个月前，一位熟人给我打电话——一家销售工业油和润滑油的批发公司的老板。目录一万六千个职位，WooCommerce，网站运营七年，流量稳定，订单源源不断。似乎一切都很好。但他没有打电话，因为他的生活很好。 “听着，”他说，“我的目录又坏了。与 1C 的交易半路冻结，一半的货物不见了，图片不见了，价格也旧了。经理手动检查每个项目。我们花了三天时间恢复本应在一个小时内更新的内容。也许有什么东西代替了 CommerceML，或者这是正常的，每个人都这样生活吗？

我没有告诉他“每个人都是这样生活的”。因为这不是真的。这就是那些困在 2005 年（即 CommerceML 格式创建的那一年）的人们的生活方式。是的，您没听错：如今成千上万的在线商店在 1C 和网站之间交换数据所使用的技术是二十一年前设计的。在 iPhone 尚未出现的时代，谷歌刚刚上市，“云”一词意味着一种纯粹的大气现象。这种诞生于完全不同的技术时代的格式仍然是俄罗斯和独联体国家 1C 与在线商店整合的事实上的标准。我认为现在是时候进行一次诚实的对话，讨论为什么会发生这种情况、为什么它不再有效以及该怎么办。

我不是任何特定技术的理论家或传播者。我在实际生产中使用 CommerceML 已经有七年了 - 伴随着它的小故障、中断、重复产品和当我迫切需要在早上邮寄之前修复目录时的不眠之夜。在某些时候，我意识到治疗症状是没有意义的——你需要改变整个方法。这篇文章讲述了我们如何做出这个决定、我们经历了什么以及我们最终得到了什么。如果您也在为 1C 和站点的交换而苦苦挣扎，也许它会为您节省同样三天的紧张目录恢复。

我们如何走到这一步：使用 CommerceML 七年

要了解 CommerceML 为何成为问题，您首先需要了解它的工作原理。这个想法很简单：1C 生成特定结构的 XML 文件 - 产品目录、报价（价格和余额）、图像 - 并通过特殊的 PHP 脚本将它们上传到网站。该站点随后解析这些 XML 文件并更新数据库。听起来很合乎逻辑，对吧？ 2005年，它甚至显得优雅。 XML 很流行，REST API 尚未成为标准，在线商店目录很少超过几千个项目。

问题是世界已经改变，但 CommerceML 没有。格式几乎与创建时相同。是的，有一些小的更新，是的，2.10 版本出现了，但从架构上来说，它仍然是相同的方法：生成一个巨大的 XML，将其完全传输到站点，完全解析它并更新数据库。这就像每次您想要更新一万行 Excel 电子表格中的一行时，通过电子邮件将整个文件发送给同事。听起来很荒谬吗？但这正是 CommerceML 的工作原理。

当我们开始这个项目时，目录包含大约四千项。 CommerceML 完成了这项工作。交流时间大约十五到二十分钟，很少出错，还算过得去。我们使用了最流行的 WooCommerce 插件之一 - woocommerce-synchronization-1c。他诚实地完成了自己的工作：他接受来自 1C 的 XML，对其进行解析，创建产品，更新价格。七年来，它对 WordPress、WooCommerce、PHP 进行了数十次更新 - 每次都会出现问题，但总的来说它是有效的。

然后目录增加到一万六千项。一切都崩溃了。

我们首先遇到的是交换时间。完全卸载目录不再需要二十分钟，而是两到三个小时。有时是四个。此外，CommerceML 的设计方式使得每次交换实际上都是一次完全卸载。是的，形式上有一个“零钱交换”机制，但实际上它的工作原理非常不可靠，以至于大多数 1C 设置都使用完全卸载。想象一下：每天晚上（交易所必须在晚上设置，因为白天它会在服务器上产生负载并降低站点速度）1C 将 16000 个产品上传到总体积约为 1 GB 的 XML 文件中，然后将它们上传到服务器，PHP 脚本尝试处理这一切。 PHP，默认情况下脚本执行时间限制为 30 秒，内存限制为 256 MB。当然，我们增加了限制 - 既增加到 512 又增加到 1 GB - 但这些只是拐杖，而不是解决方案。

二是重复产品。这可能是 CommerceML 最痛苦的问题，并且由于某种原因很少有人公开谈论它。机制是这样的：1C中的每个产品都有一个唯一的标识符（GUID）。上传时，此 GUID 会传输到站点，插件使用它来搜索现有产品进行更新。听起来可靠吗？不管怎样。一旦 1C 中的产品以某种方式发生变化 - 例如，它被移动到另一个组，或者项目类型被更改，或者目录发生某种内部重组 - GUID 可能会发生变化。或者，更糟糕的是，保持不变，但插件找不到它，因为 WordPress 中的元字段不同步。结果：网站上出现重复项。具有相同名称但不同 ID 的产品。当你有 16000 个位置时，手动捕获此类重复项几乎是不可能的。我们发现相同的机油在网站上出现一式三份的情况 - 价格不同，库存不同，网址也不同。这对于SEO来说是一场灾难，对于用户来说是困惑，对于管理者来说是头疼的事情。

第三个问题是图像。 CommerceML 将产品图像与 XML 文件作为二进制附件一起提供。理论上，这很方便——一切都在一个包中。实际上，目录中有 16000 个位置，每个产品都有一到五个图像，卸载量变得巨大。但这还不是主要的事情。主要是图像更新机制。 CommerceML 没有可靠的方法来确定产品图像是否已更改。因此，许多实现只是在每次交换时重新上传所有图像。这些是千兆字节的流量、数小时的脚本工作以及最令人不快的图像的周期性丢失。我们经常发现某些产品的图片在交换后消失了。有时是由于超时，有时是由于解析错误，有时是没有明显原因。管理人员花费数小时手动上传交易所“丢失”的图像。

第四个问题是自定义字段。这最终让我确信我需要结束 CommerceML。我们公司销售工业用油和润滑油——一种具有复杂技术特性的产品。不同温度下的粘度、倾点、闪点、ISO 粘度等级、设备制造商认证、GOST 或 TU、基料类型（矿物、合成、半合成）、密度、应用领域 - 每个产品都有数十个具体参数。在 1C 中，所有这些参数都存储为“附加详细信息”——一个灵活的系统，允许您为任何类型的项目创建任意特征。现在尝试通过 CommerceML 传达所有这些。

CommerceML 具有严格的架构。它可以传输一组特定的字段：标题、描述、文章、组、图像、价格、余额和一些标准详细信息。自定义字段？形式上——通过“属性”和“属性值”的机制。但其实现方式非常不灵活，以至于在实践中，如果不对 1C 侧的处理进行严格的定制，几乎不可能传输复杂的结构化数据（例如不同温度下的几种类型的粘度）。处理的定制需要一名 1C 程序员，每小时费用为 3000 卢布，并且需要解释您网站的结构。并且每次在1C中添加新的产品参数时，这个定制都需要更新。恶性循环。

我记得我们试图向网站添加新属性的那一刻 - 制造商批准（即适合该油的设备品牌列表）。在 1C 中，这被存储为列出公差的表格部分。 CommerceML 根本不知道如何传递表部分。我们花了两周时间与一位 1C 程序员进行谈判，他试图将这些数据“打包”到标准 CommerceML 属性中，创建一个复杂的复合值系统，然后必须在站点端进行解析。结果有效，但非常脆弱，以至于每秒 1C 更新都会中断。

第五 - 大型目录中断。这是一个技术问题，但它具有直接的商业影响。处理来自 CommerceML 的 XML 的 PHP 脚本在单个 HTTP 请求中运行。是的，许多实现将处理分解为块并使用逐步导入，但基本机制保持不变：脚本必须读取 XML、解析它、将其与数据库中的现有产品进行匹配、更新或创建新记录 - 所有这些都在 PHP 的限制内。由于目录中有 16000 个职位，每种产品有数十个属性，因此脚本经常崩溃。有时默默地 - 它只是由于超时而停止工作，使目录处于半更新状态。有时会出现内存错误。有时是由于数据库锁定 - 因为连续一万六千个 INSERT/UPDATE 查询会给 MySQL 带来严重的负载。每一次这样的失败都意味着一些产品被更新，但另一些则没有。某些产品的价格是当前价格，而另一些产品的价格是昨天的价格。其余部分已在某些地方进行了更新，而在其他地方则没有更新。管理人员不知道网站上的哪些数据可以信任。买家订购不再有库存的商品。这些不是技术上的不便——而是金钱和声誉的损失。

当我停止治疗症状时

事情是这样的：很长一段时间我试图分别解决每个问题。重复产品？让我们编写一个脚本来检查重复项。丢失图像？让我们添加日志记录和重新加载。超时？让我们增加 PHP 限制并将交换分成更小的部分。自定义字段？我们会聘请1C程序员进行定制加工。每一次——旧毯子上都会有一块补丁。每个补丁都增加了复杂性，产生了新的故障点并需要支持。曾经，我们有这样一个自定义的交换系统，没有一个新开发人员不经过一周的沉浸就无法弄清楚它。当然，没有文档——因为系统是有机增长的，从一个问题到另一个问题，没有人计划它变得如此复杂。

当我们失去一笔大订单时，转折点到来了。一位企业客户订购了一批液压油——两百升，数量相当可观。该网站显示“有库存”，因为昨晚与 1C 的交易所冻结，余额未更新。但实际上，这种油已经不在仓库里了——它在前一天被运给了另一个客户。经理打电话给客户，道歉，并提出等待交货 - 客户拒绝并去了竞争对手。不是因为我们的产品不好或价格过高，而是因为我们的数据交换系统无法及时更新一种产品的余额。我转念一想：这样的事例有多少是我们没有注意到的呢？有多少顾客看到“有货”，将商品添加到购物车，然后经理给他们回电并道歉？而又有多少人，没有留下命令，就默默离开？

从那时起我开始认真寻找替代方案。不是 CommerceML 的另一个插件 - 它们有很多，但它们都受到格式本身功能的限制。并采用一种根本不同的方法来集成 1C 和网站。在这里我第一次注意到OData。

对于那些还没有接触过它的人：OData 是用于创建和使用 REST API 的标准协议。它由 Microsoft 开发，在世界各地广泛用于访问数据。这里的关键词是“标准”。这不是一家公司的专有格式，也不是针对特定任务的临时解决方案。它是一个开放协议，具有明确的规范，支持分页、过滤器、排序、选择特定字段 - 您期望从现代 API 获得的一切。重要的是：1C 开箱即用地支持 OData。从版本 8.3 开始，任何 1C 配置都可以通过 OData 接口提供对其数据的访问。无需额外处理，无需第三方组件 - 只需在 1C Web 服务器设置中启用 OData 发布，您就可以获得数据库的所有目录、文档和寄存器的成熟 REST API。

当我第一次尝试通过 OData 查询项目目录时，我感到很惊讶。我没有等待 1C 生成 GB 大小的 XML 文件，而是发送了一个 HTTP 请求，一秒钟后就收到了包含前 100 个产品的 JSON。我发送了以下请求并收到了下一百个。每个请求都准确地返回了我需要的数据：不是整个目录，而是特定产品的特定字段，并按特定条件进行过滤。我可以询问“给我液压油组中在过去两个小时内价格发生变化的所有产品”，并在几秒钟内得到答复。使用 CommerceML 尝试此操作。

但我不要理想化。 OData 并不是一个神奇的“做好”按钮。这是一个需要不同集成方法的工具。切换到它不仅仅是用一个插件替换另一个插件。这是1C与站点之间数据交换架构的变化。让我们弄清楚根本的区别是什么。

CommerceML 的工作原理是“批量上传”。 1C 生成数据包（XML 文件），将其上传到站点，然后站点对其进行处理。这是一种批量、单向、离线操作。 1C 不知道现场发生了什么。该网站不知道 1C 交易所之间会发生什么。数据同步有延迟 - 从一小时到一天，具体取决于计划。 OData 的工作方式有所不同。这是一个 API——用于直接访问数据的编程接口。该站点可以随时访问1C并接收最新信息：产品的当前价格、仓库中的当前余额、特性列表、图像。无需等待上传，无需解析XML，无需存储中间文件。数据是实时可用的。

这里出现了大家问我的第一个问题：“1C 上的负载怎么样？如果站点不断拉取 1C 请求，就会杀死数据库！”公平的问题。答：您不需要每次在网站上查看产品时都拉 1C。正确的架构看起来有所不同。产品数据通过 OData 从 1C 导入站点数据库 - 与 CommerceML 完全相同。不同之处在于，使用 OData，您可以增量地执行此操作。不要下载整个目录，而仅请求更改：“给我修改日期大于上次同步时间的产品。”对于包含一万六千个项目的目录，通常每小时更改十到二十个项目，这意味着处理十到二十个条目而不是一万六千个条目。性能差异有两到三个数量级。

现在为此添加 webhooks。 Webhook 是 1C 本身向站点通知更改的一种机制。产品价格有变化吗？ 1C 向网站发送 POST 请求：“产品如此这般，新价格如此这般。”库存有更新吗？另一个 POST 请求。该站点收到通知并在几毫秒内更新特定产品。无需等待预定的交换，无需遍历整个目录来查找更改。网站上的数据是实时更新的——延迟几秒，而不是几小时。还记得因余额过期而导致订单丢失的案例吗？使用 webhook 就不会发生这种情况。余额将在 1C 货物发货时在网站上更新。

我必须说实话：从 1C 设置 webhooks 并不是一项简单的任务。在盒装配置（UT、ERP、KA）中没有这样的机制。您需要在 1C 中编写事件订阅，这将在产品更改时发送 HTTP 请求，或者使用扩展。我们使用一个扩展程序，该扩展程序在处理影响余额和价格的文档时触发，并向网站发送通知。开发花了几天时间，但结果是值得的 - 现在，在 1C 中发布文档后，网站的其余部分会在五到十秒内更新。管理人员不再手动检查网站上数据的相关性。客户不再接到道歉电话。这不仅仅是技术上的改进，更是企业运营方式的质变。

每次打喷嚏都不会中断的映射

1C与站点整合最痛苦的话题之一就是字段的对应关系。在 1C 中，数据存储在网站上的一种结构中，而存储在另一种结构中。 CommerceML 提供了一个严格的方案：产品名称位于“Name”字段中，描述位于“Description”字段中，文章位于“Article”字段中，依此类推。如果您的数据结构与 CommerceML 假设的数据结构稍有不同，就会出现问题。

这是我们实践中的一个具体示例。 1C中，我们的产品“液压油HVLP 46”全称“液压油HVLP 46（200升桶）”，简称“HVLP 46”。 CommerceML 传递一个字段“名称” - 哪一个？默认已满。但在网站上，我们希望在产品标题中显示一个名称，在目录中显示另一个名称，在面包屑中显示第三个名称。使用 CommerceML，为此，您需要更改 1C 中的卸载处理，或者解析站点端的字符串，从全名中提取体积和测量单位。这两种选择都是拐杖。使用 OData，我只需查询两个字段：“Description”和“NameFull”，并将它们映射到所需的 WooCommerce 字段。一个在标题中，另一个在元字段中。没有 1C 定制，没有字符串解析，没有脆弱的正则。

但这是一个简单的例子。有更多细节的情况就更有趣了。正如我已经说过的，在1C中我们的产品有几十个技术特征。粘度、密度、温度、公差 - 所有这些都存储在项目项目的“其他详细信息”表格部分中。每个属性都有一个键（特征类型的 GUID）和一个值（字符串、数字或目录元素的链接）。 CommerceML 不知道如何直接使用此结构 - 您需要一名 1C 程序员来编写将表格部分“扩展”到 CommerceML 属性集中的处理。并且每次1C中添加新的属性时，这个处理都需要更新。

OData 则不然。 OData 以对象的嵌套数组形式提供附加详细信息 - 每个对象都有一个键和一个值。在网站方面，我们只需读取此数组并将每个属性映射到相应的 WooCommerce 属性。有趣的部分来了——自动发现。当我们的模块第一次通过 OData 连接到 1C 时，会自动扫描数据库元数据，查找所有类型的产品特征并提供映射：“在 1C 中发现了 99 个独特特征。它们就是。我应该创建哪些作为 WooCommerce 属性？什么样的元字段？我应该忽略哪些？您设置一次匹配，然后它会自动工作。您是否向 1C 添加了新属性“NAS Cleaniness Class”？在下次同步期间，该模块将检测新属性并提供在站点上为其创建属性，无需 1C 程序员，无需更新处理，无需手动配置。

我们在 1C 数据库中发现了 99 个独特特征，并在 WooCommerce 中根据它们创建了 121 个分类法。为什么是 121 而不是 99？因为某些特征是多值的 - 例如，“制造商批准”包含单个产品的多个值 - 对于此类特征，创建具有多项选择功能的单独分类法会更方便。对于 CommerceML，这种灵活性根本不存在：您可以获得上传处理提供的内容，并且无法动态更改映射逻辑。

我还想谈谈可定制性。在 CommerceML 中，映射被融入到插件代码或 1C 处理中。如果您想更改 1C 字段在网站上的位置，您需要进入 PHP 代码或 1C 配置。对于 OData，映射是站点管理面板中的一项设置。您会看到一个表格：左侧是 1C 字段，右侧是 WooCommerce 字段。拖动、更改、添加转换规则（例如，“如果“油类型”字段的值为“矿物”，则将值“矿物”写入“基本类型”属性”）。更改会立即应用，无需部署代码，无需重新启动交换。这是目录管理员可以做的事情，而不仅仅是开发人员可以做的事情。

我一直想知道为什么 CommerceML 尽管有其局限性，但仍然是标准这么久。我得出的结论是，原因是惯性。 CommerceML 内置于标准 1C 配置中。它“开箱即用”——打开交换机，指定站点地址，按下按钮。无需了解API，无需编写代码。对于一个只有几百种产品的小商店来说，这确实足够了。但是，当目录增长时，当复杂属性出现时，当业务需要实时数据相关性时，CommerceML 的局限性开始导致成本增加。真正的金钱——表现为订单丢失、经理的体力劳动以及 1C 程序员的工时报酬。

实践中的过渡是什么样的

我知道读者此时可能会想，“好吧，OData 比 CommerceML 更好，我明白了。但是怎么走？我已经建立了一个交换，产品已同步，目录正在运行。我们真的需要拆除所有内容并重建它吗？”

不，没有必要。这也许是支持 OData 方法的主要论点：过渡可以逐步完成。您不会在第一天就禁用 CommerceML。您并行连接 OData 模块、设置映射、运行测试同步、比较结果 - 并且只有当您确定一切正常时，才禁用旧交换。

这正是我们所做的。第一阶段是连接到 OData 1C 并迁移现有连接。我们的 WordPress 数据库中有 16,844 个产品，每个产品都有一个元字段_id_1c使用 CommerceML 的旧 ID。该模块检查了所有产品，通过 OData 将它们与 1C 中的记录进行比较，并在单独的表中创建映射 - 18,850 条记录（包括变体）。这个过程大约持续了两个小时，但却是一次性操作。

第二步是配置增量同步。我们将 OData 模块配置为仅更新已更改的产品。每隔 15 分钟，模块就会询问 1C：“自上次检查以来，哪些产品发生了变化？” OData 允许您在一行中提出这样的请求 - 按修改日期进行过滤。响应是一个包含 10 到 20 个产品的 JSON，这些产品会在几秒钟内在 WooCommerce 中更新。与此相比，通过 CommerceML 上传完整目录需要三个小时。

第三阶段是为关键数据设置 Webhook。现在，价格和余额可以通过 1C 的 POST 请求立即到达网站。这需要在 1C 方面进行一些修改 - 在过帐销售单据、收据和价格调整时触发的扩展。但这个修改完成一次，然后就自动起作用了。

第四阶段 - 禁用 CommerceML。我们在启动 OData 模块一个月后执行了此操作，当时我们确信所有数据均已正确同步。我们停用了旧的 woocommerce-synchronization-1c 插件并禁用了 1C 中的交换处理。该网站继续工作，就像什么都没发生一样——因为数据现在以不同的方式出现。

我们得到了什么结果？我们来看一下具体的数字。完整目录同步的时间已从三到四个小时减少到二十分钟 - 而仅在初始设置期间或在 1C 目录结构发生重大更改后才需要完整同步。在正常模式下，增量更新需要几秒钟的时间。更新价格和余额的延迟已从一天（每天交换一次）减少到几秒（webhooks）。三个月内产品重复次数为零。因为 OData 使用稳定的 1C 标识符 (Ref_Key)，当产品在组之间移动或其属性发生变化时，这些标识符不会发生变化。丢失图像的数量为零。因为图像是通过单独的端点加载的，并检查了文件哈希，并且仅在发生实际更改时才更新。在过去六个月中，致电 1C 程序员定制交换的次数为零。因为映射是在站点管理面板中配置的，并且自动发现本身会找到新的详细信息。

但除了数字之外，还有另一个难以量化的变化，但可能更为重要。经理们不再害怕目录。以前，每个工作日的早上都会检查：“兑换成功了吗？一切都到位了吗？价格是最新的吗？现在它们可以正常工作了。网站上的数据始终是最新的，产品不会丢失或重复，属性会自动更新。这节省了以前用于手动检查和纠正兑换错误的大量工作时间。

另外，我想谈谈设置向导 - 我们称之为向导。 CommerceML 如此受欢迎的原因之一是其易于初始设置。我在 1C 中打开了交换机，指定了地址 - 它可以工作。对于OData来说，入门门槛较高：需要在1C Web服务器上启用OData发布、配置用户权限、了解端点。我们花了很多时间试图降低这个阈值，最终创建了一个分步向导，引导用户在十五分钟内完成整个设置。第一步是提供 OData URL 和凭据。向导检查连接，显示 1C 版本和数据库名称。第二步是选择同步参考书（术语、特性、测量单位）。该向导扫描 1C 元数据并显示可用实体。第三步是配置字段映射。该向导提供默认映射（涵盖 90% 的情况）并提供更改它的机会。第四步是运行十个产品的测试导入并检查结果。第五步是运行完全导入。所有。十五分钟，没有1C编程器，没有处理设置。

说实话，当我们向第一批用户展示此向导时，反应是出乎意料的。我预计会出现诸如“1C 中的上传设置在哪里？”之类的问题。或“我如何更改交换处理？”相反，人们会问，“等等，就这些了吗？我只是指明了地址，它自己找到了我的货物？哪里有问题？没有问题。OData 是一个标准 1C 接口，以结构化格式提供数据。无需在 1C 端配置任何内容（除了启用 OData 发布和创建具有必要权限的用户之外）。所有设置都在站点端，在熟悉的 WordPress 管理面板中。

关于缺点的诚实对话

如果我将 OData 方法作为没有缺点的解决方案来呈现，我就是不诚实的。它有其局限性，应该公开讨论。

首先，1C 中的 OData 并不理想。它比直接查询 1C 数据库慢，因为它通过 HTTP 工作并经过业务逻辑层。对于针对包含数十万个元素的目录的查询，这可能会很明显。我们通过分页来解决这个问题 - 我们请求 300 条记录中的部分数据，并通过操作计划程序（WooCommerce 中内置的任务计划程序）处理每个部分。这使您可以随着时间的推移分散负载，并且不会阻止 1C 或站点。

其次，并非所有数据都可以通过 OData 同样方便地访问。例如，下级目录（如UT中的“Item Characteristics”）可能不支持标准过滤和字段选择操作。我们面临这样一个事实：带有参数的请求$选择或$过滤器将 HTTP 400 返回到特征目录。我必须下载所有完整记录并在 PHP 端进行过滤。并不重要，但您需要了解这些功能。

第三，图像。 1C 中的 OData 不通过标准端点发送附加文件的二进制数据/$价值。至少它在我们的配置中不起作用。我必须使用额外的扩展（HTTP 服务）来接收图像文件。这在技术上并不困难，但需要在 1C 方面进行最少的修改。

第四，webhooks 还需要 1C 改进。典型的配置没有用于在数据更改时发送通知的内置机制。你需要写一个扩展。对于一个熟悉1C的人来说，这是一个需要几个小时的任务，但对于那些只做网站工作而不接触1C的人来说，这是一个额外的障碍。但是，Webhooks 是可选的：您只能通过 OData 进行增量同步，只是数据更新延迟稍长一些。

第五 - OData 要求在 1C 服务器上发布 Web 服务。这意味着必须将 IIS 或 Apache 配置为向 1C 数据库提供 HTTP 请求。在大多数 1C 服务器上，这已经完成（例如，对于通过 Web 的瘦客户端），但在某些情况下未配置 Web 发布。然后您需要让 1C 管理员参与初始设置。

所有这些限制都是真实存在的，但它们都无法抵消 OData 相对于 CommerceML 的优势。这就像将电动汽车与蒸汽机车进行比较：是的，电动汽车需要给电池充电，而且充电站仍然比加油站少。但这并不意味着你需要继续乘坐蒸汽机车，因为它的柴火可以在任何森林中找到。

另一个经常被问到的问题是：“如果我有 Bitrix/OpenCart/自定义网站，而不是 WooCommerce，该怎么办？” OData 是一个通用协议。它不与 WordPress 或 WooCommerce 绑定。任何可以发送 HTTP 请求和解析 JSON 的平台都可以使用 OData 1C。我所说的特定模块是作为 WooCommerce 插件的一部分实现的，但原理是相同的：REST API 而不是 XML 文件、增量更新而不是完全卸载、自定义映射而不是严格的模式。如果您使用其他平台，请寻找类似的解决方案或自行实施集成，因为 OData 提供了干净且有记录的 API。

如果从另一面——1C 加盟商和 1C 开发商的角度来看呢？我与几个 1C 合作伙伴进行了交谈，他们对 OData 方法的反应不一。一方面，他们了解 CommerceML 的局限性 - 他们每天都会经历这些局限性。另一方面，CommerceML 是他们的面包和黄油。定制交换处理、设置上传、修复同步错误 - 这些都是定期付费时间。向 OData 的过渡剥夺了他们的部分收入，因为客户可以自己设置集成，而无需 1C 程序员。这不是阴谋或恶意——只是经济现实。但对于支付集成费用的企业来说，这是支持 OData 的理由：减少对承包商的依赖、降低支持成本、更多控制。

你知道整个故事最让我惊讶的是什么吗？对于任何对 Web 技术稍有了解的人来说，OData 的非技术优势都是显而易见的。我很惊讶这种转变花了这么长时间。我们与 CommerceML 斗争了七年，知道它的局限性，每次我们都找到一个不改变我们方法的理由。 “现在还不是时候”，“它有效，别碰它”，“如果情况变得更糟怎么办。”维持现状的经典原因。直到某个特定订单的丢失使得不作为的代价变得显而易见时，我们才最终采取了冒险行动。

还有一个方面很少被谈论，但在实践中却非常重要 - 调试和诊断问题。当 CommerceML 交换中出现问题（并且经常发生）时，诊断就会变成侦探故事。一个数十兆字节的 XML 文件，您需要在其中找到问题节点。 PHP 日志仅显示“解析错误”，但未指定具体位置。 1C 日志写着“交换已完成，但有错误” - 以及什么样的错误，请自行找出。我们花了几个小时试图找出为什么特定产品没有更新或为什么特定产品组丢失了图像。有时，原因被证明是微不足道的 - 例如，产品名称中的特殊字符破坏了 XML 解析器。有时它很神秘，与文件处理的顺序或服务器时区有关。

诊断对于 OData 来说是透明的。您发送特定请求并收到特定响应。错误？它位于具有清晰代码和描述的 HTTP 响应中。产品未更新？查看日志中的请求和响应 - 一切都可见。我们将每个同步操作记录到一个单独的表（wpaic_1c_sync_log）中，其中包含详细信息：什么产品、更新了哪些字段、花费了多长时间、是否出现错误。管理员可以进入管理面板查看每个产品的同步历史记录。这不仅仅是方便 - 这是对流程的另一个层面的控制。

这是过渡后我注意到的其他事情。当网站上的数据始终是最新的，当交换可靠且可预测地运行时，整个团队对网站的态度就会改变。此前，该网站被视为“有时会显示正确数据的展示柜”。经理们在 Excel 中重复信息，因为“该网站不可信”。客户打电话询问是否有货，因为“网站上可能不是最新的”。现在该网站是事实的来源。经理在与客户沟通时会参考它。顾客自行下单，无需回电。管理层查看网站上的销售分析，知道数据是可靠的。这种变化很难高估——它影响整个业务的效率，而不仅仅是IT部门的工作。

我还想解决安全问题，因为它在有关替换 CommerceML 的讨论中经常出现。 “OData 允许通过互联网访问 1C 数据库 - 这是一个安全漏洞！”这是一个合理的担忧，但让我们弄清楚这一点。 CommerceML 还通过 HTTP 运行 - 站点上接受来自 1C 的 XML 的相同 PHP 脚本可以从 Internet 访问。通常它仅受到以明文形式传输的登录名和密码的保护。 OData 可以更安全地配置：具有强制 TLS 的 HTTPS、通过基本身份验证或 OAuth 进行身份验证、通过 IP 地址限制访问、具有最小权限的单独 1C 用户（仅读取必要的目录）。此外，您可以在 1C 和网站服务器之间使用 VPN，完全关闭 OData 端点的外部访问。所以从安全的角度来看，OData是前进了一步而不是倒退了。

我确信在三到五年内 CommerceML 将变得像今天的 FTP 文件上传到托管或电子表格布局一样不合时宜。技术在发展，业务需求在增长，二十一年前为不再存在的世界创建的格式将不可避免地让位于现代方法。唯一的问题是你是否现在就进行这种转变，或者等到你失去“大订单”时再进行转变。

如果您当前正在使用 CommerceML 并已在本文中发现了您的问题，那么您已准备好进行更改。没有必要害怕过渡。没有必要在一天内破坏有效的方法。从小处开始：在 1C 服务器上启用 OData，尝试发送第一个请求，查看 JSON 格式的目录数据。您将看到您的产品、您的价格、您的详细信息 - 仅以方便、可读、现代的格式显示。然后您就会明白，千兆字节大小的 XML 文件将不会再出现。

我们通过 OData for WooCommerce 将所有经验（包括积极的和消极的）收集到 1C 集成模块中。设置向导、自动发现属性、增量同步、Webhook 支持、灵活的字段映射 - 我在本文中讨论的所有内容。如果您有兴趣了解其实际工作原理，请查看我们网站上的模块页面。如果您对 1C 和 WooCommerce 的集成有疑问，请写信，我总是很乐意分享我的经验。因为每一个脱离 CommerceML 的商店都会让整个电子商务市场变得更加现代化。