企业级应用 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的文章：

从ABAP Netweaver的SICF到SAP Kyma的Lambda Function

周伯通的空明拳，米诺斯的星尘傀儡线，SAP Kyma的Serverless

(7) SAP Data Intelligence Graph

这种方式严格来讲也算基于Serverless，使用者通过浏览器登录SAP Data Intelligence控制台，进行Graph建模。完成后启动，Graph就直接运行在SAP Cloud Platform的Kubernetes基础设施上了。

之所以把这种方式单独拿出来介绍，是因为其又具有Low Code Development(低代码开发)的特质。

看一个具体的例子。

假设我想实现一个支持CRUD的API，消费者通过HTTP GET, POST和DELETE请求，能够在数据库里分别读取，插入和删除一条记录。

低代码开发平台，通常都提供了图形化的用户界面，给使用者提供了通过拖拽组件和模型驱动开发的方式, 结合少量的编码来快速创建应用或者API.

访问SAP Data Intelligence Launchpad，进入Modeler：

我们像小朋友搭积木一样，从左边的工具箱里，拖拽HTTP Server和若干个JavaScript Handler到编辑页面里。

这些积木一样的组件搭配在一起，如何就实现了支持增删改查的API功能的呢？由于篇幅原因，Jerry后续的文章会介绍，敬请继续关注。

ABAP API ERP

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。