## 这个问题，往往不是问架构，而是在问服务发布链路

在做 RAP 方案设计时，我最常听到的一类问题，不是 `RAP 能不能做 OData`，也不是 `Fiori Elements 能不能直接消费`，而是另一句更容易把人带偏的话，`既然已经用了 RAP，是不是就不再需要 SAP Gateway Hub 了`。这个问题如果只用一句话回答，很容易把项目带进误区。更准确的结论是，RAP 并没有把 central Gateway hub 这种部署方式直接判死刑，Hub 仍然可以存在，仍然可以工作，尤其是在一些历史包袱较重、系统边界已经形成、或者前端集中治理要求很强的 landscape 里，这条路依旧是成立的。原始问题里真正让人困惑的地方，不是 Hub 能不能继续存在，而是 RAP 里的 `Service Definition`、`Service Binding`、本地激活、以及 `/IWFND/MAINT_SERVICE` 之间到底是什么关系。SAP 在 RAP 相关文档里把这套模型定义得很清楚，RAP 本身负责业务对象与服务暴露模型，而部署层面是否走 embedded，还是继续走 hub，要看系统版本、Fiori 前端策略和运维约束，不是由 RAP 单独决定。([SAP Community][1])

## 先把答案压实一点

如果我们的系统使用的是 ABAP RESTful Application Programming Model，也就是大家熟悉的 RAP，那么 central SAP Gateway Hub 依然可以保留。这一点在 SAP Community 的相关说明里已经给出了非常明确的口径。不过，把 `可以保留` 读成 `仍然推荐继续大规模建设 central hub`，又会走到另一个误区里。对于 SAP S/4HANA 体系，尤其是多个后端系统版本并不一致的 landscape，SAP 更推荐 `embedded deployment`。原因不复杂，Fiori front-end server 的版本耦合、UI 组件依赖、以及跨不同 S/4 版本统一前端层时产生的适配成本，都会让 central hub 的维护成本变高。SAP 在后续的 Fiori deployment guidance 里也多次强调，embedded 是 S/4HANA 的主推荐方向，而 standalone 或 hub 更像是在特定约束下保留的选项。([SAP Community][1])

说得再直白一点，RAP 并没有废掉 Gateway，RAP 只是把服务建模与业务行为的开发方式统一了。系统到底把服务发布到本地端点，还是交给前端 Hub 去激活和路由，仍然是 landscape 设计问题。SAP 的安装与升级文档一直保留了 hub deployment 的描述。以 SAP S/4HANA 1809 为例，官方安装指南明确写到 Fiori 既可以 embedded，也可以 hub 部署，并列出了 hub 场景下前端与后端所需的组件版本。后续关于 SAP FES 2020 的资料也继续表明，hub 并不是消失了，而是版本前提更加收紧，例如对 SAP NetWeaver 7.52 的要求更明确。

## 为什么很多团队会误以为 RAP 出来以后，Hub 就没意义了

误会通常来自 ADT 里的 `Service Binding` 编辑器。创建好 `Service Definition` 之后，再创建一个 `Service Binding`，界面里会出现 `Activate` 按钮，还能看到 `Local Service Endpoint` 这样的字样。很多人一看到这里，就会自然得出一个判断，`既然在 ADT 里点一下就能激活服务，那 Gateway Hub 这层是不是已经被替代了`。这个判断只对了一半。

`Service Definition` 做的事情，是决定哪些实体、投影、行为要被暴露出去。`Service Binding` 做的事情，是把这个服务定义绑定到具体协议上，例如 `OData V2`、`OData V4`，甚至 `SQL` 或 `InA`。官方文档对这一点说得很直接，服务定义负责暴露对象，服务绑定负责选择协议并形成真正可消费的 business service。也就是说，`Service Binding` 解决的是 `服务长什么样、走什么协议`，并不天然等于 `整个 landscape 上的发布与路由已经全部完成`。([SAP Help Portal][2])

再往下看，`Activate` 这个动作也不是一个抽象的全局发布开关，它更接近 `把本地端点发布出来`。SAP 的 ADT release notes 和 RAP 教程都反复提到 `Local Service Endpoint`，而且预览功能依赖这个本地端点已经处于激活状态。在一些文档里，SAP 甚至直接使用 `Publish the local service endpoint` 这样的说法。这就已经把语义讲得非常清楚了，ADT 里的激活，优先解决的是本地开发系统里服务端点可测试、可预览、可本机访问的问题。它不是在自动替代一个独立 Gateway Hub 的运维发布流程。([SAP Help Portal][3])

## 把 Service Binding 和 `/IWFND/MAINT_SERVICE` 的关系掰开来看，就不容易混了

我更愿意把这两者理解成两个层面的动作。前一层是 `服务对象生成与协议绑定`，后一层是 `服务在具体 Gateway 环境中的注册、激活与可访问化`。在 RAP 里，`Service Binding` 的确会在后端侧形成对应的服务对象，这一点在 SAP 对这个问题的说明里已经明确提到了。而如果我们要把它发布为当前开发系统里的本地服务端点，就可以在 ADT 里直接点 `Activate`。可一旦系统 landscape 采用的是 hub 模式，服务真正要被前端 Gateway 体系消费时，`/IWFND/MAINT_SERVICE` 这类 Gateway 激活与维护事务依然有位置。SAP 在相关说明里给出的结论也很直接，若是 hub based system，仍然可以使用 `/IWFND/MAINT_SERVICE`。([SAP Community][1])

这背后其实是一条很典型的企业系统发布链路。假设我们的开发系统是一个 SAP S/4HANA 1909 on-premise 系统，里面已经按照 RAP 的 unmanaged 场景做出了一个简单的 Travel 服务，例如技术服务名类似 `ZUI_C_TRAVEL_M_###`。此时，在 ADT 里创建并激活 `Service Binding`，看到 `Local Service Endpoint` 变成 active，这说明这个服务在本地开发系统里已经有了端点，开发、联调、预览都能往前走一步。可如果生产 landscape 不是 embedded，而是前面还有一个独立的 Gateway Hub 或 Fiori Front-end Server，那么上线时仍然要回到 Gateway 这一侧做注册与激活。这个过程和传统 OData 服务的发布思路并没有突然断裂，它只是被 RAP 的建模对象接上了。([SAP Community][1])

## 这里最容易踩的坑，是把本地可预览，当成全局已发布

这类问题在项目里特别常见。开发人员在 ADT 里点开 `Service Binding`，看到预览按钮亮了，浏览器里也能访问 metadata，就容易默认服务已经完整上线。其实这一步只能证明一件事，本地 Gateway 端点已经可用。SAP 的 ADT 说明写得很明确，服务 URL 与预览按钮的显示，依赖 local service endpoint 处于 activated 状态，而且相关预览能力与具体 binding 类型也有关联。换句话讲，开发工具里看到 `可预览`，和系统 landscape 里 `已经按照目标部署方式发布完成`，不是一个层级的话。([SAP Help Portal][4])

再补一层非常容易忽略的前提，若想在开发系统里使用 `/IWFND/MAINT_SERVICE` 或者 ADT 的本地预览能力，本地 SAP Gateway 本身就必须已经配置好。这个条件在 RAP 的 on-premise 文档里也能看到，SAP 明确要求 Gateway 在 ABAP 系统中正确配置，才能激活和测试最终产生的 OData service。这也解释了为什么有些项目成员明明已经完成了 `Service Binding`，却还是会在测试阶段碰到端点不可访问、预览失败、或者事务里搜不到服务的现象，问题根子并不在 RAP model，而在本地 Gateway 基础设施没有准备好。([SAP Help Portal][5])

## 回到系统架构这块，为什么 SAP 在 S/4HANA 上更偏向 embedded

这件事和 RAP 没有直接冲突，但和项目决策高度相关。SAP 对 S/4HANA 的安装和部署建议里，一直保留 embedded 与 hub 两种大方向。可在真正的大型 landscape 里，central hub 会碰到一个非常现实的问题，不同后端系统可能处于不同的 S/4HANA release，前端层若想统一承接这些系统，版本兼容、SAPUI5 要求、FES 组件级别、Gateway 版本下限都会变得很敏感。SAP 在 Fiori deployment strategy 的说明中，把 embedded 作为主推荐选项，也强调未来方向是在客户侧降低总拥有成本，发展更强的替代方案，而不是继续把传统 central front-end server 当成唯一答案。([SAP Community][6])

我在做 landscape 评审时，更愿意把这件事拆成两种典型场景来看。第一类是单一 SAP S/4HANA 主后端，业务域集中，升级节奏统一，Fiori 应用主要服务这个系统本身。这种情况下，embedded 往往更顺，前后端版本协同简单，运维链条短，问题定位也快。第二类是遗留系统很多，前端治理被放在集团层，或者项目暂时还不能改动既有 Gateway/FES 架构，这时保留 hub 并不奇怪。RAP 不会拦住这条路，只是团队必须明白，`Service Binding` 不是自动把整条 Hub 发布链路都做完了。

## 用一个更贴近项目落地的视角来理解整件事

如果今天正在做一个 SAP S/4HANA 1909 的 on-premise 项目，后端里用 RAP 做了一个 unmanaged Travel BO，开发人员在 ADT 里完成了 `Service Definition` 和 `Service Binding`，本地点下 `Activate`，`Local Service Endpoint` 已经 active，这时开发联调、Fiori Elements 预览、甚至本机测试 URL 都能继续推进。可运维架构团队如果说，生产环境仍旧要通过独立的 FES 或 Gateway Hub 对外提供访问入口，这并不和 RAP 相冲突。研发侧做的，是后端把服务准备好并在本地可用。平台侧做的，是决定该服务最终在 landscape 里通过哪一个 Gateway 实例被注册、路由和暴露。两个动作并列存在，职责并没有重叠。([SAP Community][1])

从这个角度再回头看 `/IWFND/MAINT_SERVICE`，它并没有因为 RAP 出现而突然过时。对于 OData V2 服务，SAP 的大量文档至今仍把它作为 activate and maintain 的核心事务来使用。对 hub 系统而言，它依旧是很关键的治理入口。对本地系统而言，它也仍然是理解服务发布状态、检查 system alias、验证服务可达性的一个很实用抓手。很多团队在 RAP 项目里一碰到访问失败就先怀疑行为实现、CDS 注解、或者 EML 逻辑，其实问题往往比这些简单得多，可能只是 Gateway 侧尚未完成注册或 alias 没配通。([SAP Help Portal][7])

## 名字这件小事，也值得顺手纠正一下

社区里常有人把 RAP 写成 `RESTful ABAP Programming Model`。从 SAP 官方资料来看，更规范的名称是 `ABAP RESTful Application Programming Model`，简称 `RAP`。在部分文档、词汇表和产品说明里，也能看到 `ABAP RESTful Programming Model` 这样的简写表达，但把 `RESTful` 放到最前面，再接 `ABAP Programming Model`，并不是 SAP 主流官方名称。这个细节看上去很小，可在技术方案、培训材料、项目文档里统一术语，其实很重要，尤其是在跨团队沟通时，名称一旦混乱，大家对对象边界也更容易混。([SAP Help Portal][8])

## 最后把结论收紧

RAP 的出现，改变的是 ABAP 里事务型应用和 OData 服务的建模方式，带来的是统一的业务对象建模、行为定义、服务定义和协议绑定能力。它没有直接取消 SAP Gateway，也没有强制所有系统都必须转成 embedded。对于 SAP S/4HANA，embedded 的确通常是更推荐、更省事、总体拥有成本更低的方向。可只要项目约束、历史 landscape 或治理策略还在那里，central SAP Gateway Hub 依然可以继续存在。真正需要团队想明白的，不是 `Hub 还在不在`，而是 `Service Binding` 负责到哪一步，`Local Service Endpoint` 说明了什么，`/IWFND/MAINT_SERVICE` 在目标部署方式里还承担什么职责。把这条链路想清楚，RAP 项目的很多发布争议，基本都会自己消散。([SAP Community][1])

[1]: https://community.sap.com/t5/technology-blog-posts-by-sap/do-i-need-a-sap-gateway-hub-when-using-the-abap-restful-programming-model/ba-p/13393880?utm_source=chatgpt.com "Do I need a SAP Gateway Hub when using the ABAP R..."
[2]: https://help.sap.com/docs/ABAP_PLATFORM_NEW/f2e545608079437ab165c105649b89db/4bad0d7280b742a68dd2d42b1441f09a.html?utm_source=chatgpt.com "Creating Service Binding"
[3]: https://help.sap.com/doc/29ab892a2ddd465eaf74a8d8e1a65994/SHIP/en-US/Create_a_Loyalty_Program_Membership_App_Using_SAP_BTP_ABAP_Environment.pdf?utm_source=chatgpt.com "Create a Loyalty Program Membership App Using ..."
[4]: https://help.sap.com/doc/b5d962b873bf412c82b7ea4b65f8a383/Dev/en-US/adt_abap_development_release_notes_EN.pdf?utm_source=chatgpt.com "ABAP Development Tools Release Notes"
[5]: https://help.sap.com/doc/7dc426856bc640bf98e9e345a0736cf4/1909%20FPS00/en-US/ABAP_RESTful_Programming_Model_On-Premise_EN.pdf?utm_source=chatgpt.com "ABAP RESTful Programming Model"
[6]: https://community.sap.com/t5/technology-blog-posts-by-sap/sap-fiori-deployment-options-and-sap-fiori-front-end-server-strategy-update/ba-p/13444527?utm_source=chatgpt.com "SAP Fiori deployment options and SAP Fiori front-e..."
[7]: https://help.sap.com/doc/saphelp_nw75/7.5.5/de-DE/1b/023c1cad774eeb8b85b25c86d94f87/frameset.htm?utm_source=chatgpt.com "Activate OData Service in the SAP Gateway Hub ..."
[8]: https://help.sap.com/docs/ABAP_PLATFORM_NEW/cc0c305d2fab47bd808adcad3ca7ee9d/289477a81eec4d4e84c0302fb6835035.html?locale=en-US&state=PRODUCTION&version=202009.latest&utm_source=chatgpt.com "ABAP RESTful Application Programming Model"


在做 RAP 方案设计时，我最常听到的一类问题，不是 RAP 能不能做 OData，也不是 Fiori Elements 能不能直接消费，而是另一句更容易把人带偏的话，既然已经用了 RAP，是不是就不再需要 SAP Gateway Hub 了。这个问题如果只用一句话回答，很容易把项目带进误区。更准确的结论是，RAP 并没有把 central Gateway hub 这种部署方式直接判死刑，Hub 仍然可以存在，仍然可以工作，尤其是在一些历史包袱较重、系统边界已经形成、或者前端集中治理要求很强的 landscape 里，这条路依旧是成立的。原始问题里真正让人困惑的地方，不是 Hub 能不能继续存在，而是 RAP 里的 Service Definition、Service Binding、本地激活、以及 /IWFND/MAINT_SERVICE 之间到底是什么关系。SAP 在 RAP 相关文档里把这套模型定义得很清楚，RAP 本身负责业务对象与服务暴露模型，而部署层面是否走 embedded，还是继续走 hub，要看系统版本、Fiori 前端策略和运维约束，不是由 RAP 单独决定。(SAP Community)

RAP 上线之后，SAP Gateway Hub 还要不要留着，关键不在能不能用，而在服务到底发布到哪里

在做 RAP 方案设计时，我最常听到的一类问题，不是 RAP 能不能做 OData，也不是 Fiori Elements 能不能直接消费，而是另一句更容易把人带偏的话，既然已经用了 RAP，是不是就不再需要 SAP Gateway Hub 了。这个问题如果只用一句话回答，很容易把项目带进误区。更准确的结论是，RAP 并没有把 central Gateway hub 这种部署方式直接判死刑，Hub

紫薇堂堂主

后端

架构设计

开发工具

RAP模型并未取代SAP Gateway Hub，两者可共存。RAP统一了业务对象建模和服务定义，而Hub仍适用于历史系统或集中治理场景。SAP推荐S/4HANA采用embedded部署降低成本，但Hub在特定约束下仍有效。ServiceBinding负责本地端点激活，而/IWFND/MAINT_SERVICE仍是Hub模式下服务注册的关键事务。

路由

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

RAP模型并未取代SAP Gateway Hub，两者可共存。RAP统一了业务对象建模和服务定义，而Hub仍适用于历史系统或集中治理场景。SAP推荐S/4HANA采用embedded部署降低成本，但Hub在特定约束下仍有效。ServiceBinding负责本地端点激活，而/IWFND/MAINT_SERVICE仍是Hu...

RAP 上线之后，SAP Gateway Hub 还要不要留着，关键不在能不能用，而在服务到底发布到哪里-腾讯云开发者社区-腾讯云

RAP 上线之后，SAP Gateway Hub 还要不要留着，关键不在能不能用，而在服务到底发布到哪里

RAP 上线之后，SAP Gateway Hub 还要不要留着，关键不在能不能用，而在服务到底发布到哪里

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐