作为SAP领域的开发者，我们日常工作中离不开服务的创建与消费。无论是为Fiori应用提供数据，还是实现系统间的集成，OData服务都扮演着核心角色。SAP平台上的服务开发技术也在不断演进，从传统的SEGW到如今主流的RAP （Restful Application Programming )模型，理解这些技术的脉络对我们至关重要。本文将带你回顾传统的OData服务创建方式，梳理ABAP Web开发的技术变迁，并重点解析现代化的SAP Restful Application Programming (RAP)模型及其核心组件。
传统方式用SEGW创建OData服务
在S/4HANA等SAP后台系统中，事务码 SEGW SAP Gateway Service Builder 是我们过去创建OData服务的主要阵地。通过它，我们可以将现有的业务逻辑（如BAPI）暴露为外部可访问的服务。
一个典型的SEGW开发流程大致如下：
- 启动SEGW，创建新项目： 例如，项目名为
ZET_COMBO。 - 定义数据模型： 这是服务的骨架，决定了服务能提供什么样的数据结构。
- 创建实体类型 (Entity Type) 与实体集 (Entity Set)： 实体类型好比一个数据结构模板，实体集则是这种结构模板的实例集合。我们可以手动定义字段，更便捷的方式是从现有ABAP字典结构导入。例如，创建一个名为
Company的实体类型，包含CompanyCode和CompanyName字段，并对应一个CompanySet实体集。
- 创建实体类型 (Entity Type) 与实体集 (Entity Set)： 实体类型好比一个数据结构模板，实体集则是这种结构模板的实例集合。我们可以手动定义字段，更便捷的方式是从现有ABAP字典结构导入。例如，创建一个名为
- 实现服务逻辑 (Service Implementation)： 定义服务如何获取或处理数据。
- 创建实体集后，SEGW会自动在服务实现节点下生成增删改查等操作的框架。
- 生成运行时对象： 点击“小榔头”图标，系统会在后台生成一系列ABAP类，如数据提供者类(DPC)及其扩展类(DPC Extension Class)。这些类包含了实现各种OData操作（GET, POST, PUT, DELETE等）的方法。
- 实现
GET_ENTITYSET操作（获取列表数据）：- 在
CompanySet的GetEntitySet操作上右键，选择“映射到数据源 (Map to Data Source)”。 - 选择数据源类型为“远程函数调用 (Remote Function Calls)”，并指定BAPI名称，比如
COMPANYCODE_GETLIST。 - 进行字段映射：将BAPI返回结构中的字段（如
COMP_CODE,COMP_NAME）与实体类型Company的字段（CompanyCode,CompanyName）一一对应起来。
- 在
- 测试OData服务：
- 可以在SEGW中使用内置的“Gateway客户端”工具。输入服务URL（如
/sap/opu/odata/SAP/YOUR_SERVICE_NAME_SRV/CompanySet），选择HTTP方法（GET），执行并查看返回的XML或JSON数据及状态码（200表示成功）。 - 也可以使用Postman等外部API测试工具。
- 可以在SEGW中使用内置的“Gateway客户端”工具。输入服务URL（如
SEGW的开发方式帮助我们理解了OData服务的基本构建块，但也暴露了其手工步骤较多、灵活性不足等问题。这也催生了更现代化、更高效的RAP模型的诞生。
ABAP Web 开发 RAP 技术
要理解RAP为何成为主流，我们需要回顾一下SAP ABAP Web应用开发的演进历程：
- 经典模块池编程 (Classical Module Pool Programming)： SAP早期的开发模式，基于事务码和屏幕编程。优点是SAP自有框架，成熟稳定；缺点是只能通过SAP GUI客户端访问，无法满足Web化需求。
- 业务服务器页面 (BSPs – Business Server Pages)： 约2005年引入，借鉴JSP/ASP思想，将HTML与ABAP逻辑结合，并提供了HTMLB控件库。缺点是开发工作量大，需要编写大量HTML标签和ABAP代码。
- Web Dynpro ABAP (WDA)： BSP之后出现的框架化Web应用开发模型。它引入了更多拖放能力和代码自动生成，降低了开发门槛。SAP的SRM、CRM等产品曾大量使用WDA构建。
- SAP Fiori与SAPUI5： Fiori不仅仅是一项技术，更是一种用户体验(UX)理念和设计指南，旨在提供简洁、一致、角色化的用户界面。SAP Fiori Launchpad成为统一的应用入口。SAPUI5则是构建Fiori应用的前端技术框架，基于HTML、JavaScript、CSS等Web标准，可以开发灵活美观的Freestyle应用。这种模式下，通常由UI开发者负责前端，ABAP开发者通过OData服务提供后端数据。其挑战在于对ABAP开发者有前端技能要求，且Freestyle开发耗时可能较长。
- ABAP Programming Model for Fiori： 为了让ABAP开发者更容易上手Fiori开发，SAP早期推出了此模型。核心思想是通过在CDS Views中使用注解(Annotations)，自动生成基于模板的简单Fiori应用（即Fiori Elements）。这降低了对纯SAPUI5技能的依赖。这个模型不断发展，最终演变成了今天的RAP。
SAP RAP ABAP开发的“新范式”
SAP Restful Application Programming (RAP) 模型，是当前SAP S/4HANA和SAP BTP ABAP环境推荐的、标准化的应用和服务开发模型。
- 核心理念： 基于RESTful原则，提供一种流线型、高效的开发方法。
- 主要优势：
- 提高开发效率和生产力，降低成本。
- 标准化开发流程和最佳实践。
- 支持代码下推(Code Pushdown)到SAP HANA数据库，优化性能。
- 易于扩展标准应用。
- 支持开发无状态(Stateless)和有状态(Stateful)应用。
- 应用环境：
- SAP S/4HANA On-Premise (2021版本及以后，ABAP 7.56+)。
- SAP S/4HANA Cloud (私有云与公共云版本)。
- SAP BTP ABAP Environment (Steampunk)。
- 开发目标：
- 纯UI服务 (Pure UI Services)： 主要用于开发Fiori应用，特别是Fiori Elements。生成的服务会包含UI注解。
- Web API： 供外部系统或第三方应用通过API交互。主要关注业务逻辑，不包含UI注解。
- Side-by-Side扩展： SAP推荐将新的定制开发或对核心系统的扩展放在BTP环境中进行。在BTP上，ABAP团队可使用RAP，Java/Node.js团队可使用CAP (Cloud Application Programming Model)。
- 核心技术组成： CDS语言、ABAP语言、行为建模语言(BML)、以及基于Eclipse的ABAP Development Tools (ADT)。
RAP 技术的分层架构解析
RAP开发遵循一个清晰的分层方法，主要包括三个层次：
第一层：数据模型与行为 (Data Modeling and Behavior) 这是RAP开发的基础，定义业务实体及其可执行的操作。
- 数据模型 (Data Model)： 使用CDS Views（特别是CDS View Entities）来描述业务实体（如物料、销售订单）及其属性。数据模型通常是一个由多个相关实体通过“组合(Composition)”关系构成的树状结构。组合关系定义了实体间强的父子依赖，子实体不能脱离父实体独立存在。
- 行为 (Behavior)：
- 行为定义 (Behavior Definition)： 使用行为建模语言(BML)描述数据模型支持的标准操作（增删改查Query/Read）、自定义动作(Custom Actions)、函数(Functions)，以及权限控制和功能控制等。
- 行为实现 (Behavior Implementation)： 使用ABAP类（通常组织在Behavior Pool中）来实现行为定义中声明的操作和动作的业务逻辑。这是编写核心ABAP代码的地方。
第二层：业务服务供给 (Business Service Provisioning) 在定义好数据模型和行为后，这一层负责将它们暴露为可消费的服务。
- 业务对象投影 (Business Object Projections)： 尤其在创建UI服务时，可以创建核心业务对象的一个投影。它是针对特定服务需求，对核心数据模型和行为的一个子集或特定视角。
- 服务定义 (Service Definition)： 定义服务将暴露哪些数据模型（可能是业务对象投影）以及它们的哪些部分（哪些实体集可用）。
- 服务绑定 (Service Binding)： 指定服务的技术类型（如OData V2或OData V4）以及访问服务的URL。这是服务的最终发布点。
第三层：服务消费 (Service Consumption) 最终用户或外部系统通过这一层来消费服务。
- SAP Fiori应用： 特别是通过SAP Fiori Elements。包含UI注解的UI服务可以直接驱动Fiori Elements自动生成用户界面。
- Web API： 供外部第三方应用通过HTTP请求调用，进行数据交互。
RAP的开发流程通常遵循这个层次结构：数据库表 -> CDS数据模型 -> 行为定义 -> 行为实现 -> (可选的投影模型和行为) -> 服务定义 -> 服务绑定 -> 服务消费。
OData 服务的“通用语”
OData (Open Data Protocol) 不仅是RAP服务消费的重要方式，也是RAP服务生成的目标之一。
- API的演进： 从早期的BAPI（基于RFC，调用有一定复杂性，需特定连接器），到后来的Web Services (SOAP)，再到目前SAP推荐的OData。
- OData的特点：
- 基于REST架构原则，使用标准HTTP协议。
- 数据格式中立，常用XML或JSON。任何支持这些标准的应用都能轻松消费。
- 被誉为“Web上的SQL (SQL of the Web)”，URL中可包含类似SQL的查询选项（过滤、排序等），将部分数据处理逻辑下推到服务器。
- 是一个开放标准，消费方式一致，无论服务由何种技术栈开发。
- OData URL结构：
http://<host>:<port>/<service root>/<entity set>[/<key>]/<navigation property>[/...]?[<query options>]<key>用于访问单个实体，<navigation property>用于导航到关联实体。
- 常用OData查询选项 (Query Options)，多以
$开头：$metadata：获取服务元数据文档。$format=json/xml：指定响应格式。$top=N：返回前N条记录。$skip=N：跳过前N条记录。$filter=<condition>：按条件过滤。$select=<fields>：选择特定字段返回。$orderby=<field> asc/desc：排序。$expand=<nav_property>：同时获取关联实体数据。
- HTTP方法与OData操作及ABAP后台的对应：
- GET：读取数据 (对应
GET_ENTITY_SET/GET_ENTITY)。 - POST：创建新实体 (对应
CREATE_ENTITY)。 - PUT：完整更新实体 (对应
UPDATE_ENTITY)。 - PATCH：部分更新实体 (对应
UPDATE_ENTITY)。 - DELETE：删除实体 (对应
DELETE_ENTITY)。
- GET：读取数据 (对应
- OData文档： 服务文档（列出实体集）和元数据文档（详细描述数据模型）。
- 测试工具： SAP Gateway客户端 (SEGW或
/IWFND/GW_CLIENT)，以及Postman、SoapUI等外部工具。
RAP开发的基石-OO ABAP
面向对象的ABAP (OO ABAP) 是学习和使用RAP的必备技能。ABAP 7.4版本后，OO ABAP已成为成熟的编程范式。
- 核心概念： 类(Class)、对象(Object/Instance)、属性(Attributes)、方法(Methods)、事件(Events)。
- 可见性区域： Public（公有）、Protected（保护）、Private（私有），控制成员访问权限。
- 静态组件： 使用
CLASS-DATA或CLASS-METHOD定义，属于类本身，不依赖实例。 - 继承(Inheritance)： 子类继承父类特性，可重定义(Redefine)方法。
- 接口(Interfaces)： 定义方法签名，类可实现多个接口，实现多态。
- 异常(Exceptions)： 处理运行时错误。
在RAP的行为实现层，大量使用ABAP类来编写业务逻辑，因此熟练掌握OO ABAP至关重要。
RAP开发关键点与实践建议
- RAP是未来方向： 从S/4HANA 2021起，RAP已是ABAP服务开发的标准模型。
- 坚持服务化思维： 无论是开发Fiori应用还是外部API，都应采用服务化的开发模式。
- 充分利用CDS的威力： CDS是RAP的基石，用于定义数据模型，并支持代码下推到HANA，优化性能。
- 优先考虑Side-by-Side扩展： 新的定制开发或对核心系统的扩展，推荐在BTP环境中利用RAP或CAP实现，保持核心系统简洁。
- 善用Fiori Elements： RAP特别适合快速开发标准的Fiori Elements应用，可显著减少前端开发工作量。
- 打好技术基础： 学习RAP需要具备扎实的OO ABAP、基础ABAP以及CDS知识。
SAP RAP提供了一个端到端的、标准化的开发体验，使ABAP开发者能够高效构建云就绪的现代业务应用和API。理解其分层架构、核心组件以及与OData的关系，将帮助我们更好地驾驭这一强大的编程模型。
企业在向SAP S/4HANA Cloud转型时，SAP 许可 (License) 从 On-Premise 时代的经典指定用户模型转向全新的 FUE 许可模式，且 SAP 产品的许可 (License) 包含诸如“组件授权、用户授权、计量模式”等复杂模型，这对企业来说如同一个黑匣子，难以理解其工作原理。此外，企业还面临 SAP 的 License 审计等合规性问题。赛锐信息在 SAP License 审计流程方面拥有丰富咨询经验，拥有自主研发的高效 SAP License 资产优化软件产品，欢迎企业在需要时随时联系我们，以获得我们的支持服务和软件产品试用体验。
