1. 背景
刚接触ABAP的小伙伴常常会有这样的疑问,为什么不直接使用Open SQL直接更新数据库,而要把对DB的操作封装到IN UPDATE TASK中呢?
对于这个问题,比较常见的解释是,IN UPDATE TASK的方式会保证数据更新的一致性。因为,它注册了一个SAP LUW,在这个逻辑业务单元中的操作,将会一起成功/失败。
这个解释是没问题的,但可能还是稍微缺少点直观的感觉。在本篇博客中,让我们一起通过几个测试,来更深入地理解下IN UPDATE TASK的用法。
2. 测试
2.1 测试1 - Open SQL 与IN UPDATE TASK混合使用
首先,让我们测试下,如果Open SQL 与 IN UPDATE TASK混合使用会发生什么?
建立一个UPDATE Module的Function Module ZUPDATE_MODULE_1.
在这个函数中,我们将完成一条数据的插入。
FUNCTION zupdate_module_1.BREAK-POINT.FINAL(ls_spfli) = VALUE spfli( carrid = 'LH'connid = '456' ).INSERT INTO spfli VALUES @ls_spfli.
然后,让我们在程序ztest_luw
中,使用Open SQL插入另一条数据,同时调用更新模块函数zupdate_module_1
。
REPORT ztest_luw.START-OF-SELECTION.FINAL(ls_spfli) = VALUE spfli( carrid = 'LH'connid = '123' ).INSERT INTO spfli VALUES @ls_spfli.CALL FUNCTION 'ZUPDATE_MODULE_1' IN UPDATE TASK.BREAK-POINT.COMMIT WORK.BREAK-POINT.
在程序中,我已经预设了断点,让我们看一下运行效果。
当执行到Commit Work后,系统会开启一个新的进程,用于执行zupdate_module_1
,而在当前的dialog session中的Open SQL已经完成了数据的更新。
这样做的结果是:当前会话进程所提交的数据库更新,与IN UPDATE TASK所提交的数据库更新,相互独立。带来的后果是,两部分数据更新也是相互独立的。
若IN UPDATE TASK更新失败,会话进程的更新并不受影响。
整体上看,这样实际产生了两个独立的LUW,一个是会话进程中OPEN SQL带来的,另一个是IN UPDATE TASK带来的。
在SAP的标准代码中,会出现类似的场景,但不推荐这样用。因为,这样做的前提是,开发者或业务逻辑的负责人,要清楚地知道其影响与后果,一次业务操作后,可能引发部分操作成功,部分操作失败。
而在绝大多数场景中,我们最期望的效果是,程序运行可以简单直接,更新全部成功或全部失败。
2.2 测试2 - COMMIT WORK AND WAIT的效果
我们知道COMMIT WORK AND WAIT的效果是同步更新,也即触发新的更新进程,但要等到更新进程执行结束后,会话进程才会继续。
若在测试1的场景中,使用COMMIT WORK AND WAIT替代COMMIT WORK,会有什么影响呢?
START-OF-SELECTION.FINAL(ls_spfli) = VALUE spfli( carrid = 'LH'connid = '123' ).INSERT INTO spfli VALUES @ls_spfli.CALL FUNCTION 'ZGG_UPDATE_MODULE_1' IN UPDATE TASK.BREAK-POINT.COMMIT WORK AND WAIT. " <<-------what will happen?BREAK-POINT.
其运行效果如下:
可见COMMIT WORK AND WAIT的效果和COMMIT WORK的效果是类似的。COMMIT WORK AND WAIT仍会触发新的更新进程,并且独立于当前的会话进程,会话进程虽然被WAIT阻塞,但会话进程中对于数据库的提交并不受影响。
2.3 测试3 - SET UPDATE TASK LOCAL 的效果
通过SET UPDATE TASK LOCAL可以让IN UPDATE TASK不启动新的更新进程,让我们测试一下,SET UPDATE TASK LOCAL在OPEN SQL与IN UPDATE TASK混用场景中的效果。
改动代码如下:
START-OF-SELECTION.FINAL(ls_spfli) = VALUE spfli( carrid = 'LH'connid = '123' ).INSERT INTO spfli VALUES @ls_spfli.SET UPDATE TASK LOCAL. "<<---set before registeringCALL FUNCTION 'ZGG_UPDATE_MODULE_1' IN UPDATE TASK.BREAK-POINT.COMMIT WORK AND WAIT.BREAK-POINT.
其运行效果如下:
可以发现,通过SET UPDATE TASK LOCAL,将会直接使用当前的会话进程完成对于IN UPDATE TASK注册函数的执行,并未触发新的更新进程。
在此例中,通过SET UPDATE TASK LOCAL,实现了LUW的合并。
OPEN SQL所提交的数据库更新和IN UPDATE TASK提交的数据库更新同属一个LUW,会一起成功,一起失败。
3. 总结
通过本文中的几个测试,我们可以看到IN UPDATE TASK对程序带来的影响。
总结使用经验的话,推荐将所有的数据库更新操作,统一通过IN UPDATE TASK注册,
不要在会话进程中通过OPEN SQL提交数据库的更新操作
,而是将这些操作封装到IN UPDATE TASK中。
但又有小伙伴问了,若是所有的数据库更新操作都在当前的会话进程中,不也能保证数据的一致性嘛?
答案是“肯定的”。这种方式确实是保证了进程中只有一个LUW。但在实际场景中,对于数据库的操作其实是“一系列”的动作,并非简单一句INSERT或UPDATE。将这些操作封装到IN UPDATE TASK中进行异步更新,将会让终端用户的操作更加流畅。
因为,当所有的输入信息和校验通过后,用户便可以结束当前的会话进程,而不必等待所有的数据库更新结束后才能结束会话。
但注意,任何事情都不是绝对的,如果一个应用程序的逻辑十分简单,数据库更新操作的数据量也很小,不使用IN UPDATE TASK,直接在会话进行中使用OPEN SQL更新数据库,也是可以的。
要避免的场景是,在会话进程通过OPEN SQL更新数据库,与通过IN UPDATE TASK更新数据库,在同一程序中的混合使用!
以上,是本文对于ABAP中使用SQL直接更新数据库与使用IN UPDATE TASK的区别的一些总结,希望对你有帮助!