SAP API开发方法大全
这是Jerry 2020年的第40篇文章，也是汪子熙公众号总共第223篇原创文章。
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的文章：
(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后续的文章会介绍，敬请继续关注。
更多阅读