文章转载

随着时间的推移，商业趋势开始发生变化，市场开始随着云和移动应用程序在数字基础设施中的显著发展而发展。

现在，当公认的最佳编程实践是SAP Fiori的ABAP编程模型时，我们回过头来看，SAP在几个领域的发展历程。它将继续下去，因为未来的编程模型已经准备好了，称为ABAP RESTful编程模型。从SAP旅行者的角度来看，在SAP的接口、基础设施和集成方面，出现了许多工具，开发了一些技术，并出现了新的概念。

技术、概念和工具的演变

上面的图片没有说明这些技术的任何优先级指数，它只是在近似的年表序列中表示不同技术的到来。

1. 文件接口
基于文件交换的接口是从SAP向第三方系统提供数据的最古老的技术之一。将文本或excel文件推送到特定目录或从应用程序服务器中提取；两种方式都有效。在没有任何复杂编码和配置的情况下，使用FTP/SFTP可以将文件从SAP传输到任何第三方系统。随着PI（流程集成）的到来，从SAP提取的文件首先被发送到PI，在那里根据第三方系统提出的要求进行映射和转换，然后可以以所需的格式、JSON、XML等发送文件

       

PI作为中间件

因此，引入NetWeaver PI作为数据传输中间件的最大优势是，无论业务合作伙伴要求的数据文件的格式或类型如何，都可以实现，这对于ERP系统来说并不那么灵活。

在此上下文中经常使用的一些重要事务代码、语句、函数模块和方法包括：

AL11（事务代码）、GUI_UPLOAD、GUI_DOWNLOAD、OPEN DATASET、CLOSE DATASET、CL_GUI_FRONTEND_SERVICES=>GUI_DOWNLOAD、CL_GUI_FRONTEND_SERVICES=>FILE_OPEN_DIALOG、CL_GUI _FRONTEND-SERVICES=>GUI _UPLOAD和CL_GUI-FRONTEND_SERVERS=>DIRECTORY_EXIST

2. RFC
经典模型下的另一种方法是远程函数调用，简称RFC。RFC接口用于建立SAP和非SAP之间的通信，也用于两个SAP系统之间的通信。它基于客户端和服务器的概念运行。客户端寻找要执行的函数，并对RFC服务器进行调用。该功能在服务器端的远程系统上执行，并且可以是同步的。

根据RFC接口概念，SAP提出了BAPI（业务应用程序编程接口）。其想法是将业务对象（BO）公开给外部系统。因此，基于java的系统可以通过BO提供的独占方法访问公开的业务对象（客户，订单，雇员等）的实例。在SM59中创建了一个RFC连接，用于设置两个SAP系统之间的连接。

RFC接口

RFC接口常用的一些事务代码BAPI、SWO1、SE37、SM59和表SWOTLV。 
       
SAP有四种不同类型的RFC：         
    1 同步（sRFC）          
    2 异步（aRFC）          
    3 事务（tRFC）          
    4 排队（qRFC）

3.IDOC
中间文档是另一种古老但经过验证的技术，用于在SAP到SAP或SAP到非SAP系统之间进行通信。IDOC接口提供了一种用于在系统之间交换数据的文件格式。数据文件的格式由结构、具有位置和长度的字段组成，并进一步分为抬头、数据段和记录段的状态。

通过IDOC接口的通信基于SAP提供的名为ALE（应用程序链接启用）的框架。然而，对于公司以外的客户和供应商，使用ALE是有限制的。对于他们来说，SAP通过EDI（电子数据交换）进行通信，而对于内部第三方系统，如CRM、人力资源或财务，通信基于ALE。

随着像PI这样的中间件的引入，处理内部SAP系统与公司外部客户/供应商之间的通信变得更加容易和灵活。非SAP系统能够在SOAP协议上向中间件PI发送消息，中间件PI将格式转换为IDOC文件并发送给SAP。SAP将IDOC文件发送回PI，PI在IDOC文件中返回响应。SAP发送的消息被称为出站Idoc，而接收的消息则被称为入站Idoc。与RFC接口不同，IDOC接口通常是异步的。

有一堆事务代码用于IDOC接口的开发和监控。

重要的有：WE20、WE21、WE80、WE81、WE82、BD64、SM59、WE30、WE31、WE02、WE05、WE18、WE19、BD59、SPRO:SAP Web应用程序服务器->应用程序服务器>IDOC接口/ALE->通信。

4. SOAP（简单对象访问协议）
通过SAP 7.0版和NetWeaver，SAP引入了一种名为Web Service的新技术，用于在SAP和SAP、SAP和非SAP系统之间进行数据通信和交换。因此，可以说SOAP是一种消息传递协议，由NetWeaver 7.0版以后的版本支持，它是一种基于互联网的技术。为了调用函数，使用HTTP协议，客户端以WSDL（Web服务描述语言）的形式接收参数和函数的详细信息，可以通过定义的URL进行检索。使用SOAP的通信交换是通过XML消息进行的。处理模式通常是异步的，但这取决于需求。

基于SOAP的Web服务的一些重要注释和标准：

• 它提供了一种称为可靠消息传递（RM）的通信技术。这将确保接收器系统确实已经接收到消息。
• SOAP接口可以支持任何中间件，最好是PI
• 增量传输可以实时进行
• 有效载荷的传输可以通过bgRFC队列进行配置。因此，如果队列由于某种原因被卡住/阻塞，则在队列被解除阻塞或重新启动之前，不会通过复制进行传输。这是使用bgRFC队列的一个缺点。
• 在SOAPANAGER中，对于身份验证检查，有几个选项。通常使用的是基本身份验证，这意味着只有当应用程序使用SOAPANAGER中维护的相同凭据成功登录时，才能从URL中检索有效负载。

重要信息：ESR（企业服务库）、SOAPANAGER、SPROXY（用于代理对象）、SBGRFCMON

ESR中的代理对象

用于建模的ESR

5. REST
REST代表Representational State Transfer，这是一种用于设计网络应用程序的体系结构风格。首先，代表性的含义是什么？从本质上讲，REST是无状态的，这意味着没有为两个系统之间发生的任何通信显式创建会话。它只表示资源，但不创建自己的任何状态。与SOAP一样，它也使用HTTP协议，但通常以同步方式工作。REST是一种以资源为导向的技术，它的所有组件都充当资源。

随着SAP网关的引入，现在可以以REST API的形式提供RFC接口和ABAP功能。考虑以下场景，其中外部系统希望从ERP中提取数据。下图显示请求调用如何通过API网关的几个层并返回消息。通过REST API，即使使用分层API网关，也可以实现这种PULL功能。SAP-ERP提供API密钥，确保执行必要的身份验证，并且仅将请求的数据发送到请求数据的系统。

API网关

SOAP和REST之间的一些比较：

• 在设计和功能方面，REST比SOAP更轻。
• REST最好设置为同步，但这取决于需求
• REST可以将数据转换为JSON或XML格式
• REST比SOAP更快
• 由于REST是无状态的，因此节省了大量资源
• REST API支持CRUD（创建、读取、更新和删除）操作

结论是RESTWeb服务正在对URL进行HTTP调用，除此之外没有其他具体内容。通过这个HTTP请求和响应，两者都被创建了，它是给调用者的，如何处理它。

一些重要的事务代码：SE24、SICF和Postman（作为CRUD操作的测试工具）。

6. S4 HANA
它是SAP提供的ERP业务套件的第四个版本，基于HANA内存数据库。这是SAP在技术和概念上的一次演变。自2015年发布以来，它一直致力于使套件易于使用和管理。经过一段时间的实践证明，无论业务需求有多复杂，数据有多大，S/4 HANA都能够处理每一个问题。它可以在云中、内部部署中使用，也可以作为混合部署模型使用。

S/4 HANA遵循代码到数据的范式，该范式使用代码下推机制，这意味着复杂的数据计算发生在数据库层而不是应用层。

为了让DB层的每个人（技术或非技术人员）都能轻松地提取数据，S/4引入了信息模型的概念。基本上有：属性视图、分析视图、计算视图和决策表。它提供了很大的灵活性，可以将多个DB表连接到一个图形表示中，即使是非技术人员也可以根据需要创建模型并使用它们来显示数据。通过这样做，可以避免编写带有联接条件的复杂SQL语句。

在此期间出现了几个概念和技术：

• 核心数据服务：由于它是ABAP层SQL标准的增强，它已经从ABAP CDS视图发展到HANA CDS视图
• OIA(开放项目分析)
• AMDP(ABAP管理数据过程)
• CDS表格功能
• BOPF(业务对象处理框架)

         

绿色方框将保留，其余部分将消失

7.OData
OData代表开放数据协议。未来的编程模型是RESTful编程模型，在这种情况下，OData将发挥不可或缺的作用。因为OData促进了构建和使用RESTful API的最佳实践。因此，说到这个概念，OData是如此开放，以至于任何应用程序、程序、软件或设备都可以使用它。即使提供了非SAP系统，它们也通过HTTP连接到SAP。它可以解析和构造XML文件。

移动应用程序如果需要来自S/4 HANA系统的数据，单独的CDS视图无法提供数据。正是oData使CDS视图能够向移动应用程序公开数据。因此，介质总是oData。这就是oData将成为未来智能ERP的一部分的原因。

重要事务代码：SEGW和/IWFND/MAINT_SERVICE（用于注册服务）

OData中的CRUD操作

根据需求重新定义方法

         
8. CDS和BOPF
正如我之前提到的CDS，它是一种核心数据服务，这意味着在应用层中，CDS被定义为从DB层提取数据以呈现给应用程序。因此，该函数类似于SQL语句，但所提供的数据语义丰富，因为它包含可读的注释。它在底层数据库中创建一个运行时对象，同时也创建一个DDIC对象。CDS不是直接在DB表上应用内部联接，而是使用一种称为关联的新概念来使用抽象。CDS只能通过ADT（ABAP开发工具）创建，一旦创建，基本的必要SQL查询将在运行时自动生成，以便从DB层中选择数据。该应用程序与CDS通信，而不是与DB层通信。

拥有CDS的一个最大优势是，它是选择要求发生任何变化的唯一场所。例如，为了满足某些特定的需要，需要更改几个表之间的联接。仅使用CDS视图的应用程序不需要进行任何修改。唯一需要在关联部分进行的更改，因此可以节省大量精力。CDS比任何具有多个联接的复杂SQL语句都要快得多。

重要事务代码：RSRTS_ODP_DIS、RSRT和ADT工具（Eclipse开发）

CDS视图连接两个DB表的示例：

CDS数据定义

现在让我们讨论一下BOPF：

NetWeaver ABAP层中的BOPF

你会看到S/4 HANA下的图片视图，我在其中解释了未来将保留的组件。因此，BOPF是NetWeaver的一个附加元素。

它允许持久化应用程序的中间状态或事务应用程序的中期状态。它提供了草稿功能，这意味着创建业务对象实例的临时版本，直到它作为活动版本永久存储在持久层中。它可以管理LUW以保持数据库的一致性。它可以在运行时执行验证。使用BOPF可以创建一个事务应用程序，该应用程序能够执行CRUD操作，而无需任何额外的UI5设计。

CDS视图中作为模型类别的业务对象

激活后，将为BOPF创建一个链接

链接指向BOPF的详细信息

关于BOPF的一个重要注释是，通过RESTful编程模型，ABAP语言得到了增强，以支持事务BO行为（创建、更新和删除）的实现，这意味着不需要额外的框架。目前，在SAP Fiori的编程模型中，基于CDS的BOPF用于事务BO，但在未来的编程模型中将不再使用。

9.Web API
未来，通过RESTful编程模型（RAP），Web API的概念将与oData和Fiori并行采用。因为它是一个用于编写HTTPAPI的开源框架。与SOAP或REST一样，使用HTTP协议Web API可以引用互联网上的API。由于这只是一个概念，因此可以使用任何技术（Java、.NET等）来构建Web API。OData可以由Web API使用。

10.行为定义语言（BDL）
BDL的目的是将行为添加到业务对象（BO）中。因此，实体将如何表现，这些定义将与标头信息一起定义。使用BDL创建CDS实体，这些实体在ABAP编译器而不是ABAP字典中进行管理。BDL的语法是面向DDL（数据字典语言）的。

结论：进化之旅将继续。进步的关键是适应变化，实施和体验演变。在正确的时间做正确的事情是一把智慧的钥匙，可以让你在变革的旅程中前行。

 另外，希望大家能支持一下，将公众号的文章分享到您的朋友圈，或转发到您的微信群或QQ群，您的大力支持将是我持续维护本公众号的动力来源！