本篇内容主要讲解“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开发方法有哪些”有了更深的了解，不妨来实际操作一番吧！这里是编程网网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
