一张销售订单的风险清单打开,屏幕上只有二十行数据。业务人员看到的是交货日期、信用状态和缺货提示;系统背后却要从订单、交货计划、库存和客户资料里找出相互关联的线索。同一笔订单,仓库关心能否配货,财务关心能否放行,销售关心承诺的日期是否还能守住。若把所有判断挤进一段程序,每改一条规则都可能牵动别处;若让数据模型、业务规则和操作入口各司其职,界面看起来轻巧,出手却能层层递进。我觉得,ABAP 世界里最接近黄药师落英神剑掌的,不是某条神奇语句,而是围绕业务对象组织起来的一套组合技,尤其是ABAP CDS、RAP 和 EML的配合。这个类比有趣的地方,也恰恰在于不能只看招式多。落英神剑掌看似掌影纷繁,真正厉害的是每一次虚实变化都有意图。企业软件也是如此,页面可以呈现许多信息,内部可以安排多种处理路径,但业务结果必须准确、可解释、可追查。落英神剑掌的「神剑」二字,很容易让人误以为它是剑术。小说里的设定却是掌法,掌势带有剑法般的凌厉与变化。借这个特点看 ABAP,最贴切的地方是,同一份业务能力可以从不同入口施展。销售人员在 SAP Fiori 页面点击放行,后台程序通过 EML 发起处理,外部系统经由服务接口提交请求,入口可以不同,订单是否允许放行却应受同一组业务约束。掌影可以变,发力的根基不能随界面一起变。这里有一个边界要先摆清。RAP 是 ABAP RESTful Application Programming Model,是构建业务对象及其服务的编程模型;CDS 负责描述数据及其关系;EML 让 ABAP 程序按业务对象的语义读取或修改实例。三者能够形成一套协调的开发方式,却不是所有既有 SAP 事务的通用替身。标准销售订单是否开放了适合当前场景的行为接口,要看所在产品、版本以及实际发