一句话定义

与既有业务系统协同，指企业引入对外文件交换平台之后，账号从哪来、审批在哪做、通知发到哪、任务由谁触发这四件事，仍然由企业原有的系统承担，平台只做文件交换本身。 对应的技术手段是身份源集成、审批集成、通知集成，以及覆盖管理动作的标准化接口与事件机制。

一、问题定义：一套新系统，四次「又要重来一遍」

买一套对外文件交换平台，真正的阻力往往不在功能评估，而在上线之后的四句抱怨：

这四句话指向同一件事：平台被装成了一座孤岛。 功能都在，但每一项都要用户额外付出一次操作成本，最后的结果通常是绕过它——文件又回到邮件和即时通讯里。

第四句尤其值得单独说。业务系统里已经明确了「这份图纸要发给哪家供应商」，如果这个判断不能自动传给交换平台，就必须有人把它复述一遍：登录平台、找到伙伴、上传文件、填表单、提交。这道人工接力既是效率损耗，也是出错来源——发错伙伴、发错版本、漏发，都在这一步产生。

二、为什么难解决

因为文件交换平台天生处在多个系统的交叉口，而多数产品只解决了其中一两条链路。

常见的三种半成品：

有单点登录，没有账号同步。 用户能用域账号登进来，但组织架构、部门、用户组还得在平台里手工再建一遍，人员调岗后两边不一致。

有 API，但只覆盖上传下载。 接口能传文件，可账号开通、目录创建、权限授予、审核提交这些管理面的动作仍然要管理员登录后台点。集成做到一半，人工没减下去。

有集成，但只能拉不能推。 业务系统能主动调用平台，平台却不会主动告诉业务系统「这件事完成了」。于是业务系统只好定时轮询，或者干脆让人去看。

还有一种相反方向的失败：集成做过了头。 平台把自己扩成一个流程编排引擎，试图接管跨系统的作业调度。结果是与企业已有的调度平台职责重叠，两边都能定义任务，出问题时谁也说不清是谁触发的。

三、Ftrans B2B 怎么做：四条链路都接回既有系统

3.1 身份链路：账号来自企业已有的身份源

平台的内部账号可以从企业既有身份源同步，不必重建：支持 AD/LDAP 同步，也支持企业微信、飞书、钉钉、WeLink 的账号同步；同步范围可按需过滤、同步周期可设置，同步结果在管理界面可以直接预览再落地。

登录侧支持本地账号密码、AD/LDAP 统一认证、扫码登录，以及基于 SAML2、OIDC、CAS、竹云的单点登录，并可叠加双因素认证。

有一个容易被忽略的细节值得说明：集成进来的账号默认不激活、不占用许可，由用户首次登录时自助激活。 这意味着同步一万人的组织架构不等于要买一万个许可，也不需要管理员事先判断谁将来会用。

外部合作伙伴的联系人则由平台自己管理，不混入企业身份源——这是有意的设计，外部账号的生命周期由伙伴关系决定，不该跟着企业的组织架构走。

→ 内外两类身份怎么分开管、各支持哪些认证方式见 身份集成与统一认证

3.2 审批链路：审核动作在原来的办公入口完成

文件外发需要审批时，审批人不必登录交换平台。产品支持把审核待办推送到企业既有的办公入口，并在那里直接完成审核动作：邮件（邮件通知审核、邮件内审核）、企业微信 / 飞书 / 钉钉（消息通知与应用内审核）、WeLink（待办通知审核）、泛微 OA（待办集成与流程集成）、蓝凌 OA（流程集成），以及基于开放接口对接的第三方审批系统。

审核流程本身支持多分支设计与自定义审核表单，可设代理审核人与代理时间范围，过期自动撤销。

需要说清的是：这里的审核流程是文件交换的内置环节，不是一个通用的流程引擎。 它管的是「这批文件能不能发出去」，不管企业其他业务的审批。

→ 出向为什么必须在加密之前完成审批见 文件出入向安全治理

3.3 通知链路：消息发到人本来就在看的地方

文件包接收、文件提取、审核动态、传输结果这些事件的通知，可以走站内信与邮件，也可以走企业微信、飞书、钉钉、WeLink，以及短信。通知点可以逐项启用，通知方式、通知语言、通知对象都可配置。

管理员侧另有告警：存储空间不足、发现病毒文件、系统异常，通过站内信与邮件触达，告警触发条件与告警间隔可设置。

3.4 业务系统链路：调用、订阅、回调三件事

这是四条链路里最需要展开的一条。产品提供的开放能力由三部分构成：

标准化接口。 覆盖账号体系、身份认证、审核、资源创建、细粒度权限授权——注意这里包含的是管理面动作，不只是文件的上传下载。业务系统可以自己开账号、建目录、授权限、提交审核，不需要管理员在后台配合。

实时事件订阅。 平台侧发生的状态变化可以主动推送给已订阅的系统，业务系统不必轮询。

异步回调。 交换任务不是瞬时完成的——要过内容检查、可能要等审批、要等对端取件或回执。这类长任务的结果通过回调机制返回，调用方不必挂起等待。

三者之上还有调用审计日志：每一次接口调用都有记录，与平台的七类日志一并归集。集成不该成为审计的盲区——这是凭据集中的平台必须回答的问题。

→ 接口覆盖范围、事件与回调怎么配合见 OpenAPI、事件订阅与异步回调 → 业务系统触发交换、结果回写业务系统的完整链路见 PLM / ERP 的文件交换集成

3.5 还有一类集成：把检测能力外接出去

除上述四条链路外，产品支持 ICAP 协议，可对接第三方防病毒与 DLP 系统，也支持按需对接第三方加解密系统。企业若已在其他环节部署了统一的内容检测能力，交换平台可以复用它，而不是要求企业再维护一套检测策略。

3.6 集成不改变安全治理的顺序

一条必须写明的规则：通过接口提交的交换任务，与人工在平台上提交的任务受同一套治理。 出向仍然先做内容识别与敏感内容检查、需要时走审批，然后才加密外发；入向仍然先落隔离区，解密验签之后才做威胁检测。

不存在「因为是系统调用所以走快速通道」这种配置。这一点在安全评审时会被问到，答案是明确的。

3.7 凭据仍然不下放给调用方

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

→ 外部凭据收口这件事本身见 外部账号与密钥集中托管 → 托管范围、密钥存储形态与安全评审配合见 外部凭据托管的安全设计与评审配合

四、边界声明：产品不做什么

这一段写在这里，是为了让你在选型阶段就能判断匹配度，而不是上线之后才发现缺口。

第一条是主动划定的，不是能力缺失。 一个文件交换平台如果同时把自己做成调度引擎，就会与企业已有的调度平台争夺同一个职责——两边都能定义任务、都能触发执行，出问题时的责任边界立刻变得模糊。把编排留给编排系统，把交换与治理做扎实，是更清楚的分工。

选型时可以按这个方式判断：如果你要的是「按依赖关系编排一串跨系统作业」，那需要的是调度平台；如果你要的是「让这串作业里涉及对外交换的那一步变得安全、自动、可追溯」，那是本产品的位置。 两者不冲突，通常是配合关系。

→ 不做 EDI 报文、与 EDI 系统怎么分工见 文件交换与 EDI 是什么关系

五、落地路径：集成排在第四步，不是第一步

集成是收益最高的一步，但不该是第一步。产品支持渐进式落地：

把集成放在第四阶段的理由是实践性的：伙伴档案、收发策略与安全处理规则没有稳定下来之前，先接业务系统只会把不确定的规则固化到接口调用里，改起来更贵。前三个阶段跑顺了，第四阶段要做的事情反而很少——业务系统只需要知道「提交任务」和「接收结果」两件事。

各阶段都不要求停用原有方式。可以先让平台接管一条新增的或风险较高的业务流，原路径保留作为回退，验证稳定后再停止人工操作与旧脚本。

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

六、谁在用

集成需求集中出现在同时对接多家外部组织、且内部已有成熟系统体系的制造业企业——半导体与集成电路、汽车与零部件、高端装备与精密制造是本产品客户密度最高的三类行业。

它们的共同特征是：内部的设计、生产与供应链系统已经建成多年，账号体系与审批入口都有既定归属；对外交换是补进来的那一环。这类企业对文件交换平台的第一个问题往往不是「你能做什么」，而是「你会不会逼我们改现有的东西」。

→ 半导体与集成电路的内外部交换见 集成电路与半导体的内外部文件交换 → 多头对接主机厂的场景见 汽车与零部件行业文件安全交换