从业务对象到可恢复编辑现场，完整理解 SAP Fiori 事务应用的 Draft 开发

销售人员正在维护一张销售订单，客户、销售组织、付款条件都已经填好，订单行也录入了十几条。此时浏览器被意外关闭，网络短暂中断，或者销售人员临时被电话打断，需要过几个小时再回来继续处理。

在传统 SAP GUI 或 Web Dynpro ABAP 应用里，这类编辑过程往往依赖服务端会话和应用缓冲区。只要会话仍然存在，尚未保存的数据就可能继续保留。可到了基于浏览器、OData 和 SAP Fiori 的应用里，前端与后端之间采用更松散的请求响应方式，任何一次 HTTP 请求结束后，后端都不能理所当然地假设原来的会话上下文仍然存在。

Draft 能力正是为了解决这个问题。

它不是简单地在页面上增加一个「保存草稿」按钮，也不只是多建一张临时表。它需要数据模型、事务处理框架、OData 服务、SAP Fiori elements 页面以及并发控制共同遵守一套完整契约。只有这样，应用才能知道哪份数据是正式版本，哪份数据仍处于编辑状态，草稿由谁创建，是否允许其他人员接管，以及什么时候可以把草稿激活为正式业务数据。

本文讨论的是经典 ABAP Programming Model for SAP Fiori 中基于 CDS、BOPF、SAP Gateway 和 SAP Fiori elements 的 Draft 开发方式。SAP 官方把这一编程模型描述为一套面向 SAP HANA 优化的端到端开发架构，其中 CDS 负责语义化数据模型，CDS-based BOPF 负责事务处理，SAP Gateway 负责 OData 暴露，SAPUI5 与 SAP Fiori elements 负责界面消费。

需要特别划清边界，本文所说的 BOPF Draft 属于经典 ABAP Programming Model fo