在 SAP 业务系统里，一次看似简单的保存操作，背后往往并不是一条UPDATE语句那么简单。创建一张销售订单时，系统可能要生成订单抬头、订单行项目、合作伙伴关系、定价结果、状态信息，还可能同步更新库存需求、信用检查结果以及后续业务处理所需的数据。站在业务视角，这些动作属于同一件事情。要么整张订单创建成功，要么全部不生效，而不能出现订单抬头已经写入数据库、订单项目却因为异常没有保存的半成品状态。这种要求正是Logical Unit of Work，也就是LUW存在的原因。SAP 官方对LUW的定义非常明确，一次事务负责把数据库从一个一致状态带到另一个一致状态。在这个过程中，中间数据允许暂时处于不一致状态，但事务结束时必须重新回到一致状态。整个过程遵守all-or-nothing原则，成功时通过一次最终提交把所有变化持久化，失败时通过回滚撤销整个工作单元产生的变化。这里有一个很容易混淆的地方，Database LUW和SAP LUW并不是同一个概念。Database LUW属于数据库系统自己的事务机制。从一次数据库事务开始，到数据库执行COMMIT或ROLLBACK为止，这段范围构成一个Database LUW。数据库保证这个范围里的修改要么整体提交，要么整体撤销。但 SAP 应用程序的业务事务经常跨越多个技术处理步骤，甚至跨越多个 ABAP work process