一句话定义

PLM / ERP 的文件交换集成，指业务系统在自己的流程里决定「发什么、发给谁、什么时候发」之后，由文件交换平台接过这个判断，完成对外交换与安全治理，再把结果与回件送回业务系统。 两边不共用界面，也不互相接管职责，靠三类通用机制协同：标准化接口调用、对内部存储位置的扫描监控、事件订阅与异步回调。

一、这个场景解决什么问题

判断已经做完了，却还要有人再做一遍。

在制造业企业里，对外发文件的决定几乎从来不是在文件交换系统里做出的。图纸在产品数据管理系统里定版，供应商在采购与生产系统里选定，什么时候发由项目节点或订单节点决定——到这一步，「发什么、发给谁、什么时候发」都已经有了答案。然后发生的事情是：有人把这三个答案抄下来，登录交换平台，找到伙伴，上传文件，填表单，提交。

这道人工复述带来四类代价：

反向那一条常被低估。收到确认图、检验报告、变更回复之后，如果没有回写机制，文件就停在交换平台里，业务流程要靠人去催、去看、去搬。上传完成不等于业务交付完成——集成缺位时尤其如此。

还有一种走偏的解法：为了让业务系统能发文件，直接把伙伴的 FTP 账号、对象存储密钥配置进业务系统或它调用的脚本里。这样确实自动化了，但凭据从此散布在系统、脚本与配置文件里收不回来，安全检查也被整个绕过。

→ 不把凭据配进业务系统与脚本、改为纳管既有端点并把凭据收口到平台的做法见 零迁移纳管既有传输资源

二、怎么工作：触发、治理、回写

一次完整的链路分三段：业务系统触发 → 平台执行交换与安全治理 → 结果回写业务系统。

2.1 出向：两种触发方式

方式一 · 通过标准化接口提交任务。 业务系统直接调用平台接口发起交换。接口覆盖的不只是文件传输，还包括账号体系、身份认证、审核、资源创建与细粒度权限授权——「新供应商上线」这件事也可以整条由业务系统发起，不必中途插入一次「找管理员在后台点一下」。

方式二 · 平台扫描监控内部存储位置。 业务系统把要外发的文件写到约定好的内部位置即可，平台对该位置做扫描监控，增量发现新文件，自动成批组织为交换任务。

第二种方式对业务系统的改造要求最低。很多既有系统本身就有导出到共享目录的能力，只是导出之后没人接——这类情况不需要为集成改代码，只需要约定一个目录。

选哪一种取决于业务系统能改到什么程度：能改代码、需要拿到任务状态的，用接口；不便改动、只能导出文件的，用扫描监控。两种方式可以在同一平台内并存。

2.2 平台执行的是交换与安全治理

接到触发之后，平台做的事与人工提交完全一样：受控入库 → 内容识别 → 敏感内容检查 → 需要时人工审批 → 加密封装，然后按伙伴与方向配置的收发策略送达。

送达方式覆盖对端能力的整个区间：推送到平台内置传输服务目录由伙伴来取、推送到企业内部自建的传输服务器、推送到伙伴的 FTP/SFTP 或对象存储位置、经 OFTP2 协议直连投递并等待回执、或生成一个受控的文件包链接。对端具备什么能力，不影响业务系统的调用方式——业务系统提交的是「发给这家伙伴」，走哪条路由伙伴档案与收发策略决定。

→ 伙伴指定 OFTP2 时的对接方式见 OFTP2 文件收发

2.3 结果怎么回到业务系统

平台提供三种回写机制：

前两种回的是状态，第三种回的是文件本身，多数集成会同时用到。

回调之所以是异步的：对外交换天然是长任务——要过内容检查，可能要等人工审批，还要等对端取件或回送回执，从几分钟到几天都有可能。把一次可能等一天的审批塞进同步请求里，任何超时设置都是错的。

2.4 入向：伙伴回件怎么进业务系统

反方向同样是一条完整链路。伙伴回件有五个入口：伙伴上传到平台内置传输服务、通过收集链接提交、平台扫描伙伴的外部存储位置、伙伴经 OFTP2 协议主动推送、在伙伴库中人工选择。

进来之后先落隔离区，按受控隔离 → 外层预检 → 解密验签 → 威胁检测处理，通过安全放行闸之后才投递。投递目标可以是内部目录或 NAS、内部 Web 提取区，也可以是内部业务系统——经对象存储或 API 回调交付。对业务流程来说，这段的意义是：回件不再停在交换平台里等人搬。

2.5 集成不改变治理顺序，也不下放凭据

由业务系统触发的交换任务，与人工在平台上提交的任务受同一套治理。 产品不提供「因为是系统调用所以跳过检查」的配置。这也是集成方案与「把账号配给业务系统自己传」之间最本质的区别——后者的自动化是以绕过检查换来的。

同时，业务系统用的是平台的接口凭据，拿不到外部伙伴的 FTP/SFTP 账号、对象存储密钥、PGP 私钥或协议证书私钥。集成扩大的是自动化范围，不是凭据的传播范围。

→ 出向为什么必须在加密之前完成检查见 文件出入向安全治理 → 外部凭据收口的范围与方式见 外部账号与密钥集中托管 → 密钥存储形态与安全评审配合见 外部凭据托管的安全设计与评审配合

三、配置与运维要点

3.1 扫描监控要先约定一个内部位置

用扫描监控方式集成时，第一件要谈的不是技术，是约定：文件写到哪个位置、按什么规则组织目录、一批文件什么时候算写完。

最后一条最容易出问题。业务系统写文件通常不是瞬时的，如果平台在写入过程中就发现并取走，取到的可能是半个文件或半批文件。实践中的处理方式是约定一个明确的完成信号——写到临时位置再整体移入，或以一个约定的标记文件表示这批已经齐了。这属于集成方案设计的内容，建议在方案阶段定下来，不要留到联调。

3.2 回调地址要能被平台访问到

异步回调是平台主动发起的请求，业务系统需要提供一个平台侧可达的接收地址。在内外网分段的环境里，这一项通常涉及一次网络策略确认，同样建议在方案设计阶段提出。

3.3 事件订阅与异步回调怎么选

只关心自己提交的任务，用异步回调就够了；还要对平台上其他来源的交换做出反应，才需要事件订阅。两者可以配合使用，不是二选一。

→ 三种机制的完整说明见 OpenAPI、事件订阅与异步回调

3.4 把「已送达」而不是「已提交」写回业务系统

集成设计时要想清楚：业务系统里那个「已发出」的状态以什么为准。如果以提交成功为准，业务系统会在文件还在检查、还在等审批、甚至还没被对端取走时就显示为完成，「送达状态靠人确认」这个老问题只是换了个地方存在。建议把业务系统的状态与平台的实际交换结果对齐：文件包链接有提取回执，OFTP2 有协议级回执闭环，都可以作为「对方确实收到了」的依据回写。

3.5 编排与重试留在既有调度平台

产品提供接口与事件机制，但不包含通用的工作流编排与任务调度引擎。什么时候发起、按什么依赖顺序发起、失败后重试几次、重试间隔多久——这些决定属于业务系统本身或企业既有的调度平台。

这是主动划定的边界，不是能力缺失——两边都能定义任务、都能触发执行时，出问题的责任边界会立刻模糊。选型时可以这样判断：要的是「按依赖关系编排一串跨系统作业」，那需要调度平台；要的是「让这串作业里涉及对外交换的那一步变得安全、自动、可追溯」，那是本产品的位置。

3.6 集成排在第四阶段，不是第一步

产品支持渐进式落地，集成排在纳管、规则化、自动化之后。伙伴档案与收发策略没有稳定下来之前接业务系统，等于把不确定的规则固化进接口调用与目录约定，改起来更贵；前三个阶段跑顺了，业务系统只需要知道「提交任务」与「接收结果」两件事。

→ 第一阶段不改动现有端点怎么做到见 零迁移纳管既有传输资源

3.7 这是通用机制，不是针对某一套业务系统的专用适配

需要把话说清楚：产品对外提供的是通用集成机制——标准化接口、内部存储位置扫描监控、事件订阅、异步回调，以及入向对内部业务系统的投递。PLM、ERP 在这里是「业务系统」这个角色的两个常见例子，不是两类被专门适配过的产品。

这个说法对选型有用，因为它决定了该问什么问题。该问的不是「你们支持不支持某某系统」，而是「我们的系统能不能调接口、能不能导出到指定目录、能不能接收回调」——三个问题里有一个是肯定的，集成就有路径。具体到某一套系统的对接方式，在集成方案设计阶段确定。

此外，每一次接口调用都有记录，与平台的七类日志一并归集，可查询与导出。通过程序发生的动作和人工操作一样可查，集成不会成为审计的盲区。

四、与其他能力的关系

• 四条协同链路的全貌 —— 业务系统只是其中一条，还有身份、审批、通知三条。→ 与既有业务系统协同
• 三种机制的技术说明 —— 接口覆盖范围、订阅与回调的差别、调用审计。→ OpenAPI、事件订阅与异步回调
• 账号与登录从哪来 —— 集成账号、单点登录与外部身份的分开管理。→ 身份集成与统一认证
• 触发之后平台做了什么 —— 出向与入向为什么顺序不同。→ 文件出入向安全治理
• 伙伴指定 OFTP2 时的协议直连投递与回执 —— OFTP2 协议交换为可选组件，不随产品标配提供，需按需选配。→ OFTP2 文件收发 · B2B 产品构成与选配
• 图纸与技术文档外发的典型行业 —— 内部系统体系成熟、对外交换是补进来的那一环。→ 集成电路与半导体的内外部文件交换
• 多头对接主机厂的场景 —— 一份文件发给多家、每家规则不同。→ 汽车与零部件行业文件安全交换