在 SAP Fiori Elements 的销售订单对象页里，业务人员打开一张已经保存的订单，进入编辑状态，修改抬头上的付款条件，同时新增一条销售订单行项目。此时屏幕上看到的并不是对正式订单的直接改写，而是一套可继续保存、稍后恢复、激活或放弃的 Draft 数据。SAP 的 Draft 运行时会把活动版本与草稿版本分开管理，在现代 RAP 模型中，每个支持 Draft 的实体通常对应活动持久化与草稿持久化，请求还会通过%is_draft一类状态信息区分本次访问落在哪一条数据轨道上。问题往往不出在单个实体，而出在实体之间的导航。销售订单抬头进入草稿状态后，页面会沿着关联读取销售订单行项目，也可能继续读取计划行。如果抬头来自草稿表，而关联却把行项目带到活动表，页面里会同时出现两套时间状态。抬头是正在修改的内容，行项目却还是正式版本，基于行项目计算的总金额、交货日期和状态校验都可能与当前编辑内容脱节。Draft-Enabled Association 处理的正是这类状态一致性问题。SAP 官方给出的规则很明确，从活动源实例沿草稿关联导航时，目标是活动数据，从草稿源实例沿同一关联导航时，目标是草稿数据。没有启用 Draft 的关联则不理会源实例的状态，即使源实体是草稿，也始终读取目标实体的活动版本。草稿不是一个页面缓存，而是一条事务数据轨道很多 Fiori 开发问题会把 Draft 理解成前端临时变量，或者理解成 Object Page 在浏览器内存里保存的一份表单副本。这样的理解会掩盖关联导航真正承担的责任。Draft 由后端业务对象运行时管理，Fiori Elements 只是按照 OData 元数据和事务语义使用它。业务人员点击编辑后，活动实例可以产生对
