最近,一个带 Draft 编辑能力的销售订单场景很容易把问题暴露出来。销售订单 A 的某个行项目,需要引用销售订单 B 的另一个行项目,页面在显示模式下一切正常,进入编辑模式后也能打开关联对象,可关联路径读到的却仍然是活动数据。业务人员刚刚在另一个草稿里调整过目标行项目,当前页面却看不到那份尚未激活的修改,甚至可能继续按照旧值完成校验和金额计算。
问题并不在 SAP Fiori Elements 的页面模板,也不在 OData 导航属性是否生成。真正需要检查的是 CDS Association 有没有进入 Draft 语义。普通 Association 只负责描述实体之间如何连接,而 Draft-enabled Association 还要回答另一个问题,源实例当前是活动态还是草稿态,关联目标应当跟随哪一种状态。SAP 官方给出的规则很明确,从活动源实例沿关联导航时应读取活动目标,从草稿源实例沿关联导航时应读取草稿目标。没有启用 Draft 的关联,即使源实例已经处在草稿态,也会继续返回目标实体的活动版本。
这类差异在只读页面里不容易暴露。进入编辑流程后,活动表与草稿表同时参与运行,关联的状态一致性才会成为业务正确性的一部分。页面看起来只是从一个字段跳到另一个对象,后台实际要在活动持久化与草稿持久化之间选择正确的数据来源。选错目标版本,UI 仍然可能正常渲染,数据却已经悄悄跨越了状态边界。
Association 为什么不会全部自动获得 Draft 能力
SAP 并没有要求每一条 Association 都手工补充 Draft 注解。处在组合层级中的紧密关系通常能够由框架推导,例如从业务对象根节点到子节点、从子节点回到父节点、从更深层