企业官网建设流程全解析

1. 项目概述：为什么非要从 RFC/BOR 走向 OData

先说结论：这年头谁的企业里都沉淀着一堆老接口，RFC 功能模块一大把，BOR 业务对象也不少。它们运行稳定，承载着核心业务逻辑，突然说要上移动端、上第三方对接、上云集成，你不可能把以前写的 ABAP 代码全部推倒重来。最务实的路，就是让老接口在新协议栈里发光发热——把 RFC/BOR 封装成标准 OData 服务。这正是 SEGW（SAP Gateway Service Builder）中 Interface Import 存在的最大意义。

我见过不少团队栽在同一个坑里：拿到需求就手工创建 Entity Type，把数据模型从零搭一遍，结果服务发布后问题一堆——字段名对不上、类型不匹配、性能缓慢，甚至写入操作完全不可控。而 SEGW 的 Interface Import 恰恰可以避免这些问题，它允许你从已有的 RFC 功能模块或 BOR 对象类型生成 OData 服务骨架，最大程度复用现有接口逻辑，保留底层校验和业务规则。这篇文章会把我的实际项目经验彻底摊开：什么时候用 RFC 导入、什么时候用 BOR 导入、实体与关联怎么映射、函数导入的细节，以及最后一步我怎么在 IWFND（SAP Gateway Foundation）上把服务调通。

有个非常关键的认知必须调整：SEGW 不是“重新开发”的地方，而是“适配”和“暴露”的地方。你写的 Entity Type 本质上是给前端看的对外契约，而真正干活的，还是你后端那些已经跑了多少年的 RFC 和 BOR 方法。换句话讲，SEGW 要解决的问题就是：老接口的入参出参长啥样，前端消费者就得按啥样传参和接数据。理解了这个，后面一切操作都顺理成章。

这套内容适合谁？如果你想了解如何把已有的 SAP 后台功能以 OData 的方式开放出来，尤其是你有 ABAP 开发基础但刚接触 Gateway 技术；或者你做项目实施，负责集成方案设计但一直没搞清楚“RFC 怎么映射到 OData 服务”的细节——这篇文章就是给你准备的。我会从数据模型设计讲到函数导入映射，再到常见的报错排查，尽量把能踩的坑都提前说出来。

2. 整体思路拆解：先建模再映射，别一上来就写码

2.1 接口导入的本质是“翻译”而非“重写”

在动手之前，得先明确 Service Builder 里“接口导入”到底做了什么。SEGW 的 Interface Import 是一个桥接机制，它读取你指定的远程启用的函数模块（RFC Function Module）或业务对象类型（BOR Object Type），反向分析其参数结构、表类型、异常等元数据，然后自动生成对应的数据模型元素。相应地，你在 SEGW 中建立的 Entity Type 只是映射外层，真正的执行逻辑仍由底层 RFC 或 BOR 方法承担。

这种设计带来了两个好处：

• 语义复用：所有预校验、权限检查、业务逻辑完整保留，不因接口暴露形式改变而产生行为偏移。
• 开发效率：不需要手工维护模型定义，导入后能自动生成大部分代码骨架。

但这里有一句长期总结出来的心得：接口导入只负责骨架，不负责业务质量的优化。你仍需要在生成的模型基础上，调整属性名、修改值列表来源、添加合适的过滤条件甚至重写查询逻辑。毕竟 RFC 时代的输入输出参数命名和字段语义，并不是专门给 OData 消费者准备的。

2.2 三种导入路径的选择策略

SEGW 界面里直观可用的导入方式有三种：RFC、BOR 和自定义导入。先把它们适用场景理清楚：

从我的项目经历看，选型基本可以按如下逻辑判断：如果只是查询类接口，RFC 导入最直接；如果对象管理涉及状态机或复合操作，BOR 导入更贴近原始业务语义；如果你做好了 Service Provider 的代码架构，希望 OData 操作对应到类方法而不是单一函数，那自定义导入会更灵活。没有绝对优选的路径，唯一要避免的是“什么都不想，抓到啥用啥”。

2.3 为什么先要梳理接口清单再创建项目

实践中最容易忽视的一步，是在 SE Gateway Builder 里建项目之前，先把要暴露的 RFC/BOR 接口梳理清楚。很多项目做到一半才发现：A 功能依赖的数据源是普通函数模块，没做远程启用；B 对象类型的状态字段没开放；C 接口的参数里居然混着十几个 unused 字段——这种返工成本远比设计阶段多花半天整理要高得多。

因此建议的步骤是：

1. 在 SE37 中列出待暴露的功能模块清单，确认“Remote Enabled”勾选状态。
2. 检查参数结构：哪些是必输、哪些有默认值、哪些是表参数需要作为集合返回。
3. 在 SWO1 中梳理 BOR 对象类型的关键方法，查看对象类型释放状态和属性可读性。
4. 和前端团队约定好需要的操作类型（只读还是可写）以及字段列表，避免把后台所有字段平铺暴露。

我在一个真实项目里做过一次彻底精简：拿需求文档逐项核对后台字段，最后对外暴露的 Entity Type 只有内部表实际返回字段的三分之一，但前端体验反而更好了，因为接口字段少、语义清晰，联调时间压缩了一半以上。接口设计不是做田园烤全牛，什么料都往上堆。

3. RFC 导入实操：从函数模块到 Entity Type 的逐步细节

3.1 前置条件检查：Java 环境之外最容易卡壳的点

这里得先说个真实教训：SEGW 运行界面什么都进去了，就是没找到“RFC”导入选项，或者导入列表为空。原因通常不在 Gateway，而在后台 RFC 源未正确声明。

需要检查的项如下：

• 函数模块必须勾选“Remote Enabled Module”。在 SE37 的属性页里，如果该选项为灰色不可勾选，说明当前函数模块所在包或程序属性受限，需要调整对象属性或选择建议更新。
• 如果是函数组（Function Group）级别的批量导入，确认函数组下所有子程序都是 RFC 兼容类型。
• 函数模块的导出参数或表参数中，如果使用了个性化的深层结构（Nested Structure），在导入时能生成 Entity Type，但后续要留意序列化时的字段展开规则。
• 导入时若报“RFC module not found”，多半是系统间 RFC 信任关系或命名空间前缀问题，而不是 SEGW 本身设置。

为了减少连基本准备都没做好就卡在第一步的尴尬场面，我一般会在 SE37 里先用一个测试脚本调用目标函数模块，把输入输出跑一次并记录下来结构路径，再回到 SEGW 里做导入。这下心里有底，甚至在导入后对比自动生成字段，一眼就能发现哪些字段没被成功捕获。

3.2 详细导入操作路径与参数含义

下面按我在项目中的实际操作顺序来写，注意每一步的意义不只是“点完就完事”。

1. 打开事务码SEGW，创建新项目（建议命名带上业务前缀，比如ZOD_MM_GRP）。
2. 在项目的地图结构树中，右键“Data Model”，选择“Import from RFC”。
3. 系统弹出选择界面，输入函数组或单个函数模块名称。此时建议用F4帮助检查函数模块是否可被列表识别。
4. 选择要导入的对象后，确认生成选项。此处两个关键选项值得说明：
   • Create Entity Types：会为每个结构/表生成一个 Entity Type。如果你希望后续手工合并调整，暂时不必全选，可以先选核心结构，再手工维护其余属性。
   • Create Function Imports：将每个 RFC 调用映射为一个函数导入。这个选项比较激进，因为一个 RFC 对应一个函数导入会让服务操作非常多，前端调用体验会很啰嗦。我建议第一遍只导入模型，函数导入按需手工创建。
5. 点击完成后，SEGW 会生成 Entity Type 及其属性列表，并在 “Runtime Artifacts” 中生成 DPC/DPC_EXT 和 MPC/MPC_EXT 类骨架。

关于属性列表，自动生成的字段名通常沿用 ABAP 结构中的字段名，如果语义含糊（比如BUKRS），如果公司代码在前端语义里叫“Company Code”，建议在 MPC 里做属性注释或使用@EndUserText.label标注。注意属性列表的类型映射：ABAP 的C类型会映射到 EDM.String，I类型映射到 EDM.Int32，D类型映射到 EDM.DateTime，F类型映射到 EDM.Decimal 或 Single，具体看系统配置。

一个常见误区：导入完成后直接按 F8 注册服务，然后测试。你大概率会发现 GET_ENTITYSET 根本调不通，因为运行时框架只是生成了骨架代码，没有真正的 DPC 方法实现逻辑。下一步必须进入 DPC 扩展类，在对应方法里调用 RFC。

3.3 在 DPC 扩展类中写 RFC 调用逻辑

在 SEGW 生成的 DPC_EXT 类中，针对你要实现的操作，比如GET_ENTITYSET，双击方法进入代码编辑器。常见实现方式是：

METHOD get_entityset. DATA: lv_matnr TYPE matnr, lt_return TYPE TABLE OF zstruc_material. " 从请求对象中读取过滤条件 io_tech_request_context->get_converted_values( IMPORTING es_filter_values = ls_filter ). lv_matnr = ls_filter-matnr. " 调用原始RFC函数 CALL FUNCTION 'ZRFC_MATERIAL_GET' EXPORTING iv_matnr = lv_matnr TABLES et_data = lt_return. " 转换为实体类型数据源 et_entityset = CORRESPONDING #( lt_return ). ENDMETHOD.

这里有三处细节需要特别提醒：

• io_tech_request_context是获取查询选项、过滤条件、排序字段的核心接口，不要只取is_filter参数，很多情况下分页、排序逻辑也用到这个请求对象。
• 如果函数调用失败需要抛异常，用RAISE EXCEPTION TYPE /IWBEP/CX_MGW_BUSI_EXCEPTION并设置message_text，这样前端能收到容易识别的错误提示。
• 对于表参数返回，CORRESPONDING语法在较新的 ABAP 版本可以很好地完成字段映射，但如果两个结构字段名有差异，需要手工赋值或建立一个显式转换结构。

在GET_ENTITY单条查询中，逻辑类似，区别是要从 keys 中取得主键。假如主键是material_guid，注意 SEGW 模型中你定义的Key Properties是否与 RFC 返回字段匹配。我之前接过一个系统，导入后主键字段没自动生成，必须手工勾选并设置合适的键属性。这一步若遗漏，OData 元数据就会异常，前端框架经常直接报 500。

3.4 函数导入（Function Import）的映射要点

对于执行类的 RFC，例如创建单据、执行动作，把它映射成一个函数导入更合理——前端调服务时看起来像POST /MaterialSet('xxx')/Confirm，比模拟 CRUD 更新自然很多。

在 SEGW 中右键 Function Import 创建新条目时，要指定：

• 函数导入名称（对前端暴露，建议动词开头，如ConfirmReceipt）。
• 关联的 Entity Set（通常是返回结果的主实体集合）。
• 返回类型：单一实体还是集合。注意如果 RFC 只返回执行消息而不返回实体，选None即可，同时可以在角色配置中把返回设置为空数据，只响应状态码。
• 输入参数：这里的参数来源可以引用 Entity Type 的既有属性，也可以单独定义内部结构参数节点。我实际处理中，对于“审批”类操作，通常只传业务单据编号和审批结果，这样保证接口语义最小化。

函数导入的 URL 模板和 HTTP 方法定义可以在 MPC 扩展类中调整，但通常默认POST即可。请求体 JSON 里的字段名需要与参数结构保持一致。

有次前端团队问 “为什么我不能用 GET 调用函数导入？”这涉及 OData 协议约束：函数导入在无实体返回或副作用明确的情况下必须使用 POST。这是协议规定，不是 SAP 自定义限制。与其想着绕开，不如提前要求前端遵守规范。

4. BOR 接口导入与实体操作映射实践

4.1 BOR 导入能省多少事

BOR 对象类型其实就是 SAP 业务对象的元模型，承载了对象的属性和方法定义。之所以在 SEGW 里支持 BOR 导入，是因为很多业务场景以前是基于 BOR 对象写的经典代码，比如BUS2015（采购订单）、BUS1001（物料）等。如果团队内部还有大量基于 BOR 的调用代码，直接转为 OData 服务是自然路径。

在 SEGW 里导入 BOR 的步骤是：

1. 右键 Data Model -> Import from BOR。
2. 搜索 BOR 对象类型名，比如BUS2015。
3. 勾选需要的属性字段，系统会把这些属性映射为主 Entity Type 的字段。
4. 勾选需要暴露的方法，例如CreateFromData、ChangeStatus，这些会自动映射为实体操作或函数导入。

这里的巨大优势：BOR 方法自身有完整的业务对象事件、状态、字段校验逻辑，你不必在 DPC 里再写一堆业务判断。

但也要注意：BOR 对象类型的某些属性有对应的“内部字段语义”，比如状态字段返回内部代码而前端需要显示文本。如果你图省事直接透传，前端就会看到Status = '01'而不是“已创建”。解决方式是在 MPC 的注释或注解里配置值列表，或者在 DPC 中调用函数显式获取描述文本再输出。

4.2 BOR 方法映射到实体操作

BOR 对象类型方法一般分几类：

• 查询类：比如GetDetail、GetList。
• 创建类：比如Create、CreateFromData。
• 修改类：比如Modify、Change。
• 动作类：比如Release、Approve。

建议将查询类映射为GET_ENTITY/GET_ENTITYSET，将创建修改类映射为CREATE/UPDATE，动作类映射为函数导入。SEGW 自动生成的方法实现会基于 BOR 的BUS1111等通用方法模板调用，但代码里你要仔细核对实例的创建方式。

具体到 BOR 调用的经验：CALL METHOD语法需要创建OBJ引用，某些业务对象类型还有CREATE_INSTANCE等特定要求。如果调用后抛出业务异常，务必从RETURN表里提取消息文本，并使用RAISE EXCEPTION TYPE /IWBEP/CX_MGW_BUSI_EXCEPTION包装错误信息传给消费者。我见过太多项目只用通用异常返回一个 “Internal error”，前端排查时根本无从下手，这是极大的体验浪费。

4.3 混合建模：RFC + BOR 协同是常态

现实中，你不会只依赖 BOR 就完成全部接口。ERP 系统里大量涌现的自定义逻辑还是在 RFC 里，BOR 常用于标准对象。因此，同一 SEGW 项目里出现部分实体映射 BOR、部分实体映射 RFC 完全正常。

要留意的是关联关系：如果 BOR 实体和 RFC 实体存在主从关系，你需要建模 Association。比如主数据实体（来自 BOR）与库存实体（来自 RFC）之间，通过物料号关联。在 SEGW 中建立两个 Entity Type 间的单项关联后，可以注释@ODATA.association注解，并在 DPC 里实现GET_ENTITYSET时通过get_expanded判断是否需要联查。这个做法能明显提升服务端的响应数据和语义丰富度。

我在项目里做过一个混源服务：主数据来自 BOR 对象，实时库存来自 RFC 查询，两张实体表通过 SKU 关联。前端一次请求/MainData('SKU001')/InventorySet就能同时获得主数据和库存信息，效果相当好。关键是学会用 Association 而不是在前端调用两个接口然后手工拼数据。

5. 映射细节与数据质量，容易被忽视但很重要的内容

5.1 字段类型映射和空值策略

这是直接影响前后端联调体验的核心地带，很多项目在字段映射上栽跟头。在 SEGW 的 MPC 中，每个属性都有对应的 EDM 类型，常见的坑：

• ABAP 的DATUM（D 类型）直接映射为 EDM.DateTime 后，JSON 输出格式可能带时间部分，前端难以直接显示。建议在 MPC 中修改为Edm.String并做格式转换，或者在 DPC 中输出时格式化YYYY-MM-DD。
• ABAP 的QUAN类型映射为 EDM.Decimal 时，需要声明scale和precision。如果你不做要求，SAP 默认会输出成很大范围的小数，前端显示长度不一致。
• 对允许空值的字段，需要把属性 “Nullable” 设置为 true。很多人忽略这一点，导致前端基于元数据生成表单时空值字段校验异常。

针对输出格式，我通常建议在 DPC 层做一次专门清洗：用CORRESPONDING后，对日期类型、金额类型和代码字段做标准化处理。后端多花三行代码，前端就能省掉大量解析逻辑。

5.2 主键与关联的建模标准

OData 服务的主键设计，直接关系到 URL 语义与缓存行为。从 RFC 导入的表结构，默认主键自动生成可能是因为系统根据主键字段判断失败而设置了可行的 GUID。我在项目里的要求和经验是：

• 主键不能为空，优先使用有业务语义的短键（如物料号、公司代码、单据编号）而不是无意义的内部 GUID。
• 如果使用复合主键，URL 里的参数顺序会影响 OData 集合访问，务必在 MPC 中确认主键顺序。
• 关联的导航属性名尽量用直观名词，比如MaterialSet、InventorySet，避免只出现无意义的Nav1。

我碰到一个系统，由于早期主键选择错误，导致前端每到详情页都要在/EntitySet('如下')的时候拼接一段被 URL 编码搞混乱的长字符串键值，几经波折才定位是主键字段选择不合理。这类问题调试成本极高，建议设计模型和导入后先做一轮主键评审。

5.3 值列表与描述文本：别把内部代码丢给用户

RFC 返回结果通常就两种：代码字段和描述文本字段并存的，或只有代码的。如果你负责暴露给外部系统，且对方需要展示文本，那么服务里必须处理好两个维度：一是代码字段作为 Entity 属性输出，二是描述文本字段作为 “text” 类导航属性或普通属性输出。最省事的做法是后者——在 DPC 中调用对应描述翻译函数补齐text字段。但这会增加调用次数。另一个注意点是，能过滤的字段必须设置Filterable = true并保证在 DPC 中把过滤条件透传给 RFC；否则前端在表格里做筛选时会发现毫无反应。

具体调优上，多用_text后缀，例如status_text和status_code成对，前端直接用status_text展示。有些团队忽略了这个细节，前端每次拿到代码还要调用翻译服务，平白增加一次往返和联调成本。

6. 服务激活、注册与发布，SAP Gateway 全链路联调

6.1 从 SEGW 到 Gateway 的注册步骤

SEGW 建好模型只是第一步，真正把服务暴露到 HTTP 层还需要注册和激活：

1. 在 SEGW 中执行“生成运行时对象”，系统生成 MPC/MPC_EXT、DPC/DPC_EXT。
2. 执行“注册”，此时需要指定后端系统别名（如LOCAL）和包名。完成后 Gateway 中会出现一条服务记录。
3. 进入事务码/IWFND/MAINT_SERVICE（或新版本中的Service Maintenance），添加服务。
4. 激活服务并测试，使用 SAP Gateway Client 或直接通过 URL 访问。
5. 如果你使用的是 Hub 部署架构，需要在后端系统也注册同服务名；若系统统一，则只需一套配置。
6. 最后维护角色授权（S_IWBEP），否则外部消费者收到 403。

这里容易踩的坑是包名选择。如果你手头没有专门存放 Gateway 对象的开发包，系统会建议放到临时包，后来传输时总少对象；更好的做法是先建一个专用的网关包（比如ZGW_MM_ODATA），所有 MPC/DPC 对象统一存放，方便传输与权限控制。

6.2 用 SAP Gateway Client 做冒烟测试

服务激活后，不要急着把 URL 发给前端。打开/IWFND/GW_CLIENT，输入路径测一下：

• 元数据请求：GET /sap/opu/odata/sap/ZMM_MATERIAL_SRV/$metadata，确认实体集合和 Function Import 都正确。
• 集合请求：GET /sap/opu/odata/sap/ZMM_MATERIAL_SRV/MaterialSet，确认返回数据无序列化错误。
• 单条查询：GET /sap/opu/odata/sap/ZMM_MATERIAL_SRV/MaterialSet('SKU001')。
• 函数导入：POST /sap/opu/odata/sap/ZMM_MATERIAL_SRV/ConfirmReceipt，请求体附带参数 JSON。

常见报错之一是No batch available，这往往是因为服务在 SegW 项目中配置了但 DPC 代码没生成完全，重新生成并激活即可。另一个常见问题是 404：服务路径错误，检查 URL 中服务名与注册名是否一致，注意大小写。

联调阶段如果遇到返回异常，第一件事就是看 SAP Gateway 错误日志，事务码/IWDGN/ERROR_LOG或/IWFND/ERROR_LOG，系统会记录 DPC 抛出异常时的详细堆栈。这比盲猜强得多，也比前端反馈的“500”更能定位问题。

6.3 生产发布前的性能检查

发布前做一次性能检查特别值得投入，很多问题只有模拟生产数据量才会显现。重点检查：

1. 过滤条件下推：RFC 内部是否使用数据库条件的完整字段，还是先全量取再逐行过滤。后者在十万级数据量下直接卡死。
2. 分页处理：OData 默认每个请求需要返回一定数量的行，如果 RFC 不支持分段返回，需要在 DPC 中截断或使用游标多次获取再进行序列化。
3. 缓存策略：对于常用的主数据，可考虑使用ETag或 SAP Gateway 的缓存配置。
4. 围栏（$expand）开销：如果实体存在关联关系，一个$expand会把多个集合的查询串在一起，注意每个子查询是否都有独立的 RFC 调用开销。
5. 序列化大小：输出结构中大量无用字段会增加传输数据量。尝试精简结构，但要注意影响面。

最直观的性能优化手段是“在后台 RFC 中完成大部分聚合计算，而不是在 DPC 内存中手工拼接”。我见过一个案例：某开发者在 DPC 中对实体循环调用 RFC 获取明细，导致请求耗时从 0.3 秒膨胀到 8 秒。后来改成一次性传入多值范围，整体性能立刻回归正常。

7. 常见问题与排查技巧实录

7.1 按症状分类的排查速查表

说几个代表性场景，都是我实际项目中出现过的。

到底怎么快速定位问题，我认为最有效的从不是“看代码猜”，而是：

1. 先用 Gateway Client 的日志功能开启单步追踪，能看到 DPC 的每个方法调用链。
2. 在 DPC 方法中设置断点，用调试器观察 RFC 调用前后的数据变化。
3. 当无法在调试器中定位时，在 RFC 入口处自定义一个内存日志点，记录关键入参和返回行数。

这套组合拳基本能覆盖九成的问题。

7.2 数据量大时最容易忽略的坑

性能问题时，先检查的是有没有在GET_ENTITYSET中正确读取分页参数。框架支持$top和$skip，但如果你不用请求对象的get_top/get_skip，那么无论前端怎么传，后台都全量返回——结果浏览器先在网关层穿越了一次，网络传输还拖垮了前端。这是比较基础的问题。

另一个容易被忽略的是$count计数请求。如果集合查询支持$inlinecount=allpages，DPC 里必须额外计算符合条件的总行数，如果没有实现，前端的分页组件会永远显示“未知总数”。SAP 自带 MPC 默认可能不会帮你精确计算，所以需要调用一次 RFC 的“总数”参数或在 RFC 返回的基础上做一次聚合计数。这个动作往往被人遗忘，直到验收阶段才发现分页总数不对。

7.3 消息处理与错误传播的最佳实践

很多前端团队最大的痛点不是逻辑错，而是后台错误信息看不懂。OData 的error响应结构允许嵌套message和detail，你在 DPC 中抛异常时应当充分利用：

DATA: lo_busi_exc TYPE REF TO /iwbep/cx_mgw_busi_exception. CREATE OBJECT lo_busi_exc EXPORTING message_text = lv_error_msg. RAISE EXCEPTION lo_busi_exc.

这样前端拿到的是可读的业务错误消息，而不是 “Internal Server Error”。一定要避免随意抛出系统级异常，因为 SAP Gateway 默认会包装成很难看的结构，而且记录不到完整上下文。

还有一点心得：在 DPC 中尽量统一设计一个错误码映射规则，例如E_INSERT_FAILED、E_INVALID_STATUS。对外暴露时，把业务异常码放到error_code字段，便于前端做类型判断和国际化多语言。如果只传中文message，后面遇到国际化需求时整个服务都得改。

8. 经验总结：三个实用建议与一个扩展方向

项目做到后来，我逐渐形成了几个固定习惯，在这里写成建议供你参考：

1. 坚持一个服务一个语义主题。不要在一个 OData 服务里塞超过三个无关的实体集合，否则权限控制和缓存策略越来越复杂，而且 URL 结构混乱。若相关实体太多，拆成独立服务并用函数导入或导航属性连接更舒心。
2. 新建 SEGW 项目后立刻建好命名规范。服务名、实体名、属性名、函数导入名的严格规范能显著降低后期沟通成本。比如实体名统一用业务名词单数，属性名统一用 CamelCase，避免一个项目里混用下划线和缩写。
3. 接口文档在建模阶段就要同步维护。OData 元数据本身就是接口契约，但元数据可读性较差。建议输出业务层面的字段文档，尤其是字段取值字典、默认值、是否必输、过滤方式。这项投入会在联调和后期运维阶段加倍收回。

最后说一个我最近在尝试的扩展方向：将 SEGW 暴露的 OData 服务再通过数据集成框架推送到非 SAP 环境的中间件，甚至由第三方案件直接订阅 OData 数据。这个架构里，核心并不仅仅是 SEGW 本身，而是你从 RFC/BOR 时代带来的业务逻辑沉淀到底层接口的可靠性和语义完整性。接口设计始终在做“翻译”工作，但翻译得好不好，取决于你对业务对象的理解，而不只是你会不会 SEGW 操作。

或者从更长远来看，Abap 环境越来越强调“接口资产化”，你现有的这些 RFC 功能模块不会消失，它们只是换了一套表达方式，从传统的 ABAP 内部调用，变成了标准 HTTP 协议下可被任何语言消费的 OData 服务。理解并实践这一点，比多写几个模型类更有价值。