在一个运行时间足够长的 SAP S/4HANA 系统里，OData 服务数量通常会越来越多。最早可能只有几十个服务，后来随着 SAP Fiori 应用、自定义 UI5 应用、移动端、外围系统集成以及各种扩展需求不断增加，服务目录很容易膨胀到几百甚至更多。到了这个阶段，一个很现实的问题会冒出来。开发人员知道系统里存在很多 OData 服务，却不知道某个业务需求到底该消费哪一个服务。例如我们正在开发一个工作流相关的 SAP Fiori 应用，需要查找所有和 Workflow 有关的服务。面对一堆类似ZWORKFLOW_SRV、TASKPROCESSING_SRV、MYINBOX_SRV、APPROVAL_SRV的技术名称，仅仅依靠服务名称搜索并不可靠。更麻烦的是，有些服务名称体现的是内部技术命名，而真正有价值的信息藏在 Entity Set 里面。SAP Gateway Foundation 为这类场景提供了一个很容易被忽略的能力，Service Tagging。它并不是给 OData 数据本身打标签，而是在 SAP Gateway Service Catalog 层面，为 OData 服务增加可以被检索、分类和组织的语义信息。消费端开发人员由此可以从业务含义出发寻找服务，而不是完全依赖对技术服务名称的记忆。SAP 官方文档明确把这一能力定位为帮助消费开发人员发现和探索适合其使用场景的服务，并同时提供标签和搜索能力。如果把整个 SAP Gateway Service Catalog 想象成企业内部的 API 商店，普通的服务注册解决的 SAP Gateway Service Tagging 深入解析，给 OData 服务目录建立一套可搜索的语义索引
在一个运行时间足够长的 SAP S/4HANA 系统里，OData 服务数量通常会越来越多。最早可能只有几十个服务，后来随着 SAP Fiori 应用、自定义 UI5 应用、移动端、外围系统集成以及各种扩展需求不断增加，服务目录很容易膨胀到几百甚至更多。到了这个阶段，一个很现实的问题会冒出来。开发人员知道系统里存在很多 OData 服务，却不知道某个业务需求到底该消费哪一个服务。例如我们正在开发一个工作流相关的 SAP Fiori 应用，需要查找所有和 Workflow 有关的服务。面对一堆类似ZWORKFLOW_SRV、TASKPROCESSING_SRV、MYINBOX_SRV、APPROVAL_SRV的技术名称，仅仅依靠服务名称搜索并不可靠。更麻烦的是，有些服务名称体现的是内部技术命名，而真正有价值的信息藏在 Entity Set 里面。SAP Gateway Foundation 为这类场景提供了一个很容易被忽略的能力，Service Tagging。它并不是给 OData 数据本身打标签，而是在 SAP Gateway Service Catalog 层面，为 OData 服务增加可以被检索、分类和组织的语义信息。消费端开发人员由此可以从业务含义出发寻找服务，而不是完全依赖对技术服务名称的记忆。SAP 官方文档明确把这一能力定位为帮助消费开发人员发现和探索适合其使用场景的服务，并同时提供标签和搜索能力。如果把整个 SAP Gateway Service Catalog 想象成企业内部的 API 商店，普通的服务注册解决的 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
