SAP API开发方法有哪些

本篇内容主要讲解“SAP api开发方法有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“SAP API开发方法有哪些”吧!

(1) ABAP function module + SOAMANAGER

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

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

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

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

再后来，随着CDS view和Fiori Elements的成熟，我们可以基于加上了@OData.publish注解的CDS view，直接生成OData服务了

在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界面的创建全部包办了。

(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开发人员完全不用操心。

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

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

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

(6) serverless 架构

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

而基于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到编辑页面里。

到此，相信大家对“SAP API开发方法有哪些”有了更深的了解，不妨来实际操作一番吧！这里是编程网网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！