企业官网建设流程全解析

拿到一条 SAP OData 服务地址，在浏览器里敲回车，弹出一屏 XML，第一眼能看到一串<atom:title>下面挂着SalesOrderCollection、CustomerCollection这样的名字，大多数人的反应是：这玩意儿到底怎么用？我见过不少同事在这个阶段卡住，要么把 Service Root 当成接口文档反复问后端，要么直接把整份 $metadata 复制进代码里，然后对着 400 报错发呆。

我个人的经验是，SAP OData Requests 的门道不在语法表里，而在“请求路径和业务模型如何互相映射”这件事上。Service Root 只是门牌号，真正决定你能不能从订单表读到行项目、从客户主数据跳到销售单据的，是你有没有读懂后面那两份关键文档：Service Document 和 $metadata。这篇文章我就按实际调试的顺序，把一条 OData 请求从 Service Root 到具体业务操作完整拆开讲，适合正在做 SAP 集成、Fiori 前端开发、或者被外部系统对接需求折磨的读者，读完后你至少能独立拼出、调通绝大部分常用请求。

1. 从 Service Root 开始：第一步请求决定了后续所有思路

1.1 Service Document 里到底有什么

Service Root 就是服务的根地址，SAP 网关服务通常长这样：

https://your-server.com/sap/opu/odata/sap/API_SALES_ORDER_SRV/

在这个地址上发一个 GET 请求，SAP Gateway 会返回 Service Document。你打开看到的 XML 里，核心内容就是一个又一个<atom:collection>标签，每个 collection 的href指向一个 EntitySet 名称。以销售订单服务为例，你大概率会看到：

• SalesOrderCollection：销售订单抬头集合
• SalesOrderItemCollection：销售订单行项目集合
• CustomerCollection：客户主数据集合
• ProductCollection：物料主数据集合
• SalesOrderTextCollection：订单文本集合

注意，这里返回的只是集合名，不是数据。Service Root 不拉任何业务数据回来，它只告诉你“这个服务里有哪些资源的入口”。我把这理解为图书馆的楼层索引：你知道三楼有历史类图书，但你并不知道具体书名，得走上去翻书架。

这一步最容易被忽略的价值是：EntitySet 的命名风格能透露出服务的设计逻辑。比如 SAP 标准 API 服务经常用A_前缀加业务对象结尾（A_SalesOrder对应订单抬头），自定义服务则常常是 Z 开头的集合名。看到Collection结尾的就默认它是集合请求，看到单个名词且带括号键值的就像是单实体请求，这个判断能帮你少走很多弯路。

1.2 不同部署形态下 Service Root 的差异

实际项目里你还会遇到路径变化。老一点的系统可能是嵌在业务实例里的网关，服务路径会是：

https://your-server.com/sap/opu/sap/<服务名>/

而较新的部署或者集中式网关架构，路径一般统一走/sap/opu/odata/sap/。我建议拿到服务地址后先不要猜，直接用浏览器访问，如果能看到 XML 的 Service Document 就说明地址对。如果返回 404，优先检查路径里是odata还是sap，再看服务名大小写是否一致——SAP 的服务名对外部请求是大小写敏感的，api_sales_order_srv和API_SALES_ORDER_SRV可能一个能通、一个 404。

这一步还有一个常见坑：登录认证。直接访问会弹出登录框，输入账号密码后能拿到文档。很多外部系统对接时会发现浏览器能打开、但代码里请求就是 403，大概率是认证方式不对。SAP 网关支持 Basic Auth、表单登录、SSO 等多种方式，外部集成优先确认网关暴露的是 HTTP Basic 还是 SAML。具体方式去问 Basis 或者负责网关配置的人，不要自己在代码里瞎试。

1.3 用 Service Root 快速确认服务健康状态

我把 Service Root 当成服务的“健康检查接口”。集成联调开始前，先发一个 GET 到根地址，观察几个东西：

• HTTP 状态码是不是 200
• Response 里是否包含预期的集合名
• 返回时间是否在可接受范围（如果根地址都超过 5 秒才返回，后面拉数据大概率更慢）

如果集合列表里少了你需要的资源名，那不用继续往下测了，直接找后端确认服务是不是发布错了版本。这个前置检查特别适合多环境切换时使用——测试环境、预生产、生产各打一遍根地址，对比集合名差异，能抓出一堆环境配置不一致的问题。

2. 第二份关键文档：$metadata 就是系统的业务地图

2.1 EntityType 与 EntitySet 的关系

Service Root 只给了集合名，而集合里每个元素长什么样、有哪些字段、字段之间怎么关联，全在$metadata里定义。你只需要在 Service Root 后面拼上$metadata就能拿到：

https://your-server.com/sap/opu/odata/sap/API_SALES_ORDER_SRV/$metadata

这份 XML 通常很长，几千行很常见。里面最重要的一组概念是 EntityType 和 EntitySet。EntityType 是结构定义，描述订单有哪些字段、各字段什么类型；EntitySet 是资源入口，代表实际可查询的数据集合。用生活里的例子说，EntityType 是房子设计图，EntitySet 是小区里的一栋栋楼。设计图上写着“有客厅、两间卧室、一个卫生间”，楼栋则是指向具体单元入口的指示牌。你在请求 URL 里用的是 EntitySet 名，而返回的每条数据对应一个 EntityType 实例。

访问SalesOrderCollection返回的每一条订单记录，其字段结构和SalesOrder这个 EntityType 的定义一致。请求里能过滤哪些字段、能展开哪些子表、哪些字段可写，也几乎都由 EntityType 上的定义决定。所以读懂 $metadata，本质上就是读懂这个 OData 服务的业务能力边界。

2.2 五类核心元素的读法

$metadata 里看似标签繁杂，但实际工作中你只需要抓五类信息。

第一是属性定义。看EntityType里的<Property>标签，属性名、类型、可空性、是否主键都在这里。SAP 的 OData 服务里字段类型一般映射自 ABAP 的数据元素，所以你可能会看到Edm.String、Edm.DateTimeOffset、Edm.Decimal这些类型。一个常见新手误区是拿Edm.DateTime和Edm.DateTimeOffset混用，过滤日期时该用 Offset 的用了 DateTime，网关直接返回 400。

第二是导航属性。<NavigationProperty>标签，比如：

<NavigationProperty Name="ToItems" Relationship="...SalesOrder_To_Item" FromRole="FromRole_SalesOrder_To_Item" ToRole="ToRole_SalesOrder_To_Item"/>

看到ToItems这样的导航属性，你就能想到可以用$expand=ToItems一次性把行项目带出来。导航属性还决定了你能否通过路径直接访问关联数据，比如SalesOrder('10')/ToItems。

第三是关联关系。<Association>标签里的多重性（<End Multiplicity="1" .../>或Multiplicity="*"）告诉你这是一对多、多对一还是多对多。一对多关系里的“一”这端通常可以不带集合名继续导航，而“多”那端返回的是集合类型，格式上会有区别，排查返回结构时先确认多重性。

第四是复杂类型。<ComplexType>是复用的结构组，比如地址信息、合作伙伴角色这种一组字段。它不像 EntityType 有独立集合入口，只能依附在实体上。请求返回 JSON 时，复杂类型会以嵌套对象形式出现。

第五是注解（Annotation）。SAP 服务会在 metadata 里注入大量注解，常见的有：

• sap:creatable/sap:updatable/sap:deletable：判断能否增删改
• sap:filterable/sap:sortable：判断字段是否可用于过滤和排序
• sap:label：字段的业务标签

我曾经遇到一个情况：在表里明明存在的字段，OData 请求返回的 JSON 里就是找不到。后来查 metadata，发现这个字段根本没有映射到 EntityType 的属性列表里。所以遇到返回字段缺失，先查 metadata 确认字段是否暴露，再去纠结后端逻辑，能省很多沟通成本。

2.3 实操：怎么高效定位字段而不是被文档淹没

$metadata 动辄几千行，从头读到尾不现实。我的习惯是直接在浏览器里按 F12 或者用编辑器打开 XML，然后用搜索功能定位。比如我需要查订单的“总净值”字段，就直接搜NetAmount或NetValue。搜到以后，向上找到它所属的EntityType名称，再回到 Service Root 里确认对应哪个 EntitySet。这套“字段名反查”的打法，比漫无目的地看文档快得多。

面对超大 metadata，还可以利用$format参数。有的网关支持$metadata?$format=json，能返回 JSON 格式的定义，树状结构看得更清楚。但这个支持情况因系统版本而异，如果返回的还是 XML，也别觉得奇怪。

另外一个实用技巧：如果你只是做只读查询，不必把 metadata 全量读进代码。运行时解析 SDK 会自动处理，但如果你在写静态类型代码（比如 C# 强类型客户端），建议用工具自动生成实体类，别手写。手写一千个字段的映射类，光类型对不齐就够你调一整天。

3. 拆解一次完整请求：URL 五段式与 HTTP 方法

3.1 OData URL 的构成

读懂 metadata 之后，就能动手拼 URL 了。一条完整的 OData 请求 URL 由几部分顺序拼接而成：

1. 服务根：/sap/opu/odata/sap/API_SALES_ORDER_SRV/
2. 集合名或单个实体路径：SalesOrderCollection或SalesOrderCollection('1000')
3. 导航属性路径：/ToItems，指到关联子集
4. 键值：用括号包起来的字段值，如('1000')
5. 查询选项：?$filter=...&$select=...&$expand=...

举个例子，我要读取单号 1000 的订单抬头信息：

GET /sap/opu/odata/sap/API_SALES_ORDER_SRV/SalesOrderCollection('1000')

返回的是单个对象，不是数组。而如果要查一堆订单，则访问集合本身：

GET /sap/opu/odata/sap/API_SALES_ORDER_SRV/SalesOrderCollection

返回结构里d.results是一个数组（OData V2 JSON 格式）。这条规律特别容易踩坑——同样的请求路径，加不加括号、返回结构完全不同，解析代码自然也要分开写。

再往下一层，导航属性的路径拼接。比如我想拿到订单 1000 的所有行项目：

GET /sap/opu/odata/sap/API_SALES_ORDER_SRV/SalesOrderCollection('1000')/ToItems

这个/ToItems就是在 metadata 里看到的导航属性名。SAP 还有些服务的导航属性名带业务含义，比如ToCustomer、ToSalesOrderItem，多看看 metadata 就能掌握。

3.2 五大 HTTP 方法与语义

OData 的写操作比普通 REST 复杂一档，核心就体现在方法选择上。

GET 是最常用的，用于查询。集合地址返回列表，单实体地址返回对象，配合系统查询选项还能做过滤、排序、展开。

POST 用于创建。注意创建的目标通常是集合地址，请求体放 JSON 或 XML 载荷。比如创建一个销售订单，POST 到SalesOrderCollection，请求体里包含订单类型、销售组织、客户编号这些字段。如果创建成功，SAP 网关会返回 201，响应头里通常有Location，指向新资源的 URL。

PATCH 用于部分更新。只修改你传进去的字段，其他字段不动。SAP 新增的 API 服务对 PATCH 支持普遍较好。同一个逻辑，PUT 则是整体替换，但很多 SAP OData 服务其实没有完整实现 PUT 语义，或者对 PUT 的限制较多。我个人的习惯是：只要服务声明支持 PATCH，就优先用 PATCH。这样不需要在每次更新前先 GET 全量对象再覆盖提交，节省大量传输和出错概率。

DELETE 用于删除，目标通常是带键的单实体地址。

还有一个需要特别说的方法——HEAD。有的网关允许用 HEAD 检查资源是否存在，但支持不稳定，我在集成时一般直接发 GET。

3.3 写操作必须过的 CSRF Token 关

SAP Gateway 对写操作（POST/PATCH/PUT/DELETE）默认要求携带 CSRF Token，这是一个双步过程。

假设我写一个 Python 脚本，用 requests 库走完整流程：

import requests base = "https://your-server.com/sap/opu/odata/sap/API_SALES_ORDER_SRV" auth = ("your_user", "your_password") session = requests.Session() # 第一步：获取 CSRF Token headers = { "X-CSRF-Token": "Fetch", "Accept": "application/json" } resp = session.get(base + "/SalesOrderCollection", headers=headers, auth=auth, verify=False) token = resp.headers.get("X-CSRF-Token") print("CSRF Token:", token)

注意，获取 token 的这个 GET 请求要真正发到集合地址或其他有效资源地址，不能只发到 Service Root。有的系统在根地址上不返回 token，我踩过这个坑。拿到X-CSRF-Token响应头后，后续写操作带上它：

# 第二步：带 Token 创建订单 headers = { "X-CSRF-Token": token, "Content-Type": "application/json", "Accept": "application/json" } payload = { "SalesOrderType": "OR", "SalesOrganization": "1000", "DistributionChannel": "10", "Division": "00", "SoldToCustomer": "0000001000" } resp = session.post(base + "/SalesOrderCollection", json=payload, headers=headers, auth=auth, verify=False) print(resp.status_code) print(resp.json())

如果漏掉 token，SAP 网关会直接返回 403。这个 403 和认证失败的 403 长得一模一样，新手特别容易混淆。判断方法很简单：检查请求头里有没有带X-CSRF-Token，带了还 403，再去查账号权限。

3.4 并发控制与 ETag

SAP 的 OData 服务还需要关注并发控制。响应头里的ETag表示资源当前版本。做更新时如果带上If-Match请求头，值为资源最新的 ETag，网关会在更新前检查版本，防止别人改过之后你再覆盖。如果不带，有的服务会拒绝更新，有的服务则跳过校验直接更新。

实际项目里，外部系统对接时最常见的做法是：

1. GET 目标实体，从响应头取出 ETag
2. 更新前把 ETag 放进If-Match头
3. 提交 PATCH

如果你的业务场景不追求严格的并发控制，又遇到服务强制要求 ETag，很多开发者在数据变更不频繁的情况下直接填If-Match: *，匹配任意版本，也能通过，但要理解这等于放弃了并发保护。这个技巧适合在你确认目标记录没有并发修改风险时使用。

4. 过滤、排序、展开与分页：查询选项怎么组合才不翻车

4.1 $filter 的常用写法与格式坑

$filter 是读取请求里最常用的条件选项，但它的语法真正上手后才觉得别扭。一个标准的日期区间过滤：

GET /.../SalesOrderCollection?$filter=CreationDate ge datetimeoffset'2024-01-01T00:00:00Z' and CreationDate lt datetimeoffset'2024-03-01T00:00:00Z'

注意日期前面必须带datetimeoffset'...'前缀，引号里的格式是 ISO 8601 加 Z（UTC 时区）。有不少外部系统对接的同事喜欢直接把2024-01-01传进去，网关直接 400。还有更隐蔽的坑：某些 SAP 服务用CreationDate字段但类型是Edm.DateTime，这时前缀要写成datetime'...'，写错一样 400。

字符串过滤也是重灾区。OData 里字符串字面量要用单引号包裹：

$filter=SoldToCustomer eq '0000001000'

如果要做模糊搜索，不同 SAP 版本支持程度不一样。老版本服务常用函数substringof：

$filter=substringof('1000', SoldToCustomer)

新版本往往支持contains：

$filter=contains(SoldToCustomer, '1000')

建议拿到服务后先测一下substringof和contains哪个能用。有的服务直接不支持字符串函数，此时就要考虑是不是服务端 OData 版本是 V2 但暴露方式有差异。

4.2 $expand 与 $select 组合使用的三条经验

$expand 是读 OData 最香的功能。一条请求把订单抬头和行项目全部带出：

GET /.../SalesOrderCollection('1000')?$expand=ToItems

如果订单 1000 有十行行项目，返回 JSON 里ToItems.results就是一个数组。这里第一个经验：展开出来的子集合固定放在导航属性名下，且子集合返回格式和顶层集合一样有results包裹，解析时注意层级。

第二条经验：限制返回字段要分层指定。$select只作用于当前层级，想同时裁剪子实体的字段，得在 $expand 里附带上：

GET /.../SalesOrderCollection('1000')?$expand=ToItems($select=SalesOrderItem,Product,MaterialName)&$select=SalesOrder,Customer

这个写法一开始容易漏：只写了$select=SalesOrder，结果 ToItems 里的字段全都返回，数据量大时响应体膨胀得很厉害。画图表示就是括号嵌套，展开里面套 select，这个语法在 OData V2 和 V4 是通用的。

第三条经验：多层展开要命。比如订单带行项目、行项目再带物料信息，写成$expand=ToItems/ToProduct。每多展开一层，网关做的 JOIN 就多一级，后端性能成指数级下降。我曾经把一个三层展开扔到生产环境，单条订单八秒才返回，被业务方追着问。所以展开层级不要超过两层，如果业务确实需要更多深度的数据，宁可分多次请求去查。

4.3 分页机制：nextLink 和 top/skip 的取舍

集合查询结果默认会有条数限制。SAP 网关的默认值通常是 100 条，也可能因为配置而异。当你需要拉全量数据时，分页策略要提前想好。

手动分页用$top和$skip：

GET /.../SalesOrderCollection?$top=50&$skip=0 GET /.../SalesOrderCollection?$top=50&$skip=50

每次跳过的数量累计增加。缺点是数据量大了以后，skip 越大，网关内部扫描越深，性能下降明显。而且如果查询结果里新增了数据，分页会产生重复或遗漏。

服务器自动分页则看响应体。如果你发现返回的 JSON 底部有__next字段（有的版本叫d.__next），说明服务端分出页了。把__next的值直接作为下一次请求的完整 URL，一路跟进到没有__next为止，这是推荐做法。

def fetch_all(url, headers, auth): items = [] while url: resp = requests.get(url, headers=headers, auth=auth, verify=False) data = resp.json()["d"] items.extend(data.get("results", [])) url = data.get("__next") return items

这个循环要注意防止死循环，所以代码里加个最大页数限制。实际调试时，你可以先加$top=1快速验证响应结构，再放开全量拉取。

另外有个参数常被人忽略：$inlinecount=allpages。加上它，响应体会多出d.__count，表示符合条件的总条数，不配合分页时用它判断数据规模非常方便。有的服务要求这个参数和分页配合使用，单独用可能不返回计数。

4.4 排序与大小写

$orderby用来排序：

$orderby=CreationDate desc

多字段排序用逗号分隔：

$orderby=SoldToCustomer asc, CreationDate desc

一个提醒：SAP 网关对排序字段的要求比较严格，字段名必须在 metadata 中有定义且类型可排序。对字符串字段排序时注意大小写敏感性，不同数据库行为不一致，建议在测试环境先验证排序结果是否符合业务预期。

5. 从读请求到写操作：业务导航的实战串联

5.1 完整场景：查客户、读订单、更新备注

理论说再多，不如从头到尾跟一个完整业务流。假设外部系统需要：查客户 1000 这个客户近三天创建的未完成订单，把第一张订单的抬头备注改成“外部系统更新”。

第一步，确认客户主数据在哪个服务。如果是在客户服务里：

GET /.../CustomerCollection?$filter=CustomerNumber eq '1000'

注意有些服务把客户号字段叫Customer，有些叫CustomerNumber，以 metadata 为准。

第二步，去销售订单服务里按客户过滤：

GET /.../SalesOrderCollection?$filter=SoldToCustomer eq '1000' and CreationDate ge datetimeoffset'2024-06-01T00:00:00Z' and CreationDate lt datetimeoffset'2024-06-04T00:00:00Z' and SalesOrderStatus ne 'Completed'

这里的SalesOrderStatus是订单整体状态，字段名和取值范围同样要从 metadata 里查。也可以从OrderLifecycleStatus这类字段找，SAP 不同 API 服务字段命名差异不少。

第三步，把查到的第一条订单带出行项目：

GET /.../SalesOrderCollection('10000001')?$expand=ToItems($select=SalesOrderItem,Product,MaterialName)&$select=SalesOrder,SalesOrderType,SoldToCustomer

第四步，更新抬头备注。先取 CSRF Token（方法见 3.3），然后：

headers = { "X-CSRF-Token": token, "Content-Type": "application/json", "Accept": "application/json" } payload = {"SalesOrderNote": "外部系统更新"} resp = session.patch(base + "/SalesOrderCollection('10000001')", json=payload, headers=headers, auth=auth, verify=False) print(resp.status_code)

如果服务端要求 ETag，还要先把 GET 响应里的 ETag 取出来放进If-Match。注意这单的备注字段名可能是SalesOrderNote也可能是Note，务必查 metadata。

这个流程串起来以后你会发现：Service Root 给你集合入口，metadata 给你字段和导航关系，URL 构成决定你能访问到哪个层级，HTTP 方法决定操作类型。所谓业务导航，无非是这几个要素的组合。

5.2 返回结构解析：V2 的 d 包裹和 results 层级

SAP 的 OData 服务大部分是 V2 协议，返回 JSON 时最外层一定有一个d字段：

{ "d": { "results": [ { "SalesOrder": "10000001", "SoldToCustomer": "1000", "ToItems": { "results": [ { "SalesOrderItem": "10", "Product": "MAT001" } ] } } ] } }

集合返回一定包一层results，单实体返回没有 results 层：

{ "d": { "SalesOrder": "10000001", "SoldToCustomer": "1000" } }

嵌套导航属性如果是集合，同样会有内层results。写解析代码时先打印一次真实响应，确认层级再写通用逻辑，别凭感觉猜。

5.3 常见错误速查表

这个表我用了很多年，每次排错都是先定层，再定位。不要在 400 上花超过二十分钟，先确认是不是 filter 里某个字段名写错，再看是不是类型问题，实在不行就把 filter 拆掉一段段测，肯定能找到元凶。

6. 把经验固化：我常用的调试流程与工具习惯

6.1 三板斧：REST 客户端、网关日志、抓包

浏览器直接访问 OData 接口只能测 GET，写操作没法在地址栏里完成。我最常用的工具是一个带图形界面的 REST 客户端，发 GET、POST、PATCH 都很方便，还能自动带上认证。项目环境里如果允许，也可以在 SAP 网关的调试客户端里查请求处理和响应详情。不过那不是所有人都有权限，所以外部集成人员更需要一套自己的调试环境。

另一个容易被忽略的工具是抓包。当你的代码请求返回异常但不知道到底发了什么出去时，抓包最能还原事实。我调试过一个问题：代码里明明是带 token 的，服务端却一直报 403，抓包发现是请求头被框架重写了，token 从X-CSRF-Token变成了自定义的别的名字。这种问题不看报文根本发现不了。

日志也是一个重要路径。SAP 网关的日志在出现 500 错误时价值最大，因为它能记录后端 ABAP 程序的具体报错。排查跨系统集成问题时，让 Basis 或后端同事把网关日志导出来，配合请求号，基本能把问题定位到具体函数模块。

6.2 请求头里的几个隐藏关键点

除了前面说的X-CSRF-Token和If-Match，还有几个请求头对 SAP OData 请求影响很大。

Accept头决定响应格式：

Accept: application/json

如果不带，有的服务默认返回 XML，解析代码就要跟着变。在外部集成时尽量统一指定application/json。

Content-Type在写操作时指定：

Content-Type: application/json

如果你做 PATCH 但请求体是 XML，Content-Type 也要相应改成application/xml。混搭会造成网关无法解析请求体。

DataServiceVersion也是容易踩坑的点。SAP 老版本网关要求请求头必须带DataServiceVersion: 2.0。新版本不强制，但如果你在使用一个比较老的服务并发现请求报错，可以尝试手动加上这个头，有时候问题立刻就解决了。

6.3 从 Service Root 到代码生成：减少重复劳动

把 Service Root 和 metadata 读透之后，最实在的收益是你能用工具把客户端代码直接生成出来。社区里有很多 OData 代码生成器，输入 metadata 地址，自动生成强类型的客户端类。这样字段名、导航属性、集合名全部有类型约束，编译期就能发现拼写错误，不用等到运行时。

我个人的建议是：生成代码别全盘照搬。生成器对 SAP 某些自定义注解支持不一定好，而且生成的文件特别大，直接塞进项目会让代码仓库臃肿。更实际的做法是只生成你需要的几个 EntitySet 对应类，手写包装类统一管理请求路径和认证逻辑。

还有一点：把 Service Root 地址和常用集合名、关键 filter 字段写进项目的配置文件或 Wiki 里。一个服务的接口信息，最怕只存在某个人的邮件里，没人维护。我见过太多项目，服务上线半年后，原始对接人调走了，新来的同事花了一星期反查 metadata。把这些信息沉淀下来，后面每个人对接都能省半天时间。

7. 最后分享一个我常用的排查小技巧

当 Fiori 界面某个列表显示的数据和你用 OData 请求拉回来对不上时，不要急着怀疑数据不一致。先在浏览器开发者工具里打开 Network 面板，找到该列表发出去的那条 OData 请求，看看它用了什么 filter、什么 expand。Fiori 应用会按自己的逻辑组装 OData 请求，你复制它的 URL 到 REST 客户端里执行一遍，往往立刻就能看出差异源头。这个方法我试过很多次，几乎每次都能快速定位问题是出在过滤条件、展开层级，还是后端映射上。

做 SAP OData 集成这件事，说穿了就是“三件套”：用 Service Root 找资源入口，用 metadata 理解业务结构，用正确的 URL 加请求头去拿你要的数据。把这三段流程练熟了，面对任何新服务，你都不会再有“从哪下手”的迷茫。