把 BigCommerce 与 SAP 正确地连起来。

在这个问题回答之前，这个项目无法被估算，因为这三者是不同的产品，集成入口也不同。谁不问就报出「一套 BigCommerce 对接 SAP 的集成」的价格，报的就是一个猜测。

BigCommerce 是容易的那一端。它提供有文档的 REST 与 GraphQL API、Webhook、价格表与客户组，B2B Edition 还增加了企业账户与层级。它表现得像一个现代 SaaS 产品，因为它就是。

决策都在 SAP 这一侧，而实际上只有四条路：

• BAPI 与 RFC。经典路线；在 ECC 上，它往往是唯一能触达你所需业务逻辑的方式。同步、快速，但需要一条通往你系统环境的 RFC 连接，这意味着要和管 Basis 和防火墙的人谈。
• IDoc。异步单据。用于订单与发票这类可以容忍几分钟延迟的流程非常合适；用于「这个客户此刻买这件商品是什么价」则完全不对。很多表现不佳的商城之所以不佳，就是因为有人拿 IDoc 去做定价。
• 通过 SAP Gateway 的 OData。现代入口。在 S/4HANA 上是标配，在 ECC 上只要有人配置也能用。如果可以选，这就是你该待的地方：它是 HTTP、可缓存，而且每个开发者都已经懂它。
• 中间件。SAP Integration Suite，或 Boomi、Celigo、Jitterbit、MuleSoft 这类第三方 iPaaS。它增加成本和一跳，换来的是重试、数据转换、监控，以及一个安放「两边系统都不该拥有的逻辑」的地方。

对多数 B2B 项目而言，诚实的默认选择是：凡是买家要等的，走 OData 或 BAPI；可以异步的单据流，走 IDoc；前面再放一层中间件，别让慢的 SAP 变成慢的商城。把这件事早点定下来，架构就已经定了大半。

把架构图撤掉，每一个 B2B 商城向它的 ERP 问的都是同样六个问题。把这六件事做对，就是这个项目本身；其余都是装饰。

1. 这是谁。登录账号背后的 SAP 客户编号，并在售达方、送达方与付款方不一致时分别识别；而在 B2B 里，它们经常不一致。
2. 他付多少。这个客户、这个物料、这个数量、今天的净价。这是最难的一件，下面单独用一节讲。
3. 他能拿到多少。不只是现有库存，而是可承诺量，并且要按实际供货给该客户的工厂来算。
4. 下单。并且返回一个真实的 SAP 销售单据号，而不是一个 BigCommerce 订单 id 加上「稍后会同步」的承诺。
5. 货到哪了。交货与发运状态；承运商有回传时，还要带上运单跟踪。
6. 他欠多少。发票历史、未清项、信用额度状况。正是这一项把商城变成自助账户门户，也正是买家真正登录进来要看的东西。

第六项被低估得最厉害。多数 B2B 买家进你的站不是来逛的，而是来把买过的东西再订一遍，以及看看自己欠多少。

如果本页只值得读一节，就是这一节。

SAP 并不存着一个「某客户 + 某物料」的价格供你直接查。它是在你发问的那一刻算出来的，用的是条件技术：由条件类型组成的定价过程，经由存取顺序去匹配条件记录，再按有效期筛选。一个客户的净价可能取决于他的价格表、合同、物料组、订购数量、阶梯价、促销、附加费、运费与税，并按照贵公司多年来配置出的特定顺序求解。

你没法在商城里把这一套重新实现一遍，也不该去试。我们被叫去救火的每一次，故事都一样：有人把条件记录导进 BigCommerce 的价格表，对大多数客户是对的，而那些例外变成了一股安静的错单流，几周后被财务发现。

正确的做法是去问 SAP。让 SAP 来给购物车定价，无论是通过定价 BAPI、模拟销售订单，还是为此专门建的 OData 服务，然后原样展示它返回的结果。接着，围绕延迟做工程，而不是围绕真相做工程：

• 大胆缓存，并且按客户缓存。一个价格对那个客户在一段可接受的窗口内是有效的。把它缓存起来，并在真正会改变它的事件上失效。
• 列表页给参考价，购物车给准确价。目录与搜索可以用缓存价或参考价；购物车、报价与结账必须是 SAP 的实时数字，因为最终开票的就是它。
• 永远不要展示你兑现不了的价格。如果 SAP 不可达且你没有有效的缓存价，就告诉客户价格暂时不可用，并让他发起询价。ERP 不可用只是麻烦；价格错了是一张红字发票加一通电话。
• 没有价格就不允许加入购物车。如果 SAP 对该客户与该物料没有价格，就禁用它，而不是放行一张注定会在下游失败的订单。

来问我们这个问题的公司里，相当一部分仍在 ECC 上，并且路线图上某处放着一个 S/4HANA 项目。直觉是等。通常这是错的判断，因为商城此刻正在赚钱或亏钱，而 S/4 项目一定会往后推。

正确的判断是：用一种能扛过迁移的方式来建。

• 在中间放一层集成层。商城只和你的这层说话，这层再去和 SAP 说话。当 SAP 在底下变化时，你重写的是一个适配器，而不是商城。
• 先用你自己的语言定义那六项契约。而不是用 SAP 的语言。「取某客户某物料的净价」是一个稳定的概念，它背后的那个 BAPI 不是。
• 别让 SAP 的字段名进入商城。在边界处做映射。这是你今天能做的、让将来切换到 S/4 时最平静的最便宜的一件事。
• 在 ERP 上线之前就针对 S/4 测试这些契约，而不是上线之后。字段长度、单据类型和错误行为都会变，而商城通常是最后一个被人想起来要测的系统。

这样做，迁移到 S/4HANA 只触及一个适配器和一轮测试。反过来做，它就变成一个你没有编进预算的第二个商城项目。

根据我们事后被请进去收拾的那些项目，按出现频率大致排序：

• 价格是被复制的，而不是被问出来的。上文已述。它是 B2B 商城在无声中亏钱的头号原因。
• 商城的速度等于 SAP 的速度。没有缓存层，于是每个商品页都在等一套原本按批处理和内部用户来选型的 ERP。
• 订单重复。提交时没有幂等键，于是一次重试或一次双击就生成两张销售单据，而没人发现，直到发货部门发现。
• 没有人负责失败路径。SAP 进入维护窗口，商城就抛出堆栈信息，或者更糟，显示零价格。
• 库存是对的，但没用。同步的是总库存，而不是该客户对应工厂的可承诺量，于是网站承诺了它发不出去的货。
• 毫无可观测性。当客户说价格不对时，没人能回答「他看的那一刻 SAP 返回了什么」，排查只能从零开始。

这些都不算高深。每一条的预防成本都远低于在生产环境里发现的成本；这也正是「先做集成设计、再做商城设计」而不是反过来的理由。