SAP增强中多线程STARTING NEW TASK实现BAPI事务提交的实践指南

1. 为什么需要多线程处理BAPI提交

在SAP标准增强开发中，我们经常遇到一个典型场景：当用户保存采购订单或销售订单时，系统会触发标准增强点（如USEREXIT_SAVE_DOCUMENT）。如果此时我们需要在增强中调用其他BAPI修改关联数据，直接使用COMMIT WORK或BAPI_TRANSACTION_COMMIT会导致主订单事务被提前提交，可能引发数据不一致或业务流程中断。

我曾在项目中遇到过这样的坑：在采购订单保存增强中直接调用BAPI修改合同数据，结果导致订单抬头信息丢失。后来通过事务码ST22查看dump才发现，根本原因是COMMIT语句打断了SAP标准订单保存的事务链。这就是为什么我们需要STARTING NEW TASK技术——它相当于在后台另开一个"工作线程"，让BAPI提交操作与主事务分离运行。

2. 多线程方案设计原理

2.1 STARTING NEW TASK工作机制

STARTING NEW TASK本质是SAP的异步RFC调用机制。与普通RFC不同，它不会等待函数执行完毕就立即返回。系统会创建一个新的工作进程（类似于多线程概念）来执行被调函数。这个设计有三大优势：

• 主事务不会被阻塞
• 被调函数可以独立提交事务
• 执行失败不会影响主程序

实际测试发现，每个STARTING NEW TASK调用会占用一个RFC工作进程。在SAP系统中，这个数值由参数rdisp/rfc_max_own_task控制，默认值可能不够用，建议在测试环境通过RZ11调整。

2.2 RFC函数的设计要点

创建RFC函数时需要注意几个关键点：

1. 函数属性必须勾选"Remote-Enabled Module"
2. 参数尽量使用基础类型（如CHAR、NUMC），避免复杂结构
3. 内部逻辑要包含完整的异常处理
4. 事务控制必须放在RFC函数内部

我曾见过一个反例：开发者在RFC函数中使用EXPORT TO MEMORY传递内表，结果因为内存溢出导致整个会话崩溃。正确的做法是像示例代码那样，通过标准参数传递必要数据。

3. 完整实现步骤详解

3.1 创建RFC函数模块

首先用SE37创建函数模块ZMM_PO_CHANGE。关键配置步骤如下：

FUNCTION zmm_po_change. *"--------------------------------------------------------------- *"*"Local Interface: *" IMPORTING *" VALUE(IN_AUFNR) TYPE AUFNR *" TABLES *" RETURN STRUCTURE BAPIRET2 OPTIONAL *"---------------------------------------------------------------

函数内部需要包含完整的业务逻辑：

1. 根据输入参数查询需要修改的采购订单
2. 准备BAPI调用参数（如lt_item、lt_itemx）
3. 调用BAPI_PO_CHANGE
4. 根据返回结果决定提交或回滚

3.2 增强点中的调用代码

在标准增强点（如MM06E005）中添加如下代码：

DATA: lt_return_c TYPE TABLE OF bapiret2. CALL FUNCTION 'ZMM_PO_CHANGE' STARTING NEW TASK 'PURCHASEORDER_CHANGE' EXPORTING in_aufnr = header_imp-aufnr TABLES return = lt_return_c EXCEPTIONS system_failure = 1 communication_failure = 2 resource_failure = 3.

几个易错点需要注意：

• 任务名（'PURCHASEORDER_CHANGE'）在同一个会话中必须唯一
• 调用前要清空接收返回值的变量（如lt_return_c）
• 必须处理三种异常情况

4. 生产环境注意事项

4.1 性能优化建议

在大数据量场景下，我推荐以下优化手段：

1. 批量处理：在RFC函数中使用FOR ALL ENTRIES替代单条处理
2. 并行控制：通过DESTINATION 'NONE'启动多个并行任务
3. 资源监控：使用SM58定期清理失败的任务

实测数据显示，批量处理能使性能提升5-8倍。我曾优化过一个采购订单增强，处理1000条数据从原来的3分钟降到25秒。

4.2 错误处理最佳实践

完善的错误处理应该包含：

1. 记录日志：用APPLICATION_LOG保存执行详情
2. 状态检查：通过RFC_PING检测后台任务状态
3. 补偿机制：对失败任务实现自动重试

这里分享一个实用技巧：在RFC函数开头添加如下代码，可以方便问题排查：

DATA(lv_guid) = cl_system_uuid=>create_uuid_x16_static( ). INSERT zmm_po_log VALUES ( guid = lv_guid aufnr = in_aufnr calltime = sy-datum && sy-uzeit ).

5. 常见问题排查

5.1 任务未执行怎么办

遇到STARTING NEW TASK没有触发的情况，按这个顺序检查：

1. 用SM58查看RFC队列状态
2. 检查参数rdisp/rfc_max_own_task的值
3. 在SA38运行报告RSARFCSE测试RFC基础功能
4. 用ST01跟踪函数调用过程

5.2 数据不一致问题

如果发现主从数据不同步：

1. 确认RFC函数中的COMMIT是否执行
2. 检查BAPI返回消息中是否有警告
3. 验证函数参数的数据类型匹配
4. 在SE37测试函数单独执行效果

最近处理过一个案例：采购订单项目修改成功但账户分配没更新。最后发现是BAPI_PO_CHANGE的POACCOUNT参数没传值。这类问题最好的预防方法是编写完整的单元测试。