SAP的LUW和DB的LUW的区别

sunfull

　　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中，但之前的数据会已经提交到数据库中。