Definition
护照平台如何与 ERP 或 PLM 集成？
它位于这些系统之上，而不是取代它们。规格仍留在 PLM，交易仍留在 ERP，足迹计算仍留在核算工具中。数据通过 REST API、定时导出与供应商提交流入护照，护照发生变化时由 Webhook 通知贵方系统。
The part most integration plans underestimate is the third input. Tier-two composition and certification data usually exists in none of your systems, because until now nothing required you to hold it.
职责
集成之后，哪个系统负责什么
| Data | System of record | What CirculeID adds |
|---|---|---|
| Product specification | PLM | The passport projection and its required-field gap report |
| Transactions and batches | ERP | Batch identity bound to a resolvable passport |
| Carbon footprint | LCA or carbon accounting tool | The figure held against the product with its methodology |
| Supplier evidence | The supplier | Signed credentials, so the claim carries its author |
| Supply chain events | WMS, MES and logistics partners | One EPCIS 2.0 history, queryable by object |
| Access policy | CirculeID | Who sees which field, evaluated at resolution time |
接口
数据如何流动
REST API
护照、事件与凭证均采用基于 HTTPS 的 JSON，密钥按环境分别限定。
定时导入
面向无法主动外呼的系统，在接收时完成映射，而不必由您改造数据格式。
供应商提交
面向您并不掌握的数据的途径——由供应商签名，而非由您转录。
带签名的 Webhook
护照、事件与凭证的变更会推送到贵方系统，并带退避机制进行重试。
字段映射
把贵司的字段惯例一次性映射到标准模型，此后每次导入都沿用。
变更历史
实质性变更以带日期的事件形式记录，因此前后两次读取可以相互对账。
顺序
一个切合实际的集成顺序
- 01
确定主数据系统
在动手写任何映射之前，先确定每一类数据由哪个系统所有。跳过这一步，正是主数据出现重复的根源。
- 02
映射一个产品组
导入一份真实的导出文件，读一读差距报告。它会告诉您：授权法案要求的哪些内容，目前无人掌握。
- 03
启动供应商接入
立即着手，并与其他工作并行推进。这是关键路径，而且更像是一项关系工作，而非技术工作。
- 04
接好回调
让贵方系统订阅护照与凭证的变更，这样下游流程是被动响应，而不是不停轮询。
答疑
常见问题
产品数据的主数据仍由哪个系统承担？
归您。规格的主数据仍在 PLM，交易的主数据仍在 ERP，足迹计算仍在您的碳核算工具。CirculeID 承载的是护照——覆盖这些系统之上、经过组装、带访问控制且携带证据的视图——而不会成为第二个需要维护底层数据的地方。
数据究竟是怎么进来的？
三种方式，通常组合使用：面向能够对外调用的系统的 REST API；面向无法对外调用的系统的定时导出；以及面向您完全不掌握的数据的供应商提交。第三种通常占据工作量的大头，因为二级供应商的成分数据几乎不会存在于您的任何系统之中。
当源数据发生变化时会怎样？
护照会更新。当变更具有实质意义时——例如成分修正、新增认证——会以带日期的事件记录，而不是悄然覆盖此前的数值，因此去年读取的护照与今年读取的护照可以相互对照。
你们有现成的连接器吗？
对常见的 ERP 与 PLM 系统，是的；但连接器只是缩短映射工作，而非取消它：每一次实施都有自己的字段约定和自己的一堆变通做法。请把连接器当作映射讨论的起点，而不是省去这场讨论的替代品。
我们的系统如何得知有内容发生了变化？
Webhook。护照、事件与凭证的变更会发出经签名的回调，您的系统订阅后，下游流程无需轮询即可对新的供应商凭证作出反应。投递失败会按退避策略重试，失败日志是可见的，而不是悄无声息。