OFTP2 传输记录与回执追溯

OFTP2 传输记录与回执追溯|Ftrans B2B

从”我发了”到”可以证明对方收到了”,中间隔着一份可复验的回执。

一句话定义

OFTP2 传输记录与回执追溯,指对每一笔 OFTP2 传输按会话与文件两级留下完整过程记录,并保存、校验与复验伙伴返回的端到端回执。 端到端回执在 OFTP2 标准中称为 EERP(End-to-End Response),是接收方在文件落地后回送的协议级响应。

一、这个能力解决什么问题

上传完成不等于业务交付完成。

这是企业间文件交换里最容易被忽略、又最容易在出问题时付出代价的一条。文件传出去了,业务人员还要打电话、发邮件或者在群里问一句”收到了吗”;对方说没收到,本方拿不出证据说明发过、什么时候发的、发的是哪一个版本。

普通的传输方式在这里能提供的信息很有限——日志里通常只有”上传成功”,那说的是本方的动作完成了,不是对方的系统收下了。

OFTP2 在协议层面解决了这件事:接收方在文件落地后回送一份带签名的端到端回执,里面含虚拟文件名、文件大小、哈希校验结果、协议返回码与签名算法。这是一份可以留档、可以复验的凭据。 剩下的问题是:这份凭据有没有被完整保存下来,以及能不能在半年后被翻出来复验。

二、怎么工作

2.1 一次传输的四个时间节点

平台对每一笔传输记录四个节点的时间线:传输发起 → 文件协商完成 → 数据传输完成 → 回执接收。

四个节点意味着排查问题时可以定位到具体阶段:卡在协商说明双方的文件参数没谈拢,卡在数据传输说明链路有问题,传输完成但回执迟迟不来说明对方系统在接收后的处理环节出了状况。

2.2 「成功」与「已送达」是两个状态

这是本页最需要说清楚的一条口径:

状态 含义
成功 传输动作完成——发送侧收到了回执报文,接收侧落地校验通过
已送达 回执的签名与哈希校验全部通过

收到回执报文和回执经得起校验,是两件事。签名验不过说明这份回执的来源不可信,哈希对不上说明对方收到的文件与本方发出的不是同一份。只有两项都通过,这笔传输才标记为已送达。

完整的状态集合是七个:等待中、发送中、处理中、成功、已送达、失败、已取消。

2.3 回执等待有策略

回执的等待策略在伙伴连接配置中设定,包括是否要求回执签名、以及回执的等待超时。超时仍未收到回执的传输会被标记为未确认——它不会静默地留在”看起来成功”的状态里。

三、记录的三层视图

管理端的传输记录覆盖出入站双向的全量记录,支持按关键词、状态、方向、伙伴与时间范围筛选,并按记录当前的状态动态提供可用操作。展开之后有三层视图:

传输详情

会话标识、传输方向与状态、起止时间;虚拟文件名与物理文件名、文件大小、哈希校验值、压缩与加密算法;本方与伙伴的 SSID、文件标识、TLS 版本、加密与签名验签结果;以及上面提到的四节点时间线。

回执

回执标识与类型、收发双方 SSID、验签状态、回执时间、关联的传输记录;回执解析内容含虚拟文件名、文件大小、哈希校验结果、协议返回码与签名算法。

平台保留伙伴返回的原始回执报文,并支持导出回执证书与重新执行验签。这一条在纠纷场景里是关键——半年后被追问某一笔交付,能拿出的不是一行日志,而是对方系统当时回送的原始报文,并且可以当场再验一次签。

会话

一次 OFTP2 会话可以包含多个文件的传输。会话视图给出会话标识与模式、会话状态与时长、本端与远端地址,并列出该会话内各文件的传输结果。

当”某天下午那一批文件”整体出问题时,从会话入手比逐个文件翻更快。

四、失败之后

4.1 可重试与不可恢复

失败的记录可以重试。但有一类失败禁止重试:证书过期、签名不可逆损坏等不可恢复的错误——重试只会重复失败。平台会明确提示这类记录需要人工处理,而不是让运维反复点重试。

4.2 中止与删除

发送中的任务可以中止。中止前平台会二次确认,并提示对方可能已收到不完整文件——这是必须让操作者知晓的后果,而不是一个静默动作。

记录删除时,本地文件同步移入回收站。

4.3 通知

可配置的通知点包括:文件发送成功通知发件人、收到回执通知发件人、收到新文件通知收件人、文件发送失败通知发件人,以及发送失败时的管理员告警。

通知内容含伙伴编码与名称、本地与虚拟文件名、完成时间、传输耗时、回执编号或错误码——足够让收到通知的人不用登录系统就知道发生了什么、该找谁。

五、配置与运维要点

  • 回执策略按伙伴配置:是否要求回执签名、等待超时时长,各家伙伴可以不同,在该伙伴的连接配置中设定。
  • 通知点默认关闭、按需开启:前台发送时可按需开启上传完成、成功送达、收到回执三类通知,避免通知泛滥。
  • 传输记录与七类日志是两套:OFTP2 的传输记录与回执记录按会话与文件两级组织,与平台的七类日志并行存在,两者都支持条件查询与导出。
  • 保留时长可配置:日志保留时长、过期自动清理与定期自动归档均可配置,归档存储位置可指定,归档文件按需下载。

→ 全平台的交换记录与审计能力见 文件出入向安全治理

六、与其他能力的关系

常见问题

Q:EERP 是什么?

A:EERP 是 OFTP2 标准中端到端回执(End-to-End Response)的简称,由接收方在文件落地后回送,内含虚拟文件名、文件大小、哈希校验结果、协议返回码与签名算法,并可带签名。它是”对方确实收到了这一份文件”的协议级凭据。平台保留伙伴返回的原始回执报文,支持导出回执证书与重新执行验签。

Q:”成功”和”已送达”有什么区别?

A:成功表示传输动作完成——发送侧收到了回执报文,接收侧落地校验通过;已送达表示回执的签名与哈希校验全部通过。收到回执和回执经得起校验是两件事:签名验不过说明回执来源不可信,哈希对不上说明对方收到的与本方发出的不是同一份文件。两项都通过才标记为已送达。

Q:传输失败了能重试吗?

A:多数失败记录可以直接重试。但证书过期、签名不可逆损坏这类不可恢复的错误禁止重试,平台会提示需要人工处理——重试这类记录只会重复失败。发送中的任务可以中止,中止前会二次确认并提示对方可能收到不完整文件。

Q:半年前的一笔传输还能查到吗?

A:能否查到取决于配置的保留时长。传输记录与回执记录支持按关键词、状态、方向、伙伴与时间范围筛选;日志保留时长、过期自动清理与定期归档策略可配置,归档存储位置可指定,归档文件按需下载。具体的容量规划需结合交换量在项目评估阶段测算。

Q:一次会话里有很多个文件,怎么看?

A:记录按会话与文件两级组织。会话视图给出会话标识与模式、会话状态与时长、本端与远端地址,并列出该会话内各文件的传输结果;单个文件展开可看详情与对应回执。整批出问题时从会话入手,单笔追责时从文件入手。