ABAP中COMMIT WORK与COMMIT WORK AND WAIT的异步与同步机制解析

1. 从洗碗机理解ABAP提交机制

想象你家里有两台洗碗机：第一台负责清洗餐具（UPD1），第二台负责烘干和消毒（UPD2）。当你按下普通启动按钮（COMMIT WORK）时，餐具放进洗碗机后你就可以转身离开做其他事情，这就是典型的异步处理。而当你按下"洗完后提醒我"按钮（COMMIT WORK AND WAIT），就必须站在洗碗机前等到整个流程结束听到"嘀"声才能离开，这就是同步等待。

在ABAP世界里，COMMIT WORK就像那个普通启动按钮。我做过一个采购订单批量创建的报表，连续提交500个订单时，如果每个都同步等待，程序要运行20分钟。改用异步提交后，3分钟就完成了界面交互，后台更新慢慢消化，用户体验直线上升。但这里有个坑：有次我忘记检查SM13事务码里的更新日志，后来发现部分订单因字段长度限制更新失败，导致财务对账时出现差异。

2. 更新任务的双引擎解密

2.1 UPD1与UPD2的分工协作

在SAP系统中，更新任务就像装配流水线：

• UPD1是精密机床：专门处理VBMOD表里的数据库直接修改

abap复制" 典型UPD1任务示例：物料主数据创建
DATA: ls_mara TYPE mara.
ls_mara-matnr = 'MAT_001'.
ls_mara-mtart = 'FERT'.
INSERT mara FROM ls_mara.
COMMIT WORK. " 触发UPD1更新

• UPD2是质检包装工位：处理统计字段更新、BW数据抽取等衍生操作。曾经有个库存过账程序，UPD1成功但UPD2失败，导致MM模块显示库存正确但CO模块成本核算数据缺失，这种问题用COMMIT WORK AND WAIT就能立即发现。

2.2 更新队列的容量管理

每个SAP系统都有类似高速公路收费站的设计：

• 更新进程总数就像收费通道数量（默认约4000个）
• 异步提交相当于ETC通道：车辆（事务）通过后立即释放通道
• 同步提交就像人工收费通道：必须完成找零才能放行下一辆车

在ECC6 EHP8系统中实测发现：当并发用户达到300人时，如果大量使用同步提交，SM50里会出现大量等待锁的工作进程。这时就需要像交通管制一样，只在关键业务（如财务过账）使用同步提交。

3. 同步与异步的实战选择

3.1 必须同步的五大场景

根据我的踩坑经验，这些情况非用COMMIT WORK AND WAIT不可：

1. 财务凭证过账后立即打印凭证
2. 物料需求计划运行前的数据一致性检查
3. 与外部系统实时接口（比如银企直连付款）
4. 审批工作流触发前的数据验证
5. 批次管理物料移动时的序列号登记

abap复制" 银行转账示例
CALL FUNCTION 'BAPI_ACC_DOCUMENT_POST'
  EXPORTING
    documentheader = ls_header
  TABLES
    accountgl      = lt_gl
    currencyamount = lt_amt
    return         = lt_return.

READ TABLE lt_return WITH KEY type = 'E'.
IF sy-subrc = 0.
  ROLLBACK WORK.
ELSE.
  COMMIT WORK AND WAIT. " 必须等待银行返回结果
  IF sy-subrc = 0.
    CALL FUNCTION 'Z_PRINT_PAYMENT_SLIP'.
  ENDIF.
ENDIF.

3.2 适合异步的三种典型场景

这些情况用普通COMMIT WORK更合适：

1. 后台作业执行的批量数据导入
2. 不急需结果的统计字段更新
3. 用户操作后的次要数据记录

有个取巧的做法：在WebDynpro应用里，可以先用异步提交让界面快速响应，再通过轮询SM13或自定义状态表来检查更新结果。就像外卖APP先显示"商家已接单"，后台继续跟踪配送状态。

4. 异常处理的艺术

4.1 更新失败的侦探技巧

当SM13出现红色警报时，我常用的排查三板斧：

1. 检查更新函数的调试日志（事务码SU01）
2. 查看更新模块的异常捕获逻辑
3. 分析数据库表锁冲突（事务码DB02）

曾经遇到个诡异案例：UPD2总是凌晨2点失败。后来发现是BW抽取程序与月结作业冲突，通过调整作业计划解决。这类问题如果只用异步提交，可能要等月末对账才会暴露。

4.2 回滚的注意事项

ROLLBACK WORK不是万能橡皮擦：

• 不会撤销已经发送的IDoc
• 不能回退调用外部系统的Web Service
• 对已提交的BAPI操作无效

有次我做接口测试时，连续执行了10次带有回滚的测试脚本，自以为很安全。结果发现对方系统还是收到了10条测试数据，原来他们的接口设计是收到请求就立即写入日志库。这提醒我们：跨系统交互要特别设计补偿机制。

5. 性能优化实战技巧

5.1 更新包大小的黄金分割点

通过ST12事务码跟踪发现：

• 每次提交100条以下记录时，UPD1开销占比达70%
• 单次提交超过500条又容易引发锁超时
• 300-400条/次的批量提交效率最佳

abap复制" 优化的批量提交示例
DATA: lt_data TYPE TABLE OF zorder,
      lv_lines TYPE i.

SELECT * INTO TABLE lt_data FROM zorder 
  WHERE erdat = sy-datum.

lv_lines = lines( lt_data ).
DO lv_lines TIMES.
  READ TABLE lt_data INDEX sy-index INTO DATA(ls_data).
  " 处理逻辑...
  IF sy-index MOD 350 = 0 OR sy-index = lv_lines.
    COMMIT WORK. " 每350条提交一次
  ENDIF.
ENDDO.

5.2 更新函数的优化之道

好的更新函数应该像瑞士军刀：

1. 包含完善的输入校验
2. 使用本地变量避免全局字段符号
3. 对长时间操作实现分块处理
4. 提供详细的状态返回结构

我重构过一个运行要2小时的物料主数据更新函数，通过以下改造降到25分钟：

• 将单个大更新拆分为多个小更新单元
• 用FOR ALL ENTRIES替代嵌套SELECT
• 对非关键字段采用延迟更新策略