SAP API 开发方法大全

2022 年 8 月 06 日
本文字数：3045 字
阅读完需：约 10 分钟

本文首先简单回顾一下笔者从事 SAP 开发工作 15 年以来，接触过的各种 SAP API 的开发方式，然后再介绍 SAP Data Intelligence 里遵循 Low Code Development(低代码开发)理念的 API 开发方式。

(1) ABAP function module + SOAMANAGER

最古老的技术，把 ABAP 系统里的函数通过 SOAMANAGER 发布成 Web Service. 虽然古老，但至今 S/4HANA 里的 Service 模块的新功能开发还在使用。

https://blogs.sap.com/2014/05/20/step-by-step-to-create-consume-and-trace-web-service-in-abap-system/

我 2014 年的时候也写过一篇介绍 SOAMANAGER 使用步骤的文章，虽然到现在为止，这个工具已经更新换代多次了。

(2) 基于事务码 SEGW 的 SAP CRM OData 服务手动实现

这是我最熟悉的 SAP OData 服务实现方式，因为我就是 SAP CRM OData 服务的开发者之一。SAP 成都研究院 CRM 开发团队在 2014 和 2015 年开发这些 OData 服务时，SAP Fiori Elements 的前身，当时的名称是 Smart Template，还处于发展初期，所以那时候我们没有选择这项基于元数据驱动的开发方式。

Jerry 在 2018 年写过一篇文章 SAP OData 编程指南，里面详细介绍了这种方法。

(3) 基于 CDS view 的 OData 服务自动生成

再后来，随着 CDS view 和 Fiori Elements 的成熟，我们可以基于加上了 @OData.publish 注解的 CDS view，直接生成 OData 服务了，具体工作原理在我的这篇文章里有介绍：

揭开SAP Fiori编程模型规范里注解的神秘面纱 - @OData.publish工作原理解析

在 S/4HANA 里，除了在 ABAP Development Tool 里手动给 CDS view 加上 @OData.publish 注解之外，还可以采取另一种方式，纯粹在浏览器里完成操作。

使用 S/4HANA 里的 Custom CDS Views 这个应用，

可以选择 S/4HANA 里多个标准的 CDS view 来创建新的复合视图，

并能根据自己的需求，来挑选哪些标准视图的字段需要包含到新的复合视图里：

最后也是一键实现复合视图的 OData 服务发布。

到了 SAP 云平台 ABAP 环境上，基于 CDS view 创建的 Service Definition 和 Service Binding，把 OData 服务和 Fiori UI 界面的创建全部包办了。

更多关于这种基于 Restful ABAP Programming 模型的开发方式，请参考我的文章 30分钟用Restful ABAP Programming模型开发一个支持增删改查的Fiori应用。

(4) SAP Cloud for Customer 里基于 Business Object 的自定义 OData API 创建

前面在 SAP S/4HANA Fiori Launchpad 里看到的 Custom CDS View 这个应用，即使不太懂技术的 Key User，也能在浏览器里完成字段的搭配和 OData 服务的发布。

SAP Cloud for Customer 也有类似的设计，只不过供 Key User 选择的不是 CDS view，而是 C4C 里标准的 Business Object.

Key User 在浏览器的 Custom OData Service 应用里能选择将 Business Object 节点里的哪些字段发布到 OData 服务里，此操作同 SAP S/4HANA 里选择标准 CDS view 字段的思路是一样的。

在 C4C 的 Cloud Application Studio 里，还能基于标准 Business Object 创建 Web Service.

总结：基于 ABAP 技术栈的 SAP 产品，运行于其上的 OData 或者 Web Service 这些 API，本质都是通过 ABAP Netweaver 的 ICF(Internet Communication Framework)被外界消费的。我们观察其调用 Url 路径，就能找到 SICF 事务码里的对应的处理节点。

以 SAP CRM OData 服务 Url 末尾的 CRM_OPPORTUNITY 为例：

在 SICF 事务码里能找到对应的同名节点。我们只需要在 SICF 里给这个节点绑定一个 ABAP 类，该节点对应的 Url 通过浏览器或者 Postman，或者其他编程语言访问时，ABAP ICF 框架就会自动调用绑定的 ABAP 类。

也就是说，应用开发人员只需要在 ABAP 类里实现业务逻辑，至于这个类运行时的实例如何被 ICF 调用，如何初始化和销毁等生命周期管理，ABAP 开发人员完全不用操心。

关于更多 ABAP ICF 的介绍，请参考我的文章：一个13年ABAP老兵的建议：了解这些基础知识，对ABAP开发有百利而无一害。

(5) 基于 Java SpringBoot，Node Express 等 Web 应用框架的 API 开发

采用此类开发方式的生态圈是全球最庞大最活跃的群体，技术成熟稳定，相关文档和教材非常丰富。更新更先进的开发框架也在不断演化。开发人员通常在本地完成开发，再将应用部署到服务器上运行。也可以将应用打包成容器镜像，再以容器的方法运行在物理服务器或者 SAP 云平台，AWS，Google Cloud Platform，Azure 等各种云上。容器数量到达一定规模之后，可以采用 Kubernetes 进行编排管理。

Jerry 这篇文章介绍了一个例子：在SAP云平台上部署和运行Docker应用。

Jerry 之前的项目里也消费过 SAP Commerce 的 Web Service：如何使用 API 的方式消费 SAP Commerce Cloud 的订单服务。

(6) Serverless 架构

云计算行业里的一个热门词汇，Serverless 架构，并不意味着采用这个架构后就再也不需要服务器了，而是指应用开发人员不用关心开发好的应用如何部署到服务器，不需要考虑服务器的运行状态等运营和维护问题。传统 Web 应用的开发思路，如 Jerry 之前介绍的那样，通常在本地完成开发和单元测试，然后需要考虑采用何种方式，部署到何种服务器或者云上。

而基于 Serverless 架构的 API/服务开发，根本就没有 API 部署的这个步骤。以 Jerry 之前介绍过的 SAP Kyma 上的 Lambda Function 为例，API 函数本身的代码编写就是在云上完成。一旦保存，只要 API 维护的触发条件满足(事件触发或者 Url 触发)，该 API 立即被调用。

下图是我在 SAP Kyma 里使用 nodejs 编写的一个 Lambda Function：

我设置其通过 HTTPS 的方式被调用：

在浏览器里访问这个 HTTPS-endpoint，Lambda Function 立即执行。

从这个角度讲，Jerry 觉得 ABAP 开发人员，在开发 API 的时候，一直就在享受着 Serverless 架构带来的便利。因为 ABAP 领域的开发，无论是通过 SAPGUI，ABAP Development Tool，还是通过各种 Key User 工具，本质上都是连接到 ABAP Netweaver 这个集应用开发和运行为一体的服务器上进行的，因而根本没有传统 Java/nodejs 开发里的应用部署这一环节。

关于更多如何使用 Lambda Function 实现 API 的介绍，请参考 Jerry 的文章：