跨系统状态是对不同系统已完成动作的记录，不能只用手机上的一个"成功"代替。上海电气数科通过明道云（HAP 超级应用平台）衔接SAP、移动操作和质检的公开案例提供了业务背景；本文从前后端协作出发设计可观测状态，所有字段和时序均为通用建议，未在该客户系统实施。
我做客户与伙伴服务时，关心的是用户看到的结果能不能解释。工程团队已经处理了重试和日志，现场人员却仍然不知道该等还是该重做，问题就还没有真正交接过去。
先承认：一个成功按钮承载不了四种事实
案例速览：主体为上海电气集团数字科技有限公司，公开分享人齐元帅；文章更新2025-06-04，描述SAP事件驱动移动处理及子公司质检流程，没有披露完整错误处理实现。官方来源
从这条业务路径出发，可以把一次请求拆成四层事实：前端收到了点击；业务应用保存了记录；集成端发出了请求；目标系统接受了业务结果。它们可能先后发生，也可能在某一步停止。
本地记录已保存，页面可以明确告诉用户不用重新填写；目标系统尚未确认，则要保留等待状态。把这两个信息同时表达出来，比让用户反复刷新更有用。
给UI返回业务状态，不直接暴露底层异常堆栈
下面是人工API返回模型，用于需求评审，不是HAP或SAP的标准响应。真实字段需按项目约定转换。
json
{
"task_id": "inspection-demo-01",
"business_state": "approved",
"delivery_state": "unknown",
"last_confirmed_at": null,
"next_action": "wait_for_reconciliation",
"user_message": "检验结果已保存，正在核对接收状态，请勿重复提交。",
"support_reference": "flow-demo-01"
}这里将业务状态与传输状态拆开：结果可以已经批准，但交付状态仍未知。前端不应因为一次网络失败就把审批退回，也不能为了让列表全绿，把未知状态当完成。
用户需要看到人话、最后核对时间、可执行动作；维护人员需要按追踪标识找到请求摘要、错误分类和处理历史。日志里的内部地址、认证信息和完整敏感载荷，不应直接显示到手机提示里。
三种时序，决定按钮能不能重试
| 时序 | 后端掌握的事实 | 页面反馈 | 允许的动作 |
|---|---|---|---|
| 本地保存前失败 | 没有成功保存的业务记录 | 保存失败，保留草稿 | 用同一请求标识重试保存 |
| 本地成功、目标明确拒绝 | 目标返回业务拒绝 | 显示可理解的原因 | 修正数据后形成新版本，经授权重发 |
| 本地成功、目标回音丢失 | 目标可能已处理 | 结果已保存，正在核对 | 查询目标结果或人工核对，避免盲目重发 |
前端禁用按钮只能改善操作体验，无法保证业务幂等。页面刷新、多个设备或后台重投都可能绕开这个限制，最终需要服务端的稳定请求标识、唯一约束及业务校验。
同样，能查询状态不等于查询结果永远即时准确。若读副本存在延迟，或者目标端异步处理，要约定何时能够确认"没有执行"。在此之前，保留未知状态比过早宣布失败更诚实。
HAP节点的边界要在联调时说清
官方Webhook文档说明，外部请求可以触发工作流；发送API请求节点则承担向外部系统发出请求和处理返回数据的能力。接收文档、发送文档
图：官方文档说明Webhook用于接收外部请求并触发工作流。来源：工作流触发方式------Webhook触发，访问2026-10-15；产品能力说明，不是客户接口测试记录。
这些能力为连接提供组件，不自动证明跨系统一致性。客户端请求返回、工作流节点运行结束和目标业务落地，应在联调记录里分别找到证据。不能用一张工作流"成功"的截图，替代目标系统里的业务确认。
实施团队可以把状态转换与记录写入放在合适组件中。若任务、去重记录与外部请求分别跨越不同存储，需要明确失败窗口；不能假定一个平台工作流等同跨系统事务。
给运维留一份能接手的对账视图
建议维护视图至少能按来源业务对象、事件ID、任务ID、目标请求ID和时间范围定位记录，并展示最后状态、重试次数、下一次核对时间与负责人。这是原创建议，不是客户公开架构。
先做一个人工可用的列表：哪些已保存却未确认，哪些明确拒绝，哪些等待资料，哪些重复事件已忽略。不同问题分开筛，才能决定该找业务、接口维护人还是网络管理员。
再为长期未确认项设置基于业务时限的提醒。没有真实需求时不要编造统一的"30秒超时"或"99.9%成功率"目标。时限、告警阈值和处理班次由项目共同确定。
人工处理也要留痕。谁确认目标已经接受、使用什么证据、是否触发过重发，都应记录。直接改数据库把状态改绿，会让下一次排查失去依据。
一张可复用的前后端联调检查单
- 断网后本地草稿是否保留，是否会重复生成业务请求标识。
- 后端已保存但页面未收到响应时，再次查询是否能找回原记录。
- 目标拒绝能否显示可行动的原因，而非仅返回错误码。
- 目标结果未知时，用户是否清楚等待原因和接手方式。
- 页面是否把"质检完成"和"业务放行"混为一个状态。
- 同一任务从两台设备操作时，服务端是否拒绝过期版本。
- 维护者能否从一条用户反馈定位到完整跨系统记录。
上述用例需要在获准的测试环境执行。本文只提供设计，没有真实SAP/HAP端到端运行结果。
常见问题
Q：前端禁用提交按钮够不够？
A：不够。禁用只能限制当前页面操作；重复投递与并发调用仍需服务端处理。
Q：必须实时刷新状态吗？
A：看业务时限，可选轮询或订阅等方式；无论哪种方式，都需显示最近确认时间并处理连接失效。
Q：有了对账视图就不用保证幂等了吗？
A：不是。幂等减少重复副作用，对账识别遗漏和不确定结果，两者处理的问题不同。
你更希望在页面上看到具体失败原因，还是一个明确的接手人？
罗丹丹 Luna｜2026-10-15。工程方案用于讨论，不能当成客户实施说明。