SAP的LUW和DB的LUW的区别
LUW是Logical Unit of Work，也就是逻辑工作单元。将系统中连续的变化放做一个逻辑单元里，可以全部执行，也可以全部不执行
一般来说，一个业务事物不能被一个LUW处理，比如说从客户订单到收到的发票问题的过程，就是分为逻辑的几个部分，每个部分是用一个LUW处理；
SAP的LUWs定义依赖于整个过程及其造型
数据库的LUW是若干个变化（数据库数据的变化），直到出现DB COMMIT为止；
在一个数据库LUW中，它可以放弃所有的变化都发生在那一刻（数据库回滚），在这种情况下，在当前数据库LUW中，数据库将重置它的状态。所以如果发生了错误，为了恢复以前的（一致）数据库状态，我们可以使用这个数据库回滚功能。
但是如果数据库LUW被DBCOMMIT封住，那么回滚就失效了
使用ABAP的工作的ROLLBACK和COMMIT语句时，可以显式实现一个DB或DB提交回滚。也有情况会triggerred隐含的DB Commit
如果有一个SAP - LUW的处理错误，它应该有可能返回到一个一致的数据库状态前的开始就存在SAP的LUW中。所以这是可能的，SAP的LUW的范围内必须处理一个DB - LUW中。
如下图所示：
但值得注意的是：SAP R/3是一个C/S架构的，通常一个事物会有多个屏幕中的切换，每一个屏幕切换都是一个隐形的DBCOMMIT，但是，它应该有可能在捆绑用户条目内形成一个一个的SAP LUW的交易的DB - LUW，并写入数据库。
隐形的DBcommit有：
A:当系统输出一个屏幕的时候
B:当系统输出一个message的时候
C:执行CALL RFC的时候
D：CALL TRANSACTION <t_code> or SUBMIT <program>.
为了保证数据库的统一性，SAP使用了Bundling changes：
对于在SAP LUW的数据库更改捆绑技术确保他们仍然可以逆转。这也意味着，可以分发交易在多个工作流程，甚至在多个SAP系统。
下面讲几种方法：
A:在子程序中的bundling技术应用：
PERFORM ON COMMIT .
B:在funciton modules for update的bundling 应用
CALL FUNCTION... IN UPDATE TASK
C:在funciton modules 在其他的SAP系统中的bundling 应用
CALL FUNCTION... IN BACKGROUND TASK DESTINATION
D:SAP的tcode
SAP的TCODE是一个应用程序，它可能包含一个或多个SAP LUWs，每当系统达到一个COMMIT WORK或ROLLBACK WORK语句时，只要不是在交易的最后一个对话框中的SAP步骤结束时，它会打开一个新的SAP LUW中，但之前的数据会已经提交到数据库中。
