最近在做 SAP RAP unmanaged 场景时，一个很容易踩坑的点，是 action 之间的业务顺序。销售订单已经创建，业务同事在 Fiori 页面点了「创建交付」，系统不只是把Status改成Delivery Created这么简单。真实项目里往往还要检查订单状态、检查开票状态、准备后续 billing 数据、写入 buffer、返回最新 UI 数据。如果每一步都直接改数据库，代码一多，状态就会变得很脆。某个检查晚了一步，某个 update 已经落库，另一个 update 又失败，最终就会出现业务上最麻烦的半成功状态。
在 RAP 里处理这类流程，更适合把一个主 action 设计成编排器，让它在内部通过 EML 调用多个子 action。SAP 对 EML 的定义很清楚，它是 ABAP 访问 RAP business object 的语言子集，可以读取或修改 RAP BO 的 transactional buffer，也可以触发持久化流程。EML 语句执行时，会进入 RAP runtime framework，再调用对应 RAP BO 的实现。在 unmanaged RAP BO 中，这部分实现位于 ABAP behavior pool。(
