SAP Fiori 消息类型的设计逻辑，从 Transition Message 到 State Message

最近在做 SAP Fiori Elements 草稿应用时，消息处理经常会卡在一个很细的点上，后端明明已经抛出了 message，前端也确实收到了，可是有的消息刷新页面就没了，有的消息却会跟着 draft 数据一起保存下来。这个差异不是 UI 层随便决定的，而是 ABAP Programming Model for SAP Fiori 和 BOPF 消息框架在设计时就划好的边界。真正决定消息生命周期的关键字段，是 validation 里 message 的LIFETIME。SAP 官方文档把 message 的生命周期分成两类，一类是TRANSITION，另一类是STATE，前者只随当前请求返回，后者只对 draft 场景有意义，并且会被持久化。(SAP Help Portal)从一次保存失败开始看 message 的分叉在 Fiori Elements 的对象页里，我们经常遇到这样的操作链路。用户进入销售订单 draft 页面，填了客户、币种、订单金额，点击保存或者激活。后端 validation 被触发，BOPF 或者 ABAP 应用框架开始检查这些字段。此时可能发生两类完全不同的