做SAP S/4HANA扩展开发的人应该都碰到过这种需求业务方拿着一张纸质单据过来说“我要在这个页面上上面显示抬头信息下面能够维护明细行还能增删改”。以前遇到这种主明细Master-Detail场景ABAP顾问的第一反应往往是SE80建Web Dynpro或者是做一套SEGW Smart Template再不然请前端同事手写Fiori Elements页面。放到今天的S/4HANA环境里答案已经非常明确CDS view定义数据模型RAP定义业务行为Fiori Elements自动渲染UI一套组合拳下来主从明细页面不用写一行前端代码就能跑起来。这篇内容围绕“sap Fiori CDS -RAP 主明细显示”这个主题展开我会从数据模型怎么搭、行为模型怎么定义、服务怎么暴露、界面怎么呈现到实际开发中我踩过的一些坑完整走一遍。适合刚接触RAP的ABAP开发人员也适合想评估“用RAP做一个主从维护页面到底要花多少工作量”的团队参考。1. 整体设计与思路拆解1.1 主明细显示在RAP里到底指什么先把这个标题拆开。“主明细显示”在ERP领域是一个非常经典的交互模型一个业务对象由抬头和行项目组成。比如销售订单有header和item生产订单有order和component采购申请有PR header和PR item。页面上半部分展示抬头属性下半部分维护明细列表两者在同一事务内联动、保存、校验。在RAPABAP RESTful Application Programming Model里这个模型被浓缩成三层关系CDS视图层用composition把根实体根视图和子实体明细视图关联起来。composition不是普通的association它表达的是“包含”关系父没了子就没了生命周期绑定。行为层Behavior通过Behavior Definition显式声明允许哪些操作比如header的create、update、delete以及通过association _Item支持级联新增明细。服务层UI层用Service Definition和Service Binding把行为暴露成OData V4服务Fiori Elements的List Report Object Page模板读取元数据后自动识别composition关系直接渲染出主从维护界面。也就是说RAP把传统开发里“数据字典 OData 前端页面”三套东西变成了“一个业务对象模型”。主明细显示的本质是这个业务对象模型的前端投影。1.2 为什么选CDS RAP而不是传统开发传统实现主从明细通常会走两条路径第一条路是SEGW OData Fiori Elements。SEGW里要建Entity Type、Association、Entity Set还要写大量*_SET_ENTITY、*_CREATE_ENTITY的DPC扩展代码明细和抬头之间的关联要手动维护navigation属性。能跑但代码量不小而且前后端模型容易脱节改字段要动两处。第二条路是Smart Template Gateway坦白说Smart Template已经处在维护模式新项目我不建议再碰。它的自定义能力和RAP不在一个量级遇到复杂校验和status管理会很吃力。RAP用一套声明式定义解决这个问题CDS视图把数据模型固定下来composition天然表达父子关系。Behavior Definition把“允许干什么”声明出来框架自动生成标准的增删改查实现真正的业务校验才需要写实现类。服务定义直接绑定行为OData服务发布后自带元数据。另外RAP生成的代码干净、结构一致新进来的团队成员看行为定义就能理解业务规则在哪个方法里不会像传统DPC_EXT那样堆一大堆方法。所以从长期维护的角度RAP的性价比明显更高。2. CDS视图层搭建先把手头的数据模型理顺2.1 根视图与明细视图的association设计RAP开发的第一步是先把数据模型想清楚。假设我们要做一个简单的“费用申请主从”应用表ZRAP_HEADER存抬头表ZRAP_ITEM存明细。主表主键是HEADER_UUID子表主键是ITEM_UUID子表里用HEADER_UUID回指抬头。主视图这样定义AbapCatalog.sqlViewName: ZRAP_HEADER_V AccessControl.authorizationCheck: #CHECK EndUserText.label: 费用申请抬头 define root view entity ZI_RAP_HEADER as select from zrap_header composition [0..*] _Item as _Item { key header_uuid as HeaderUuid, header_no as HeaderNo, applicant as Applicant, apply_date as ApplyDate, description as Description, _Item }注意两点。第一composition [0..*] _Item意味着主实体“包含”零到多条明细这是RAP识别父子关系的关键。第二视图的字段最好语义化命名header_uuid映射成HeaderUuid这样后续注解、行为定义、前端显示都统一用大写驼峰。子视图定义AbapCatalog.sqlViewName: ZRAP_ITEM_V AccessControl.authorizationCheck: #CHECK EndUserText.label: 费用申请明细 define view entity ZI_RAP_ITEM as select from zrap_item association [1..1] to ZI_RAP_HEADER as _Header on $projection.HeaderUuid _Header.HeaderUuid { key item_uuid as ItemUuid, header_uuid as HeaderUuid, item_no as ItemNo, expense_type as ExpenseType, amount as Amount, currency as Currency, remark as Remark, _Header }子视图里的_Header是back association方便以后在明细层面读抬头信息或者做值检查。添加这个关联不影响父子关系定义但很多内部校验逻辑都会用到建议保留。主从查询时CDS支持路径表达式。如果想在某个视图里同时读出抬头和明细可以直接这么写define view entity ZI_RAP_HEADER_ITEM as select from ZI_RAP_HEADER as H join _Item as I on H.HeaderUuid I.HeaderUuid { H.HeaderUuid, H.HeaderNo, I.ItemUuid, I.ItemNo, I.ExpenseType, I.Amount }这在调试数据或做只读报表时很方便不过针对RAP交互应用主数据模型一般还是用前两个视图就够了。2.2 主明细下的注解与关键字段选择CDS注解在RAP里承担了“给前端提供元数据”的职责。主从明细页要显示得好注解就得写到位。我常用的几个抬头视图上UI: { headerInfo: { typeName: Expense Request, typeNamePlural: Expense Requests, title: { value: HeaderNo }, description: { value: Description } }, identification: [ { value: HeaderNo }, { value: Applicant }, { value: ApplyDate }, { value: Description } ], facet: [ { purpose: #STANDARD, type: #IDENTIFICATION_REFERENCE, label: General Info }, { id: ItemsFacet, purpose: #STANDARD, type: #LINEITEM_REFERENCE, targetElement: _Item, label: Expense Items } ] }明细视图上UI: { lineItem: [ { value: ItemNo, label: Item No }, { value: ExpenseType, label: Expense Type }, { value: Amount, label: Amount }, { value: Currency, label: Currency }, { value: Remark, label: Remark } ] }这里UI.facet里的#LINEITEM_REFERENCE并指向_ItemFiori Elements读到之后会在Object Page上自动渲染一个子表区域这就是“主明细显示”能在不写前端的情况下出现的原因。字段选择上我的建议是主键用UUID不要用自增数字。RAP在managed场景里负责持久化UUID可以提前在create方法里赋值天然适合分布式、测试环境和后续同步场景。用自增或业务编号做主键会带来“先占号还是先落库”的麻烦。业务编号单独建字段比如HeaderNo、ItemNo作为语义键。这类编号可以用numbering方法生成也可以显示给用户看。金额、数量字段考虑引用数据元素比如/DMO/AMOUNT或系统标准的CURRENCY字段并加上Semantics.amount.currencyCode这种注解保证前端金额展示带货币单位。补充一句经验DDIC表结构一定要在开发前确认好。RAP虽然改字段也方便但一旦服务发布、生成过测试数据再调整主键或association关系迁移成本比传统开发还头疼。先用文本文件或Excel把字段清单列给业务确认再进SE11建表是我个人很推荐的做法。3. RAP行为定义让数据能增删改的“把关层”3.1 Behavior Definition的骨架CDS视图建好之后第二步是创建Behavior Definition。在主视图上右键“Generate Behavior Definition”IDE会帮我们生成骨架。实际项目中建议手工整理成下面这种结构managed implementation in class zbp_rap_header unique; strict(2); define behavior for ZI_RAP_HEADER alias Header persistent table zrap_header lock master authorization master ( instance ) { create; update; delete; field ( readonly : update ) HeaderUuid; field ( readonly ) HeaderNo; mapping for zrap_header { HeaderUuid header_uuid; HeaderNo header_no; Applicant applicant; ApplyDate apply_date; Description description; } association _Item { create; } } define behavior for ZI_RAP_ITEM alias Item persistent table zrap_item lock dependent authorization dependent ( instance ) { update; delete; field ( readonly : update ) HeaderUuid; field ( readonly ) ItemUuid; mapping for zrap_item { ItemUuid item_uuid; HeaderUuid header_uuid; ItemNo item_no; ExpenseType expense_type; Amount amount; Currency currency; Remark remark; } }几个关键点managed implementation表示由RAP框架自动处理insert/update/delete的持久化我们只需要在需要校验的地方写determination、validation。lock master和lock dependent让锁机制自动管理父子实体。用户编辑抬头时明细同时被锁避免并发冲突。association _Item { create; }是子表能级联创建的关键。这样前端在做主从同时新增时框架才知道允许你通过create by association往子表塞数据。行为实现类zbp_rap_header会在单独package里生成一般命名为ZBP_RAP_HEADER里面可以添加后续的determination和validation方法。3.2 determination、validation与create by association行为定义只是声明了“允许做什么”真正写业务规则的地方在实现类的局部类里。主明细场景常见的两块逻辑其一create时自动生成业务编号。例如保存抬头时自动生成HeaderNo可以在主实体上定义determination setHeaderNo on save。实现方法里通过read语句拿到创建数据然后调用编号函数赋值。如果用的是UUID主键这一步是在create的时候手动生成UUID并赋值也可以在determination on create里做。其二保存前校验明细金额合计不能超过预算。定义一个validation validateAmount on save在方法里read出抬头和明细然后循环判断。校验方法抛出异常时框架会放弃保存并把消息返回前端。另外create by association在主从新增时非常有用。前端点击“新增明细”按钮实际上是调用MODIFY ENTITIES ... CREATE BY ASSOC。这也是RAP原生支持的能力不需要我们在行为定义里额外加方法。但如果需要给明细排序号类似ItemNo从10、20、30递增可以在明细实体的determination on create里根据已有的明细条数算下一个序号。这类逻辑在传统ABAP里通常写在外层调用逻辑里现在直接下沉到行为模型更内聚。关于strict(2)当前新建项目默认就是strict模式行为定义里不允许出现未声明的操作或非标准写法。如果你接手的是老项目里生成的RAP对象发现有些语法不支持多半是strict版本不一致尽量统一升级到当前推荐版本。3.3 用EML在测试类里跑通主从写入写完行为定义先别急着发布服务。我习惯在ABAP Development Tools里写一个简单的ABAP类用EMLEntity Manipulation Language模拟一次性创建抬头和两条明细验证行为有没有通。MODIFY ENTITIES OF ZI_RAP_HEADER ENTITY Header CREATE FIELDS ( HeaderUuid HeaderNo Applicant ApplyDate Description ) WITH VALUE #( ( %cid H1 HeaderUuid 6E9D0C6A9A4D4A5E9C18D0F5F3E2C9A1 HeaderNo EXP0000001 Applicant 10000001 ApplyDate cl_abap_context_infoget_system_date( ) Description Test from EML ) ) CREATE BY ASSOC _Item FIELDS ( ItemUuid ItemNo ExpenseType Amount Currency Remark ) WITH VALUE #( ( %cid_ref H1 %target VALUE #( ( %cid I1 ItemUuid 6E9D0C6A9A4D4A5E9C18D0F5F3E2C9A2 ItemNo 10 ExpenseType TRAVEL Amount 1000 Currency CNY Remark 高铁票 ) ( %cid I2 ItemUuid 6E9D0C6A9A4D4A5E9C18D0F5F3E2C9A3 ItemNo 20 ExpenseType MEAL Amount 800 Currency CNY Remark 客户招待 ) ) ) ) ) ENTITY Header UPDATE FIELDS ( Description ) WITH VALUE #( ( HeaderUuid 6E9D0C6A9A4D4A5E9C18D0F5F3E2C9A1 Description Updated ) ) COMMIT ENTITIES.在这个测试脚本里%cid是客户端引用ID%cid_ref用于指向父实体的%cid。有了它们框架才能在最终持久化时把子表数据关联到正确的抬头记录。测试时如果提示“Unknown member %cid_ref”或者“Association _Item is not available”先检查行为定义里是否声明了association _Item { create; }再看CDS视图里是否用的是composition。这两个地方不一致是新手最常见的问题。跑完COMMIT ENTITIES之后到SE11里直接查表或者用SE16N看ZRAP_HEADER和ZRAP_ITEM确认主从数据都落库。4. 服务暴露与Fiori界面消费4.1 Service Definition和Service Binding配置行为定义完成第三步是定义服务。Service Definition负责决定暴露哪些CDS视图define service ZUI_RAP_MASTER_DETAIL { expose ZI_RAP_HEADER as Header; expose ZI_RAP_ITEM as Item; }然后创建Service Binding绑定服务定义协议选OData V4 – UI。为什么是V4因为RAP和Fiori Elements对V4的支持更完整V4的嵌套、导航、批量操作机制天然适合主从模型。V2虽然也能用但很多注解和association相关的特性在V2里要打折扣对主从复杂场景能选V4就选V4。发布之后可以在Service Binding界面直接点“Preview”预览页面会以Fiori Elements的Object Page形态展示。如果前面CDS视图里的UI.facet和UI.lineItem写得正确此时你应该能看到抬头字段和明细表格同时出现。这意味着“主明细显示”在Fiori层已经拉通了。需要提醒一句发布时如果提示“Service must be activated in ICF”先到SICF里检查/sap/bc/odata4节点是否激活再回到Service Binding重新激活。4.2 Fiori Elements主从界面呈现原理界面怎么自动形成的原理并不神秘。Fiori Elements会读取OData服务的元数据尤其是CDS视图里composition [0..*] _Item暴露成OData navigation property。UI.facet的#LINEITEM_REFERENCE告诉前端“这里要放一个子表”。UI.lineItem决定子表列的顺序和标签。UI.identification决定抬头区域字段的展示。如果你对这个展示方式不满意比如想让明细表格默认展开、或者加上合计行通常不需要改前端只要在CDS视图里增加注解就能实现。比如给金额字段加UI.aggregation: #SUM子表底部就会自动出现小计给明细表的facet加UI.lineItem的position排序可以控制列的顺序。这些能力让ABAP顾问能在后端完成绝大多数页面微调不需要前端团队介入。如果你需要的是“先出列表再进详情”也就是从List Report点进Object Page那么在当前Facet基础上再在根视图上加Search.searchable: true和几个UI.lineItem字段列表界面也会自动生成。这个模式在企业应用里最常用进入App看到所有费用申请点某一条进入主从维护页面。5. 常见问题与排查技巧实录实操中主从RAP项目的新手问题比较集中我把踩过的坑整理一份速查表。现象大概率原因排查思路预览页面空白或报403当前用户没有服务调用权限检查PFCG角色是否包含服务对应Authorization Object或临时在SU01给用户分配S_SERVICE权限主表新增成功明细没创建行为定义的association _Item { create; }没配置或CDS用了association而不是composition打开行为定义检查CDS视图把association改回composition后重新激活EML执行报“%cid_ref is not available”父实体和子实体的%cid对应错误或父实体没有成功创建检查%cid_ref是否等于父行里的%cid先单独创建父实体试试保存时报重复键UUID生成时机不对可能是determination里才生成UUID导致两次创建用到相同值确认UUID在create时立即赋值或者使用numbering方法统一管理明细修改后保存不生效行为定义里明细没有声明update或者字段被标readonly检查行为定义确认需要在界面维护的字段没被设置成readonly : update对象保存成功但金额汇总没刷新side effect未配置前端缓存了旧值在主实体上定义side effects字段或给明细字段加UI.aggregation让前端自动重算ATC检查报权限相关错误CDS视图设了#CHECK但缺少相应权限对象在DCLData Control Language里维护好PFCG或角色权限或改用#NOT_REQUIRED仅限不敏感数据再分享一个我实际项目里遇到的问题。有一次业务反馈在前台新增两条明细后点击保存系统一直提示“Item 00010 could not be created”。后台看消息日志原因是权限对象没有分配给用户。RAP在authorization master( instance )模式下每个实例操作都会检查权限如果没有在权限对象里维护ACTVT和实例关键字就会出现这种“保存一半失败一半成功”的诡异现象。排查方法打开ST22看短日志或者用/IWFND/ERROR_LOG查OData层的错误记录通常能直接看到权限对象名称。另外单独提一下ATC检查。S/4HANA开发机现在基本都接入了ATC启用RAP的check variant。建议在发布请求之前就把ATC检查作为日常习惯。RAP相关ATC检查项对行为定义和CDS视图的命名、权限、strict模式都有要求提前跑一遍能避免很多调用阶段的低级错误。还有一个容易被忽略的点请求传输。RAP对象涉及的表、视图、行为定义、行为实现类、服务定义、服务绑定每个对象都会被分配传输请求。交付到测试机之后如果预览报404先查Service Binding是否在目标系统里激活了。步骤通常是这样STC01或者手工到Service Binding里重新激活再到SICF里激活相应的OData节点。RAP依赖的package和transport sequence建议项目上统一约定一个“RAP对象传输检查清单”省得丢三落四。写在最后的一点体会从我自己的使用体验来说RAP对主从明细这种高频需求的支撑已经相当成熟。只要数据模型设计得稳行为定义把增删改和级联关系写清楚后面发布成OData服务和Fiori页面基本是水到渠成的事情。做这个项目时我最深的感受是以前改一个主从维护页面往往要在前端和后端之间反复沟通字段约束和刷新逻辑现在这些约束直接写在行为定义和注解里前后端看到的是同一份元数据沟通成本降了一个量级。最后再补一句建议如果你是第一次做RAP主从别急着把功能铺得太全先跑通“一条抬头一条明细”的最小闭环再逐步加编号生成、校验、权限、状态管理。把最小闭环跑通之后后面遇到问题也更容易定位是模型问题、行为问题还是服务层面的问题。这套技术路线值得花时间投入长期收益非常明显。
实时任务切换)