为了方便用户及时了解 EDI 业务运行情况，知行之桥支持配置多种邮件通知。不同邮件代表不同的问题和紧急程度：有些是日常运行报告，有些则表示业务流程可能已中断，需要及时联系技术支持团队处理。

本文将对知行之桥常见邮件通知进行分类，简要说明每类邮件的识别标志、可能产生的业务影响以及收到邮件后的建议处理方式，帮助用户更快地判断“这是什么通知、是否影响业务、下一步应该找谁处理”。

说明： 知行之桥支持自定义邮件主题、收件人和部分正文内容，因此不同企业或项目中的邮件标题可能不完全一致。识别邮件时，应结合主题以及正文中的交易伙伴、工作区、端口、文件名、错误信息、证书名称或 SLA 状态综合判断。

1. 常见邮件通知一览

2. 各类邮件说明

2.1 交易或端口处理错误通知

这类邮件表示什么

知行之桥在接收、转换、校验或发送业务数据时出现错误。常见情况包括通信连接失败、账号或密码失效、文件格式不符合要求、业务字段缺失、交易伙伴拒收或目标业务系统暂时不可用等。

如何识别

• 主题出现Failure、Failed、Error、“失败”或“错误”
• 正文包含工作区名称、端口、消息ID标识、具体的报错信息描述
• 同一问题持续发生时，可能重复收到相似邮件。

用户如何处理

1. 根据邮件中的工作区名称、端口、消息ID标识，确认对应的是订单、发货、发票还是其他业务。
2. 如果报错为临时性的连接中断，需要确认连接是否已经恢复，文件是否已经重发成功。如果后续重试成功，应在业务系统或对方回执中确认该笔数据已成功传输，无需将异常升级处理。
3. 如果收到了持续报错通知，将邮件转给 EDI 技术支持处理。
4. 问题修复后，与技术人员确认该数据是自动重试，还是需要人工补传或重新生成。
5. 补传后进行业务对账，确认上下游系统均已正确接收，避免重复订单、重复发票等问题。

2.2 系统健康警报

这类邮件表示什么

系统健康检查发现服务器或知行之桥的某项资源达到预警阈值。检查项包括应用数据库数据量、内存使用、磁盘空间以及单个目录中的文件数量。 健康检查的阈值默认初始设置如下： 磁盘和内存默认是超过60%发邮件，日志是超过十万条数据，端口下的文件数（Send,Sent,Received,Logs/Sent,Logs/Received任意目录下）阈值是5000笔。
如果服务器磁盘占用90%，EDI系统的自动化会停止工作。如果服务器磁盘占用超过95%，EDI系统的被动接收也会停止工作。

如何识别

• 主题出现“Health Check Report”
• 邮件内容提到数据库、内存、磁盘空间或目录文件数量。
• 通常会提供当前值、阈值或受影响的服务器节点。
• 多节点环境中的内存警报可能包含 InstanceId，用于指出发生问题的服务器节点。

用户如何处理

1. 关注近期订单、发货、发票等业务数据是否出现延迟或积压。
2. 及时将邮件转给EDI 服务器管理人员排查服务器的内存、磁盘、数据库等占用情况。
   • 磁盘超出阈值后可以清理磁盘空间，可以尝试将知行之桥日志从归档改为删除，清理历史日志文件，或者缩短删除数据的周期；也可以清理操作系统临时文件；或者进行磁盘扩容或历史数据迁移。
   • 日志超阈值后可以通过归档日志或删除日志处理。
   • 端口下的文件数目较多时，需要具体情况分析;
     • Send和 Receive先排查相关端口工作流是否有在自动处理数据，排除因未开启自动发送导致的文件累积。
     • 再梳理业务逻辑，检查文件是否应移动到磁盘其它路径。
     • 若为Logs下的文件夹堆积文件过多，则可进行归档处理。
3. 如果EDI系统运行正常，没有卡顿或者延迟现象，可等待管理人员反馈，不需要自行清理文件或重启系统。如果已出现大面积延迟或数据中断，应按生产业务异常升级处理。
4. 如果需要修改系统健康警报的警报阈值和报警频率，可以在”系统设置“–>”通知“的系统健康警报处设置。 ![[images/Pasted image 20260814141016.png|653]]

2.3 证书到期警报

这类邮件表示什么

知行之桥检测到系统中使用的一个或多个证书即将到期或已经过期。证书常用于与交易伙伴建立安全连接，以及对 EDI 文件进行签名、验签、加密或解密。证书到期后，双方可能无法继续正常交换数据。

如何识别

• 主题出现“Certificate Expiration Alert”
• 正文是过期证书名称、过期日期和过期天数
• 一封邮件中可能汇总多个即将到期或已经过期的证书。

用户如何处理

1. 收到“即将到期”提醒后，立即转给 EDI 项目负责人或系统管理员，不要等到到期当天再处理。
2. 如证书涉及外部交易伙伴，应同时确认由本方更新还是等待对方提供新证书。
3. 证书更新期间，业务人员应配合跟进确认证书更新时间等。
4. 更新完成后安排收发测试，并确认生产业务已经恢复正常。

2.4 授权到期警报

这类邮件表示什么

知行之桥检测到系统授权将于30天内到期。

如何识别

• 主题出现“Your subscription is going to expire in xx days”

用户如何处理

1. 收到“授权即将到期”提醒后，立即联系EDI技术支持团队进行授权续费和延期，不要等到到期当天再处理。
2. 授权更新完成后，观察生产业务没有异常文件堆积。

2.5 SLA 有风险通知（At Risk）

这类邮件表示什么

SLA 用于检查某个时间段内应发送或接收的业务数据数量。例如，某交易伙伴在每个工作日应至少发送一定数量的订单。当当前数量低于预期并进入预警阶段时，系统可发送 At Risk 通知。

这类通知不一定表示系统已经报错，也可能是上游尚未产生数据或业务量临时变化。

如何识别

• 正文出现 SLA、At Risk 或“存在风险”
• 通常包含交易伙伴或端口、发送或接收方向、预期数量、当前数量和统计时段。
• 表示还有一定处理时间，但若未及时恢复，可能进一步变为 SLA 违反。

用户如何处理

1. 先确认该时间段是否确实应该有相关业务数据。
2. 若业务上本来就没有数据，例如节假日、停线或临时取消计划，应告知 EDI 管理员核对 SLA 配置。
3. 若应该有数据但尚未收到，及时联系上游业务人员或交易伙伴确认是否已经发送。
4. 同时通知 EDI 运维检查端口运行、通信连接和待处理队列。
5. 在 SLA 截止前持续跟进，确认缺失数据已到达并成功进入业务系统。

2.6 SLA 违反通知（Violated）

这类邮件表示什么

在规定的统计周期结束时，实际发送或接收的数据量仍未达到预期，SLA 已被判定为已违反。与 At Risk 相比，这类邮件表示业务影响已经发生或高度可能发生。

如何识别

• 正文出现 SLA、Violated、“违反”
• 包含预期数量、实际数量、统计时段以及相关交易伙伴或端口。
• 如果系统启用了提前预警，此前可能已经收到同一周期的 At Risk 邮件。

用户如何处理

1. 按业务异常流程升级，通知业务负责人和 EDI 运维人员。
2. 核对缺失的是哪些订单、发货通知、发票或其他业务数据。
3. 联系上下游确认数据是未生成、未发送、未收到还是处理失败。
4. 问题恢复后完成补传、补收或重新处理。
5. 记录影响范围和恢复结果；对重要或反复发生的问题，建议安排复盘。

2.7 周期性状态报告

这类邮件表示什么

系统按照设定的报告周期发送运行状态汇总，主要用于日常巡检。收到状态报告本身通常不表示系统发生故障。

如何识别

• 标题常含“Status Report”。
• 邮件按照每日、每周或其他固定周期到达。
• 正文通常为一段时间内的汇总信息，而不是单笔业务数据的详细报错。

用户如何处理

1. 查看报告中是否存在错误、积压、资源异常或交易量明显偏低。
2. 无异常时可按公司要求归档，不需要额外操作。
3. 如果报告中存在异常，根据异常类型转给 EDI 运维、系统管理员或业务负责人。
4. 如果状态报告未按计划到达，可联系管理员检查邮件配置，不代表 EDI 业务一定已经中断。

2.8 自定义业务通知

这类邮件表示什么

项目可以根据实际业务，在流程中配置自定义邮件。例如，某类订单到达后通知业务人员、文件等待人工确认、处理完成后发送结果，或将指定文件作为附件发送。

如何识别

• 主题或正文具有明显的项目和业务含义。
• 可能包含订单号、发票号、供应商、客户、交易伙伴或业务状态。
• 可能带有业务文件附件。
• 主题格式由项目自行约定，通常没有统一的系统关键字。

用户如何处理

1. 按邮件正文及项目操作手册中的说明执行。
2. 涉及附件、链接、账号或付款信息时，先核对发件地址和业务背景，避免处理仿冒邮件。
3. 如果邮件含义或责任人不明确，联系项目负责人确认，不要直接忽略。
4. 如果同一通知重复出现，应告知 EDI 运维检查是否存在重复数据或流程重复触发。

2.9 自动化报表邮件

这类邮件表示什么

管理员可以为报表设置发送计划，在固定时间把报表结果发送给指定人员。这类邮件与系统状态报告不同，内容取决于项目所配置的具体报表。

如何识别

• 使用事先配置的报表主题。
• 按固定计划到达，正文或附件中包含报表结果。
• 通常不包含单笔交易错误的即时告警信息。

用户如何处理

1. 按报表用途查看、分发或归档。
2. 如果报表中的业务指标异常，转交相应业务负责人进行核对。
3. 如果报表未按时到达，联系报表负责人或系统管理员检查调度及邮件发送状态。

3. 收到邮件后的通用处理原则

3.1 先确认涉及哪项业务

根据邮件中的交易伙伴、端口、文件名、业务单号和时间，确认它对应订单、发货、发票还是其他流程，以及是否属于生产环境。

3.2 再判断是否已经影响业务

在业务系统中核对相关数据是否已经存在。如果数据已经成功到达，可能只需让技术人员检查告警原因；如果数据缺失或状态异常，应立即升级处理。

3.3 提供完整信息

向EDI技术支持团队转交问题时，建议一并提供：

• 生产、测试或开发环境。
• 邮件接收时间和问题发生时间。
• 交易伙伴、业务类型和受影响单据。
• 工作区、端口、文件名、消息 ID。
• 完整错误信息或必要截图。
• 业务截止时间和当前影响范围。

3.4 补传前避免重复数据

重新发送或补传前，应先确认对方系统是否已经收到。处理完成后还应进行端到端业务核对，不能只以知行之桥中某一步显示成功作为最终业务成功的依据。