前言
截止到上一篇为止，unmanaged的基本功能已经都实现了，剩下的其他功能实现就和managed场景下实现起来没什么太大差别了，本篇在之前unmanaged场景的基础上添加创建真实采购订单的功能，在create和update的同时，创建或者更新标准采购订单数据。
正文
BAPI的本质是执行事务性更改，BAPI被设计为通过发送一次性请求，要么成功，要么失败，调用会返回成功或失败的消息，这意味着BAPI调用通常包含对输入数据的验证和更新任务的执行。
在RAP中使用BAPI是可能的，但并不是所有的BAPI都可用，前提是调用的BAPI不违反SAP LUW规则，简单来说不能包含内置COMMIT，在OP环境中，如果一个BAPI包含了testrun模式，并且COMMIT的控制权是交给调用者的，那么这个BAPI就适合在RAP中使用，反之如果这个BAPI有内置的COMMIT动作，则无法（直接）在RAP中使用。
如果你需要在SAP RAP中使用传统的标准BAPI，那基本上一定会碰到 BEHAVIOR_ILLEGAL_STATEMENT 错误，因为RAP框架对事务控制有非常严格的限制，内置COMMIT WORK或则需要调用完BAPI之后使用COMMIT WORK提交的语句在RAP场景下无法直接使用。
在官网中可以明确的看到COMMIT/ROLLBACK相关的语句在任何RAP相关的处理方法中都是禁止的：
以下是完整的语法限制图，包含交互阶段和保存阶段详细的限制，如果开发中不知道在哪个阶段哪个处理类中能用哪些功能，可以对照这张图来看：
Restrictions in RAP Handler and Saver Methods[1]
基于RAP框架的一些强制限制，本文将提供三种处理标准业务数据的实现方法示例，处理方式为在create之后保存的同时创建采购订单，在edit之后保存的同时，更新采购订单：
-
1. 直接调用传统的标准BAPI：仅私有云和OP环境支持。 -
2. 使用BAPI包装类：仅私有云和OP环境支持。 -
3. 调用标准BO：所有环境均受支持。
本系列文章中主要使用的系统版本为 S4HANA On-Premise 2023，由于代码段可能比较多，完整的源码在文末统一提供。
前期准备
这里为了区分使用BAPI还是BAPI包装类还是BO接口，需要添加一个区分字段来做控制。
1. 在抬头表中添加一个request_code字段，用来在后续保存时作为调用实现方式的分类依据：
-
• 'BAPI'：填写BAPI时调用普通BAPI -
• 'WRAP'：填写WRAP时，使用包装类的方式 -
• 'BO'：填写BO时，调用标准BO接口的方式 -
• ''：什么都不填时，仅进行自建表的数据更新，不做其他处理
2. 调整相关对象
根视图：
根投影视图：
行为定义（需要重新生成草稿表）：
控制结构：
元数据扩展：
调整purchaseorder字段为只读：
方式1：直接调用传统的标准BAPI
这种方式仅在OP环境中可用，因为绝大部分BAPI在云环境中都属于未发布的对象，无法直接调用，SAP推荐的做法都是创建对应的包装器来进行调用，一旦SAP发布了标准的可用API，都建议替换为最新的标准API，直接调用BAPI只能在OP环境中使用。
由于RAP框架的限制，不允许任何显式的COMMIT语句，所以那些有内置COMMIT的BAPI是无法直接调用的；而一般情况BAPI中数据的事务更新都是放在更新进程UPDATE TASK中的，而包含UPDATE TASK的处理在RAP中只允许在两个地方使用：
-
1. adjust_numbers：仅适用于late numbering场合。 -
2. save/save_modified：unmanaged save场合。
本文使用的示例BAPI：BAPI_PO_CREATE1的事务提交是交给调用者控制的，并且提供了TESTRUN参数，所以这类BAPI可以在RAP unmanaged场景中（仅OP环境）通过以下方式调用：
-
• 在check_before_save方法中使用 TESTRUN等于'X' 作为参数测试调用BAPI，以确保BAPI可以执行成功（不触发更新进程）； -
• 在save方法（unmanaged场景）或者save_modified方法（managed场景）中以 TESTRUN等于空 作为参数来实际调用BAPI（触发更新进程），注意不能调用BAPI_TRANSACTION_COMMIT或者ROLLBACK，所有的事务提交必须有RAP框架自动执行。
接下来实现第一种方式的具体实现逻辑：
1.1 添加BAPI的实现方法