因为在工作中，我需要对 SAP CRM 的 attachment 模型，进行增删改查操作，因此我就编写了一个工具类。本文介绍 attachment 的 deletion 即删除操作。
我定义了一种方法，其中包含以下两个导入参数和一个返回参数：
- iv_bor_type type string：业务对象的 BOR 类型
- iv_uuid type raw16：您的业务对象实例的 guid
- rv_successful 类型 abap_bool：表示删除是否成功
删除代码如下：
DATA: ls_bo TYPE SIBFLPORB, lt_loios TYPE SKWF_IOS, ls_loios TYPE SKWF_IO, ls_error TYPE SKWF_ERROR, lt_badios TYPE SKWF_IOERRS, lv_del_flag TYPE ABAP_BOOL. ls_bo-instid = iv_uuid. ls_bo-typeid = iv_bor_type. ls_bo-catid = 'BO'. rv_successful = abap_false. CALL METHOD cl_crm_documents=>get_info EXPORTING business_object = ls_bo IMPORTING loios = lt_loios. LOOP AT lt_loios INTO ls_loios. CALL METHOD cl_crm_documents=>lock EXPORTING is_bo = ls_bo is_loio = ls_loios IMPORTING es_error = ls_error. IF ls_error IS NOT INITIAL. RETURN. ENDIF. ENDLOOP. CALL METHOD cl_crm_documents=>delete EXPORTING business_object = ls_bo ios = lt_loios IMPORTING bad_ios = lt_badios error = ls_error. IF ls_error IS INITIAL. " deletion failed rv_successful = abap_true. ENDIF.
通过测试，我发现它与大多数 BOR 类型的产品、IBASE、BP 和一份订单完美配合。
但是，它不适用于 SAP CRM7.0 EHP3 中的新 BOR 类型 CRMSOCPOST - 在报告中写入显式调用 COMMIT WORK 之前，我的 BO 和附件之间的关系并未真正删除。 但是，对于任何其他标准 CRM BOR 类型，不需要 COMMIT WORK。
是什么原因造成了这种差异呢？
经过一番调试终于找到答案。不知道大家是否已经观察到下面代码里的注释了吗？ 写得很清楚：如果业务对象存在于数据库中，则不需要COMMIT WORK。
回到我的例子，由于CRMSOCPOST 是 CRM7.0 EHP3 中创建的新 BOR 类型，功能模块无法识别它，因此代码到达第 225 行，并且那么该 BO 实例就被认为在 DB 中不存在。 因此，要使删除工作始终需要显式 COMMIT WORK.
COMMIT WORK 是 SAP ABAP 中的一个关键字，用于提交事务，将事务中的所有数据库更新操作永久保存到数据库中。在 SAP 系统中，数据库更新操作通常是在事务内执行的，为了保证数据的一致性和完整性，需要将这些更新操作一起提交到数据库中，而 COMMIT WORK 就是用来实现这一目的的。
在 SAP 系统中，事务是指一组数据库操作的逻辑单元，它们要么全部执行成功，要么全部失败，不存在部分执行成功的情况。事务的执行是原子性的，即要么全部执行，要么全部回滚。当一个事务包含了一系列的数据库更新操作时，这些操作并不会立即生效，而是暂时存储在 SAP 数据库内存中，直到事务被提交才会将这些操作永久保存到数据库中。
使用 COMMIT WORK 关键字可以触发事务的提交，将事务中的所有数据库更新操作一次性提交到数据库中。一旦执行了 COMMIT WORK，所有在该事务内进行的数据库更新操作都会立即生效，并且变得不可逆转。
