采购人员在系统里取消了一张仍需履行的采购订单，几分钟后，仓库发现收货计划已经看不到了。业务同事说，赶紧把订单恢复。开发人员听到的却是另一组问题，取消动作有没有提交，订单是被标记为取消，还是相关业务对象真的被删除，后续有没有产生收货、发票或其他凭证，系统还能从哪里找到取消前的状态。这很像赵灵儿施展还魂咒时要面对的局面。屏幕上同样是一个倒下的角色，背后的原因却可能完全不同。ABAP 没有名为还魂咒的语句，也不存在对任意已提交业务数据通用的一键复活功能。不过，围绕事务回滚、业务撤销、草稿保存、变更追踪、数据备份与重建，确实可以设计出相当接近还魂咒效果的恢复能力。要把这个类比讲准确，关键是弄清楚业务对象究竟在哪一刻失去了可用状态。在我们的系统里，一张单据看起来消失，并不总是数据库记录没了。它可能仍在数据库中，只是状态变为已取消，因而被应用列表的默认筛选条件排除。它也可能处于尚未保存的草稿里，另一位同事看到的是旧的正式版本。还有一种更棘手的情况，单据本身仍在，但其关联凭证、库存数量与对外发送的消息已经发生变化。此时把一个字段改回原值，画面或许恢复了，业务却未必恢复了。可以把还魂咒理解为一项有前提的业务恢复操作。施术前得辨明对象、损伤范围、可用记录和恢复代价；施术时要遵守业务规则；施术后还要检查关联对象是否一致。ABAP 能参与每一步，但每一步使用的机制并不相同。最接近即时还魂的能力，是尚未提交时的事务回滚。传统 ABAP 程序执行若干数据库修改，业务校验在提交前发现问题，就可以使用ROLLBACK WORK放弃当前事务范围内的修改。已经通过COMMIT WORK完成的事务，不能在过了几个小时后靠补写一条ROLLBACK WORK