SAP API开发方法大全

Jerry之前的文章：**从SAP Leonardo到SAP Data Intelligence **曾经提到，SAP Leonardo Machine Learning Foundation的机器学习API已经被标注为deprecated状态，将由SAP新的AI产品，SAP Data Intelligence所替代。

在学习SAP Data Intelligence的过程中，Jerry算是了解到了一种新的API开发方式。本文首先简单回顾一下我从事SAP开发工作13年以来，接触过的各种SAP API的开发方式，然后再介绍SAP Data Intelligence里遵循Low Code Development(低代码开发)理念的API开发方式。

(1) ABAP function module + SOAMANAGER
(2) 基于事务码SEGW的SAP CRM OData服务手动实现
(3) 基于CDS view的OData服务自动生成
(4) SAP Cloud for Customer里基于Business Object的自定义OData API创建
(5) 基于Java SpringBoot，Node Express等Web应用框架的API开发
(6) Serverless 架构
(7) SAP Data Intelligence Graph

本文提到的API，指的是通过HTTP协议暴露出来，能直接通过浏览器，Postman，curl等各种工具，以及各种编程语言消费的API. 在SAP生态圈内，最常遇到的是基于SOAP的Web Service和串联SAP S/4HANA前后台的OData服务。

(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的文章：