海外子公司的一笔销售订单已经保存成功，后续发送给仓储系统的消息却失败了。业务人员打开订单，发现编号存在，交货流程却没有继续。此时最危险的处理方式，是看到报错就把整笔业务重新执行一遍。第二次执行可能再次创建订单，仓储系统也可能已经收到第一次请求，只是回执在途中丢失。真正需要救回来的，是那段中断的业务流程，而且救援只能在明确的条件下进行。《天之痕》里的七仙神针很适合用来思考这件事。游戏攻略对它的描述是，装备后被动生效，角色濒死时自动复活，在同一场战斗中只有一次机会。法宝成长会影响恢复程度。把这几个条件抽出来，分别是持续守护、识别失败、自动恢复、限制次数，以及恢复后保留多少继续战斗的能力。ABAP 没有名为七仙神针的标准功能，也没有一个关键字能让所有失败的程序原地复活。不过，围绕事务、持久化状态、重试、幂等和业务补偿，我们可以设计出相当接近的机制。这里要抓住一个容易混淆的细节。游戏角色复活后，仍处于同一场战斗。业务程序发生运行时错误后，原来的调用栈、局部变量和执行位置通常不会凭空恢复。我们能让同一笔业务继续，靠的是事先留下可信的状态，再由新的执行过程读取状态、判断已经完成的步骤，并从安全的位置继续。这种复活不是把进程时间倒转，而是让业务结果重新进入可完成的轨道。在 SAP ABAP On-Premise 中，离七仙神针最近的一层保护是事务回滚。程序在一个尚未提交的 SAP LUW 中修改数据，检查发现错误后，可以终止这次事务，避免把不完整结果留下。它像是角色受到致命一击之前被护住，谈不上已经死亡又复活。ROLLBACK WORK只能处理相应事务中尚未提交的工作，已经完成的提交不会因为后来的一次回滚而消失，外部系统已接收的请求也不会跟着撤销。假设我们的销售订单创建与一条自建处理