SAP学习笔记 - 开发36 - RAP开发 RAP架构图，RAP的优势/特点，RAP的组成结构，开发方法，开发工具，开发流程等概念

Business Object Projections: 业务对象的特定视图或变体，针对不同使用场景定制。
- CDS: Projection views: 使用CDS(核心数据服务)定义的投影视图，用于简化或定制底层数据模型的展示。
- BDEF: Behavior projection: 行为定义的投影，可以修改或限制原始业务对象的行为。
- ABAP: Behavior implementation: 用ABAP代码实现的投影特定行为。

d）. 数据建模与行为层 (DATA MODELING & BEHAVIOR)

Business Objects: 业务实体(如销售订单、客户等)的完整表示，包含数据和行为。
- CDS: Data modeling: 使用CDS语言定义数据模型(实体、关系和字段)。
- BDEF: Behavior definition: 定义业务对象的行为(CRUD操作、验证、动作等)。
- ABAP: Behavior implementation: 用ABAP代码实现业务对象的具体行为逻辑。

e）总结 - 关键概念关系

这个架构图展示了RAP的分层设计理念：

底层是数据建模与行为层，定义业务对象的核心结构和基本行为。
中间是业务服务提供层，可以创建业务对象的不同投影视图。
上层通过服务绑定将业务功能暴露为服务。
最上层是服务消费，通过各种UI或API使用这些服务。

RAP模型的核心优势在于它提供了从持久层到UI层的全栈开发框架，同时保持了各层的解耦，使开发者能够专注于业务逻辑而非技术细节。

2，RAP的优势和特点

- Focus on User Experience：开发人员可以专注于用户体验

- Utilize SAP HANA capabilities：优化

- Efficient development：高效的开发

- Cloud：云特点，不仅是BTP Side-by-side，On-Stack里面也可以用

下面我在Deepseek中查了一遍这些术语的解释：

这张图展示了 SAP BTP 平台上 RAP (ABSP RESTful Application Programming Model) 的主要优势和特点。下面我将详细解释图中的各个术语：

a）. 用户体验相关 (Focus on User Experience)

Utilize SAP HANA capabilities: 充分利用SAP HANA内存数据库的高性能计算能力
Efficient development: 高效的开发模式，减少样板代码
Cloud: 原生支持云环境部署

b）. 多设备访问 (Role-based)

Browser-based: 基于浏览器的访问方式
On any device: 支持在任何设备上访问
Device switch: 支持设备间无缝切换

c）. 前端技术

SAP Fiori and SAPUI5: SAP的标准前端UI框架
RESTful protocols: 基于REST架构风格的通信协议

d）. 代码管理

ABAP managed code pushdown: 将业务逻辑下推到数据库层执行
Secure app development: 安全的应用程序开发机制
High code quality: 保证代码质量
Code management: 完善的代码管理功能
Testability: 良好的可测试性
Supportability: 易于维护和支持
Documentability: 良好的文档支持

e）. 扩展性

In-app extensibility (stable cloud extensions): 应用内扩展能力(稳定的云扩展)
Side by side (whitelisted APIs): 并行扩展模式(通过白名单API)
Stateless cloud-ready apps for scalability and elasticity: 无状态设计，支持云环境下的扩展性和弹性

f）. 数据访问技术

ABAP SQL: ABAP语言中的SQL接口
Core Data Services (CDS): 核心数据服务，定义数据模型
Code pushdown to SAP HANA: 将业务逻辑下推到HANA数据库执行

g）. 开发工具和方法

ABAP Development Tools: 基于Eclipse的ABAP开发工具
Development methodology: 标准化的开发方法论

h）. 平台集成

In-App extensibility: 应用内扩展能力
SAP BTP: SAP业务技术平台集成

i）. 总结- 核心价值

RAP模型的主要价值在于：

提供全栈式开发框架，从前端到数据库层
支持云原生应用开发，具备弹性扩展能力
通过标准化方法提高开发效率和质量
充分利用SAP HANA的高性能特性
提供多种扩展选项，满足不同场景需求
与SAP生态系统无缝集成

这些特点使RAP成为SAP BTP平台上开发现代企业应用的理想选择。

3，RAP的组成结构

这个和 1，RAP架构图差不多。

- Greenfield developments：绿色开发，即从0 开始的开发

- Brownfield developments：有既存系统，其部分火全部设计/代码继续使用，再做一些升级

下面我在Deepseek中查了一遍这些术语的解释：

这张图展示了 SAP BTP 平台上 RAP (ABAP RESTful Application Programming Model) 的组成结构和关键特性。以下是图中术语的详细解释：

a）. 服务开发 (Service development)

SAP Fiori UI services: 为Fiori应用提供后端服务的开发能力，支持响应式UI设计
Web APIs: 开发基于HTTP/REST的API接口，支持系统间集成

b）. 开发场景

Greenfield developments: "绿地开发" - 全新开发项目，从零开始构建应用
Brownfield developments: "棕地开发" - 在现有系统基础上进行扩展或改造

c）. 系统集成

SAP S/4HANA: 与SAP旗舰ERP系统的深度集成能力
SAP BTP, ABAP environment: 在SAP业务技术平台上的ABAP运行环境

d）. RAP核心特性

Universally usable programming model: 通用编程模型，适用于多种业务场景
Available on-premise and in the cloud: 支持本地部署和云环境，提供部署灵活性

e）. 关键组件详解

e)-1. 服务开发层

RAP提供了完整的服务开发框架，包括：

基于OData协议的标准化服务暴露
自动生成符合SAP Fiori标准的服务元数据
支持SAPUI5前端应用的优化数据交互模式

e)-2. 开发场景支持

RAP特别设计了两种开发模式：

绿地开发特点：
- 完全基于CDS和BDEF定义数据模型和行为
- 采用最新的RAP架构标准
- 适合全新业务应用构建
棕地开发特点：
- 支持传统ABAP代码与现代RAP模型的混合使用
- 可以逐步迁移现有ABAP程序
- 提供与传统BAPI/RFC的互操作性

e)-3. 系统集成能力

SAP S/4HANA集成：
- 通过CDS视图直接访问S/4HANA业务数据
- 支持S/4HANA扩展场景的开发
- 提供预定义的业务对象接口
SAP BTP ABAP环境：
- 专为云优化的ABAP运行时
- 提供与BTP其他服务的原生集成
- 支持多租户和自动扩展

f）. 总结 - RAP模型的核心价值

统一性：一套模型同时支持本地和云部署
现代化：基于CDS和OData等现代技术标准
高效性：减少样板代码，提高开发效率
扩展性：支持从S/4HANA到独立应用的各种场景
未来就绪：为SAP的云战略提供长期支持

这种结构设计使RAP成为SAP技术栈中连接传统ABAP世界与现代云应用开发的关键桥梁。

4，开发方法的变迁

以前也贴过这张图。

SAP学习笔记 - 开发11 - RAP（RESTful Application Programming）简介_sap rap-CSDN博客

按ABAP Platform的版本，一共有3世代：

- ABAP Platform <= 7.5，这个比较古老，Web页面用Web Dynpro来做那个时代，算第一代；

- ABAP Platform >= 7.5，SEGW / @OData，Reference Data Source (SADL)

CDS View，CDS-Based BOPF（用于更新操作）

页面用Fiori，这样前后端都齐了，这算是第二代；

※SADL：Odata redefinition with Referenced Data Sources

- SAP S/4HANA >= 1909，这个就是最新的RAP（RESTful Application Programming）

定义Business Service，用CDSView，取代BOPF用Behavior来更新数据，这算是第三代。

- 现在SAP 推荐的是第二种和第三种，但是估计第二种只是存量，未来大概率是主推第三种

下面我在Deepseek中查了一遍这些术语的解释：

这张图展示了SAP ABAP开发方法的变迁，特别是从传统ABAP编程到现代RESTful ABAP编程模型(RAP)的演进。以下是图中术语的详细说明：

a），传统ABAP平台(≤7.5)

CLASSIC ABAP PROGRAMMING - 传统的ABAP编程方式，使用事务码如SE38创建报表和模块池程序
Best practice freestyle ABAP programming - 遵循最佳实践的自由风格ABAP编程

b），过渡期ABAP平台(≥7.5)

ABAP PROGRAMMING MODEL FOR SAP FIORI - 为SAP Fiori应用设计的编程模型
SEGW / @OData Referenced Data Source -
- SEGW: SAP Gateway Service Builder，用于创建OData服务
- @OData Referenced Data Source: 通过注解引用数据源的OData服务
Core Data Services (CDS) - 核心数据服务，定义数据模型和视图的领域特定语言
CDS-Based BOPF - 基于CDS的业务对象处理框架(Business Object Processing Framework)

c），现代ABAP平台(SAP S/4HANA ≥1909 & SAP Cloud Platform)

ABAP RESTful APPLICATION PROGRAMMING MODEL (RAP) - ABAP RESTful编程模型，现代ABAP开发的核心框架
Business Service - 业务服务，RAP中暴露给消费者的服务层
Core Data Services - 在RAP中继续作为数据建模的基础
Behavior Definition & Implementation - RAP中的关键概念：
- Behavior Definition: 定义业务对象的行为(CRUD操作、验证、动作等)
- Behavior Implementation: 实现定义的行为逻辑
Safe Investments! - 表示采用这些技术是"安全的投资"，即SAP长期支持的方向

这些术语共同构成了现代SAP BTP(Business Technology Platform)上ABAP开发，特别是RAP开发的基础架构。RAP模型结合了CDS的强大数据建模能力和定义明确的业务对象行为，为开发云就绪的ABAP应用提供了标准化框架。

5，开发工具的变迁

- 以前在 SAP GUI Client上开发，以后在Eclipse ADT上开发

- 以前叫 ABAP Workbench，以后叫Repository

下面我在Deepseek中查了一遍这些术语的解释：

这张图展示了SAP开发工具的演进历程，从传统的SAP GUI客户端到现代的Eclipse-based开发工具。以下是图中术语的详细说明：

a），开发工具变迁

SAP GUI Client - 传统的SAP图形用户界面客户端
- 长期以来是ABAP开发的主要环境
- 使用事务码如SE80(ABAP Workbench)、SE38(ABAP编辑器)等进行开发
Eclipse Client - Eclipse集成开发环境
- 提供了更现代的IDE体验
- 支持多种编程语言和框架
ABAP Development Tools (ADT) - ABAP开发工具
- 是基于Eclipse的ABAP开发环境插件
- 提供了代码完成、语法高亮、调试等现代IDE功能
- 支持RESTful ABAP编程模型(RAP)等现代开发方式

b），运行环境

NW AS ABAP (7.31 SP4 or higher) - NetWeaver Application Server ABAP 7.31 SP4或更高版本
- 这是支持ADT的最低ABAP平台版本要求
- NW AS ABAP是SAP的ABAP应用服务器

c），传统开发组件

ABAP Workbench - ABAP工作台
- SAP GUI中的传统开发环境集合
- 包含SE80(集成开发环境)、SE38(程序编辑器)、SE24(类构建器)等工具
Repository - 仓库
- SAP系统中存储所有开发对象的中央存储库
- 包含程序、类、数据字典对象等所有ABAP开发工件

这种变迁反映了SAP开发工具从传统的SAP GUI向现代IDE(Eclipse)的转变，使ABAP开发体验更接近其他现代编程语言的开发环境，提高了开发效率和开发者体验。

6，Business Object的组成

这个Business Object就是 [ 1，RAP的架构图]里面的那个 Business Object。

- Data Model：数据的模型，它有一个根节点，还可以有子节点

- Behavior：对这个模型，可以有些什么操作，都在这里定义的

- Runtime Implementataion：Behavior里面的定义具体在哪儿实现的呢，就是这里

<再贴一下这张图>

下面我在Deepseek中查了一遍这些术语的解释：

SAP业务对象(Business Object)组成要素解析

这张图展示了SAP业务对象(Business Object)的核心组成部分，特别是在RESTful ABAP编程模型(RAP)中的结构。以下是图中术语的详细解释：

a）. 数据模型(Data Model)

COMPOSITION TREE (root, parent, and child nodes) - 组合树结构

Root node: 根节点，业务对象的主要实体
Parent nodes: 父节点，包含主要业务数据
Child nodes: 子节点，与父节点有组合关系的数据
这种树状结构定义了业务对象中不同实体间的层次关系

b）. 行为(Behavior)

- CRUD: 基本操作：Create(创建)、Read(读取)、Update(更新)、Delete(删除)

- Actions & Functions: 动作和功能：自定义业务操作，如"审批"、"拒绝"等特定业务逻辑

- Locks: 锁机制：防止并发修改导致的数据不一致

- eTag: 实体标签：用于乐观锁控制的版本标识

- Authorizations: 授权：控制谁可以访问或修改业务对象

- Feature Control: 特性控制：动态启用/禁用特定功能

- Draft: 草稿模式：支持临时保存未完成的数据

c）. 运行时实现(Runtime Implementation)

- INTERACTION PHASE: 交互阶段：用户与业务对象交互的处理过程

- TX buffer: 事务缓冲区：临时存储未提交的变更

- SAVE SEQUENCE: 保存序列

数据持久化到数据库的流程
包括验证、授权检查、实际保存等步骤

这种结构体现了现代SAP业务对象设计的三个关键方面：数据模型定义业务数据结构，行为定义业务逻辑和操作，运行时实现处理实际执行流程。这种分离使得业务对象更清晰、更易于维护，并支持现代RESTful服务开发范式。

7，Business Service的组成

下面我在Deepseek中查了一遍这些术语的解释：

SAP Business Service（业务服务）组成解析

这张图展示了SAP业务服务的关键组成部分，主要围绕如何定义、发布和管理服务。以下是图中术语的详细解释：

a）. 服务绑定（Service Binding）

Protocol: OData V2 or OData V4?
选择OData协议版本：V2（更成熟，兼容性更好）或V4（功能更强大，符合最新标准）
Scenario: Web API or UI?
确定服务使用场景：纯Web API（供外部系统集成）或UI服务（主要为Fiori应用提供数据）

b）. Web API生命周期管理

Release - 服务发布流程
Versioning - 版本控制策略
Deprecation - 服务废弃管理（旧版本淘汰策略）

c）. 工具支持

UI: SAP Fiori elements preview
提供Fiori元素应用的实时预览功能，快速验证UI效果
Web API: Swagger UI preview
通过Swagger UI交互式文档预览和测试Web API

d）. 服务设计核心要素

Service Definition: which entities?
服务定义：确定暴露哪些业务实体（CDS视图或业务对象）
BO Projection View: which elements?
业务对象投影视图：定义哪些字段/元素对外可见（数据层面的裁剪）
Behavior Projection: which behavior?
行为投影：确定暴露哪些行为（CRUD操作、自定义动作等）

这种结构体现了现代SAP服务开发的完整流程：

首先通过服务绑定确定基本协议和场景
设计阶段明确要暴露的数据实体和行为
通过投影机制控制对外暴露的细节
提供完整的生命周期管理和开发工具支持

这种设计模式使得业务服务既能满足前端UI需求，也能支持系统集成场景，同时保持灵活性和可维护性。

e），这里面插播一个疑问，为啥要分Scenario: Web API or UI？

就比如画面和Batch，共用一套API 不好吗？

技术上同一个服务确实可以同时供UI和API使用。但SAP这样区分主要是出于 优化目的 和 架构清晰度，而不是技术限制。

- 🌟 举个现实例子说明区别：

想象一家餐厅：

UI服务 像 堂食菜单
- 为Fiori应用优化（上菜快、摆盘漂亮）
- 默认包含分页/排序等UI必要功能
- 可能简化部分字段（比如不返回技术ID）
Web API服务 像 外卖菜单
- 为系统集成优化（数据完整、支持批量操作）
- 包含所有业务校验逻辑
- 可能需要更详细的错误码

- 🤔 为什么要有这个选择？

维度	UI服务	纯Web API
协议倾向	通常OData V4（功能多）	可能选V2（兼容性好）
数据量	分页默认20条	可能允许100+条批量获取
字段控制	隐藏技术字段	暴露完整字段
性能优化	为前端渲染优化	为系统吞吐优化

- ✅ 实际开发中的真相：

技术上：您完全可以用同一个服务同时服务UI和API（就像您说的）
最佳实践：SAP建议区分是为了：
- 避免UI的字段限制影响API使用者
- 防止API的庞大响应拖慢前端
- 更精准的权限控制（比如API开放更多操作）

- 🛠️ 开发工具如何体现？

当您在ADT中创建Service Binding时：

abap

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '员工服务'
define service ZEmployeeService {
  // UI服务会多这个注解
  @UI: { headerInfo: { typeName: '员工' } }
  expose ZEmployee_UI as Employee;

  // API服务可能这样暴露
  expose ZEmployee_API as EmployeeAPI;
}

建议刚开始可以统一使用，等遇到性能或需求冲突时再拆分。这就是为什么SAP工具要提前让您思考这个问题。

8，RAP的开发流程

下面我在Deepseek中查了一遍这些术语的解释：

SAP RAP（RESTful ABAP Programming Model）开发流程详解

这张图展示了RAP开发的核心流程和组件架构，下面来分解每个关键术语：

a）. 业务服务层（Business Services）

服务发布流程

Service Binding（服务绑定）
定义服务暴露的协议（OData V2/V4）和使用场景（UI/API）
Service Definition（服务定义）
明确哪些业务实体（CDS视图/业务对象）会通过服务暴露
Business Services Provisioning（业务服务提供）
实际发布服务供消费者使用的过程

b）. 持久层基础

DB Table(s)（数据库表）
存储业务数据的物理数据库表
Dictionary（数据字典）
ABAP数据字典，定义表结构、数据类型等元数据

c）. 数据建模层

Core Data Services (CDS)（核心数据服务）
定义业务数据模型的领域特定语言
Data Model View(s)（数据模型视图）
基于CDS的业务对象数据视图
Projection View(s)（投影视图）
对基础数据模型的裁剪视图（控制字段暴露）

d）. 行为定义层

Behavior Definition（行为定义）
声明业务对象支持的操作：

abap

define behavior for ZI_Employee alias Employee
{
  // 标准操作
  create;
  update;
  delete; 
  // 自定义动作
  action approve;
}

Behavior Projection（行为投影）
控制哪些行为对外暴露（类似字段投影）
Behavior Pool（行为池）
存储行为实现代码的ABAP类集合

e）. 开发资源

Source Code Library（源代码库）
存储业务逻辑实现代码的ABAP程序集合

f）. 完整架构

Data Model & Behavior（数据模型与行为）
整个业务对象的完整定义，包含：
- 数据结构（Data Model）
- 业务逻辑（Behavior）

🔄 典型RAP开发流程：

底层建模：先创建数据库表 → 定义CDS数据模型
行为设计：编写Behavior Definition → 在Behavior Pool实现逻辑
服务暴露：通过Projection裁剪 → Service Definition选择实体 → Service Binding发布
前端消费：Fiori应用或API通过绑定好的服务访问数据

这种分层架构使开发人员可以清晰地分离：

数据定义（CDS）
业务逻辑（Behavior）
服务暴露（Service Binding）
UI适配（Projection Views）

每个环节都可以独立修改而不影响其他层次，大大提升了代码的可维护性。

可以看到BTP这里的内容实在是太多了，概念都这么多，以后得系统研究研究。

以上就是本篇的全部内容。

更多SAP顾问业务知识请点击下面目录链接或东京老树根的博客主页

https://blog.csdn.net/shi_ly/category_12216766.html

东京老树根-CSDN博客

魔乐社区

魔乐社区（Modelers.cn) 是一个中立、公益的人工智能社区，提供人工智能工具、模型、数据的托管、展示与应用协同服务，为人工智能开发及爱好者搭建开放的学习交流平台。社区通过理事会方式运作，由全产业链共同建设、共同运营、共同享有，推动国产AI生态繁荣发展。

更多推荐

量化挑战赛冠军专访：4小时啃下W4A8量化，我靠的是这些经验

魔乐社区

「极限压缩量化未来」Modelers GeekDay上海站圆满落幕

魔乐社区

替你试过了，消费级显卡可以跑的开源文生图SOTA模型，顶级渲染、高密度文本绘图

魔乐社区

所有评论(0)

查看更多评论

东京老树根

@shi_ly

已为社区贡献4条内容

SAP学习笔记 - 开发36 - RAP开发 RAP架构图，RAP的优势/特点，RAP的组成结构，开发方法，开发工具，开发流程 等概念

东京老树根

1，RAP的架构图

a）. 服务消费层 (SERVICE CONSUMPTION)

b）. 服务绑定层 (SERVICE BINDING)

c）. 业务服务提供层 (BUSINESS SERVICES PROVISIONING)

d）. 数据建模与行为层 (DATA MODELING & BEHAVIOR)

e）总结 - 关键概念关系

2，RAP的优势和特点

a）. 用户体验相关 (Focus on User Experience)

b）. 多设备访问 (Role-based)

c）. 前端技术

d）. 代码管理

e）. 扩展性

f）. 数据访问技术

g）. 开发工具和方法

h）. 平台集成

i）. 总结- 核心价值

3，RAP的组成结构

a）. 服务开发 (Service development)

b）. 开发场景

c）. 系统集成

d）. RAP核心特性

e）. 关键组件详解

e)-1. 服务开发层

e)-2. 开发场景支持

e)-3. 系统集成能力

f）. 总结 - RAP模型的核心价值

4，开发方法的变迁

a），传统ABAP平台(≤7.5)

b），过渡期ABAP平台(≥7.5)

c），现代ABAP平台(SAP S/4HANA ≥1909 & SAP Cloud Platform)

5，开发工具的变迁

a），开发工具变迁

b），运行环境

c），传统开发组件

6，Business Object的组成

a）. 数据模型(Data Model)

b）. 行为(Behavior)

c）. 运行时实现(Runtime Implementation)

7，Business Service的组成

a）. 服务绑定（Service Binding）

b）. Web API生命周期管理

c）. 工具支持

d）. 服务设计核心要素

e），这里面插播一个疑问，为啥要分Scenario: Web API or UI？

- 🌟 举个现实例子说明区别：

- 🤔 为什么要有这个选择？

- ✅ 实际开发中的真相：

- 🛠️ 开发工具如何体现？

8，RAP的开发流程

a）. 业务服务层（Business Services）

服务发布流程

b）. 持久层基础

c）. 数据建模层

d）. 行为定义层

e）. 开发资源

f）. 完整架构

🔄 典型RAP开发流程：

所有评论(0)

温馨提示：您尚未绑定手机号

东京老树根

SAP学习笔记 - 开发36 - RAP开发 RAP架构图，RAP的优势/特点，RAP的组成结构，开发方法，开发工具，开发流程等概念