最近在做 SAP Fiori elements 和 RAP Draft 应用时，一个很容易被忽略的问题会反复出现。用户打开一个对象开始编辑，系统已经为这条 Active instance 创建了 Draft，并且拿到了独占锁。按常规理解，只要用户还没点 Save，也没点 Discard，其他人就不应该动这条业务数据。可是用户去开会了，浏览器页面挂在那里半个小时，回来继续输入，系统并不会简单地沿用原来的锁。更微妙的是，Draft 可能还在，锁却已经失效了。用户继续编辑时，框架会触发 Resume，尝试重新取得独占锁。这个过程成功时几乎无感，失败时却可能让原来的 Draft 变成无法继续使用的历史残影。这就是 SAP Fiori Draft 里 Locking Timeout and Resume 要解决的问题。SAP RAP 的 Draft 机制不是单纯为了保存半成品数据，它同时承担了 Web 应用里事务一致性的设计压力。传统 SAP GUI 或 Web Dynpro ABAP 这类 stateful 应用，可以依赖服务器会话和应用缓冲区保存临时状态。现代基于 OData 的 Fiori 应用更接近 stateless 通信模式，后端不能假设一个长时间稳定存在的会话一直陪着同一个用户完成整段业务操作。SAP Learning 对 Draft 的解释也强调，Draft 会把临时版本存到数据库里的 Draft table，而不是放在应用服务器内存中，直到数据被激活或丢弃。 (