在 SAP Gateway 项目里调试$batch请求时，经常会碰到一种很有意思的现象。前面的CREATE_ENTITY、UPDATE_ENTITY甚至CHANGESET_PROCESS都已经执行完了，程序里也能看到待修改的数据，可数据库里的最终状态还没有真正固定下来。继续单步执行，运行时进入/IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_END，随后 SAP Gateway Framework 才完成整个 changeset 的事务收口。如果只看方法名称，CHANGESET_END很容易被理解成一个普通的生命周期回调，类似某段处理逻辑结束后的通知方法。实际上，它在 SAP Gateway 的 changeset 事务模型中承担了远比名字更重要的角色。SAP 官方对/IWBEP/IF_MGW_APPL_SRV_RUNTIME的定位非常明确，它是每一个 Data Provider Class，也就是 DPC，需要实现的中央运行时接口。围绕实体创建、修改、删除、Action 执行、媒体流处理以及$batch，SAP Gateway Framework 都通过这个接口与应用层发生交互。而CHANGESET_END所处的位置，恰好是一个 changeset 从应用层处理走向数据库最终提交的边界。理解这个方法，关键并不在于记住一句COMMIT WORK，而在于理解 SAP SAP Gateway 事务真正落地的最后一道关口，深入理解 CHANGESET_END
在 SAP Gateway 项目里调试$batch请求时，经常会碰到一种很有意思的现象。前面的CREATE_ENTITY、UPDATE_ENTITY甚至CHANGESET_PROCESS都已经执行完了，程序里也能看到待修改的数据，可数据库里的最终状态还没有真正固定下来。继续单步执行，运行时进入/IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_END，随后 SAP Gateway Framework 才完成整个 changeset 的事务收口。如果只看方法名称，CHANGESET_END很容易被理解成一个普通的生命周期回调，类似某段处理逻辑结束后的通知方法。实际上，它在 SAP Gateway 的 changeset 事务模型中承担了远比名字更重要的角色。SAP 官方对/IWBEP/IF_MGW_APPL_SRV_RUNTIME的定位非常明确，它是每一个 Data Provider Class，也就是 DPC，需要实现的中央运行时接口。围绕实体创建、修改、删除、Action 执行、媒体流处理以及$batch，SAP Gateway Framework 都通过这个接口与应用层发生交互。而CHANGESET_END所处的位置，恰好是一个 changeset 从应用层处理走向数据库最终提交的边界。理解这个方法，关键并不在于记住一句COMMIT WORK，而在于理解 SAP