ABAP使用SQL直接更新数据库与使用IN UPDATE TASK的区别
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.
https://i-blog.csdnimg.cn/direct/3eb921b9b0d14ed49d0127410a7606d3.png
在这个函数中，我们将完成一条数据的插入。
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已经完成了数据的更新。
https://i-blog.csdnimg.cn/direct/321fa250c50a462ea8ed7725a3ab9892.png
这样做的效果是：当前会话进程所提交的数据库更新，与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.
其运行效果如下：
https://i-blog.csdnimg.cn/direct/fe32f109474b4aadb118f528d1cbe94c.png
可见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 registering
CALL FUNCTION 'ZGG_UPDATE_MODULE_1' IN UPDATE TASK.
BREAK-POINT.
COMMIT WORK AND WAIT.
BREAK-POINT.
其运行效果如下：
https://i-blog.csdnimg.cn/direct/766e44b5c95f4d33b71d385234d97cf3.png
可以发现，通过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的区别的一些总结，希望对你有资助！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]