ABAP-SAP的LUW和DB的LUW的区别

转载：http://www.cnblogs.com/helileng/archive/2010/10/14/1851409.html

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