为什么用一个引擎，而不是很多条各自的连接
连接系统最直觉的方式就是直接连：哪个应用需要对接平台，就由它自己去对接。这是做成第一条连接最快的路径，也是做到第二十条时最慢的路径。
各建各的连接会不断增殖。每个应用最终都持有自己的一套账号、自己的重试逻辑、自己对“请求失败”的理解。一旦出问题，“这段通信到底发生在哪里”这个问题，有多少个应用就有多少个答案。
各部分的位置
- 电商平台与渠道
- 仓储与第三方物流
- 承运商与物流跟踪
- 应用程序接口
- mPorts 系统对接
- 商品与刊登
- 订单
- 库存
- 发货
- 成本
- mPorts OMS
- mPorts Distribution
- AI 运营
这里列出的是系统类别。是否已上线、已认证，按系统逐个在各集成页面说明。
它在日常工作中带来什么
新增系统只需在一个地方接入；系统出问题时只需在一个地方排查；需要妥善保管的账号集中在一处，而不是分散在多个地方。
这也让其余部分保持简单：mPorts OMS 只用自己的业务语言表达需求，至于某个外部系统希望以什么方式被调用，由这个引擎来负责。
- 电商平台与销售渠道
- 仓储与第三方物流系统
- 承运商与物流跟踪服务
- 应用程序接口
为什么列类别，而不是数量
本页列出 mPorts OMS 能连接的系统类别，而不是一个数字——因为买家真正想知道的数字，是已上线、已认证、正在生产环境运行的连接数，而这要按系统逐个回答，在各集成页面上，而不是给一个总数。
ERP 的对接按账户评估；直接问我们，我们会说明需要做什么。
一次中断，从头到尾
某个仓储系统在夜间停止回复提交。
-
信号
提交给某个仓储系统的请求得不到回执，而其他连接一切正常。
-
mPorts 显示什么
这条连接的健康状况集中在一个地方，以及正在等待它的那些订单。
-
追查
问题出在连接、出在仓库，还是仓库对提交内容的要求发生了变化。
-
建议
暂缓受影响的提交，或者把紧急订单改道到另一个有库存的地点。
-
审批
由运营人员决定。改道是对订单的一项决策，而不是一个开关。
-
执行
连接恢复后，暂缓的提交通过同一条连接继续；改道的订单重新规划。
-
记录
中断、决策与重新提交都记录在它们涉及的订单上。
客户常问的问题
你们支持我们的系统吗？
请直接问我们，我们会对照已上线的连接核实。每个集成页面都写明了那条连接具体做什么。
系统对接怎么收费？
它是 mPorts OMS 的一部分。每个系统只接入 mPorts 一次，OMS 做的一切共用这条连接；没有需要为它单独购买的东西。
你们支持 EDI 吗？
支持。mPorts 通过 EDI 与零售商对接——采购订单、回执、发货通知与发票——由这些单据产生的订单，与其他所有渠道一起运营。具体对接哪些零售商、用哪种格式，需要先做范围评估：大型零售商各有各的要求。
账号凭证保存在哪里？
保存在集成引擎处，而不是分散在各个应用里。这正是把连接集中起来，在日常运维上最主要的理由之一。