天天头条

SAP集成技术（六）技术、标准和协议

2023-11-22 17:17 由 氢氦 发表于 #企业信息化

本文链接：https://www.cnblogs.com/hhelibeb/p/17849837.html

内容摘录自《SAP Interface Management Guide》。

Web Service

Web Service是互联网或企业网络中的平台-无关的服务，通过该服务，应用程序可以使用标准的网络技术与先前定义的接口交换信息。术语的定义如此，但是，具体的含义是什么呢？

Web Service基本上基于将服务对外发布（到网络）的想法。在上一篇文章中，我们在这个背景下讨论过SOA。


图1 服务的结构

如图1 所示，服务基本上包括以下组件：

  • 接口：接口代表了服务向外部世界的中心访问点。
  • 服务契约（Service Contract）：服务契约是服务提供的功能和限制的规范。
  • 服务实现：服务实现是实际的技术实现，它根据服务的定义的业务逻辑提供数据。

如图2所示，Web Service是使用网络技术公开的内部服务。外部合作伙伴可以以一种受控和定义的方式访问内部资源。当然，这个定义是一个高度简化的视图，但可以帮助你理解Web Service背后的基本概念。


图2 Web Service作为外部合作伙伴的中央访问点

Web Service的功能基本上遵循经典的客户端/服务器调用序列，由服务请求者（客户端）和服务器（服务提供者）组成，如图3 所示。在这种情况下，客户端通过 HTTP POST 向服务器的网络服务发送消息。消息和随之发送的数据由Web Service根据实际服务支持的数据格式进行准备。应用程序根据服务实现中存储的业务逻辑处理数据，并将结果返回给接口。Web Service封装数据，并相应地将其作为 HTTP 响应发送回发送者。


图3 Web Service架构

在此过程中，通信基于两个核心组件：XML和HTTP。

在其底层架构中，Web Service通过另一个组件：服务注册表，扩展了这种经典的客户端/服务器架构。服务注册表包含所有可用网络服务的目录以及它们的服务描述。
因此，服务注册表作为通用描述，发现和集成（UDDI）服务——也就是说，作为网络服务的基于网络的信息目录。通常，应用程序向 UDDI 提交一个特定服务的搜索查询，并收到适当网络服务的服务描述，然后实际的调用会被指向这个服务。当今，UDDI 的应用越来越少，因为它缺乏对服务管理的规定，尤其是对单个服务请求者和服务提供者的记录。

在集成环境中，SOAP 协议迅速成为基于 XML 的数据交换的标准消息协议。HTTP 被用作传输协议。SOAP 通过将服务调用转换为 XML 消息进行传输（在服务请求者一侧）并从 XML 转换为相应的服务调用（在服务提供者一侧）来实现分布式系统之间的通信。换句话说，SOAP 使用 XML 实现远程过程调用。通过 HTTP 协议在客户端和服务器之间传输数据通常是无状态的。因此，所有消息都是独立传输和处理的，不参考上游数据传输。

SOAP 的优势在于，大多数集成系统可以导出 Web Service Description Language（WSDL）文件，扩展名为 .wsdl，这是定义基于 XML 的网络服务的标准。WSDL 描述了服务的功能，如何调用它，以及其访问点或URL。

RESTful

严格来说，Representational State Transfer（REST）一词，并不是指用于消息交换的 HTTP 之类的协议，而是一种通过某些原则定义网络服务的架构风格的范式。
与 SOAP 类似，例如，基于 REST 的通信的关键是机器或应用程序之间的消息交换。HTTP 和 SOAP 协议的区别主要在于网络服务及其使用的资源的寻址方式。REST 也可以被称为资源导向的架构。

如果满足以下六个架构原则，一个架构就被认为是符合 REST 的：

  • 客户端-服务器架构：必须坚持客户端-服务器架构，以便分离责任（例如，将前端与数据库解耦）。
  • 无状态：客户端和服务器之间的数据传输通常是无状态的。因此，所有消息都是独立传输和处理的，不参考上游数据传输。
  • 统一接口：所有资源必须通过一组标准化的方法进行访问。服务 URI 的结构也必须遵循统一的模式，并唯一地识别每个要使用的资源。
  • 缓存：缓存旨在通过在客户端的缓冲区中保留某些数据，减少不必要的服务器请求。基于服务器响应头部的某些信息，客户端可以决定数据可以和可能被缓存多长时间，而无需再次查询服务器。
  • 多层：向外部提供一个定义的接口，但是无法访问其背后的处理。这个特性用于抽象调用。因此，该服务可以被多个客户端以不同的格式调用（例如，通过 XML 的业务应用和通过 JSON 的移动设备）。然而，后台的处理是相同的。
  • 按需代码（可选）：按需代码（Code-on-demand，COD）描述了从服务器卸载代码到客户端的能力。这个功能主要在网络环境中使用，而在经典的应用集成中使用较少。因此，这个原则也应被视为可选。

总的来说，REST 不是像 HTTP 或 SOAP 那样的协议，而是一种可以使用各种机制实现的编程范式。与 SOAP 不同，REST 不仅依赖于 HTTP POST 方法，而且依赖于对单个资源的许多 HTTP 访问方法。例如，一个 SOAP 服务器应用程序可以提供几个函数来访问用户数据：getCustomer()，addCustomer()，和 deleteCustomer()。按照 REST 方法，只会定义资源https://host.com/customers，然后通过 HTTP 方法相应地映射各个操作。

OData

OData 协议基于 HTTP 协议，并允许通过定义的访问路径调用服务器提供的功能。在这方面，OData 服务最初与上文提到的 SOAP 服务有相似之处，但在实现 REST 编程范式和支持基于 XML 和 JSON 的消息上有所不同。由于其基于 HTTP 协议的结构以及通过 REST 范式对相关服务器资源的针对性（读取和写入）访问，OData 非常适合轻量级的客户端应用程序，如移动应用程序或 web UI。

通过考虑 REST 范式，OData 服务从根本上区别于第 2.3.1 节中介绍的 web 服务。因此，OData 查询的核心是基于 HTTP 的、符合 REST 的对单个可识别的服务器资源的创建、读取、更新和删除（CRUD）操作。

服务提供者确定哪些资源可用，可以执行哪些操作，以及以哪种格式（XML 或 JSON）进行查询。OData 服务的结构和设置在服务文档和 OData 服务的服务元数据模型中定义，这些都提供给客户端应用程序。

服务文档代表了 OData 服务实际上公开发布的端点，客户端用于数据交换。客户端应用程序可以使用此端点访问分配给服务的资源、路径和操作。服务文档的 URI 遵循 https://host:port/odataservice/ 的模式。

服务元数据文档包含了 OData 服务的元模型，包括 OData 服务结构的抽象描述。这个结构包括包含的实体类型、属性和两个实体类型之间的关系。客户端应用程序可以检索并使用元模型，以了解如何查询和与 OData 服务中包含的实体交互。服务元数据文档的 URI 遵循 https://host:port/odataservice/$metadata 的模式。

元模型或实体数据模型，基于此 OData 服务基本上遵循相同的结构。OData 元模型的简化模式表示如图4 所示。


图4 OData 元模型

实体数据模型描述了服务中包含的实体和关联。实体代表可以检索的具体条目，是实体类型的具体体现。实体集（或集合）围绕服务中包含的实体类型形成一个封装，并将它们打包成逻辑相关的包。实体类型的特性由其属性描述。实体键用于唯一引用单个实体。关联（也称为对象关系）允许你使用导航属性创建实体之间的连接并检索关联的信息。

客户端可以使用各种标准 OData 操作在查询服务器时过滤数据。常见的查询操作如下，

操作 参数 描述
选择 $select 属性集的限制
排序 $orderby 基于属性的升序或降序排序
格式化 $format 定义 OData 响应格式（XML 或 JSON）
过滤 $filter 基于属性内容的限制
表1 最常见的 OData 查询操作列表

针对性地查询数据外，元模型也提供了另一些优点。一方面，元模型允许对实体和关系进行平台和技术独立的描述，因为客户端不关心哪个数据库或哪个应用程序在 OData 服务后面。通过 OData 的通信和使用 OData API 遵循相同的基本原则。另一方面，元模型还允许对服务提供的哪些功能和结果进行标准化的文档记录。

实践表明，OData 服务在新的 SAP 产品，如 SAP S/4HANA Cloud 中起着重要的作用。然而，有些情况下，可能没有可用的 OData API，或者同一个对象有几个可用的 API。哪个服务最适合一个用例并不总是明显的，而且经常是模糊的。在实践中，我们发现通过 OData 读取数据比通过 SOAP 更有效。反之，通过 SOAP，尤其是大量（批量）消息的写入，工作更简单，更快。最后，防止集成环境的碎片化也很重要，需要遵循一个明确的集成策略。

RFC/IDoc

在 SAP 环境中，远程函数调用（Remote Function Calls，RFCs）仍然在使用。尽管 SAP 近年来将其他集成技术，如 Web Service或 OData 服务，纳入其产品组合，但在 SAP 环境中，大部分集成仍然使用 RFCs 完成。

RFCs 是 SAP 对远程服务或过程调用（也称为远程过程调用（Remote Procedure Calls，RPCs））的实现。通过 RPC，客户端可以从服务器程序调用服务或过程。服务器程序也可以安装在另一台计算机上。

图5 显示了 RPC 调用的示意表示。在客户端中调用一个占位函数。占位函数的任务是将传输的数据从客户端的格式转换为数据交换的定义格式。你可以在占位函数中实现其他服务（例如，序列化服务）。这个占位符确保所有消息按正确的顺序处理。在占位函数的最后一步，消息被传递给客户端的通信组件。客户端和服务器之间的传输通过两个通信组件进行。在服务器中，接收到消息后，通过调度程序选择正确的服务，并将消息传递给其占位函数。在占位函数中，进行反序列化（如果实现的话）和之后的消息转换到服务器的格式。然后，消息传输到实际的服务器程序。


图5 RFC调用示意图

RFC有RFC 客户端和 RFC 服务器。客户端和服务器可以是不同的系统，也可以是同一个系统。

不同类型的 RFC 调用：

  • 同步 RFCs（sRFCs）
  • 事务 RFCs（tRFCs）
  • 队列 RFCs（qRFCs）
  • 后台 RFCs（bgRFCs）

具体参考：SAP RFC介绍：关于sRFC，aRFC，tRFC，qRFC和bgRFC

可以在两个 SAP 系统之间，或者在 SAP 系统与非 SAP 系统之间实现 RFC，但它们在两个 SAP 系统之间工作得最好。在 RFC 服务器中，可以通过为相应的函数模块设置远程启用选项，使 RFC 函数模块可用。在 RFC 客户端中，可以使用 CALL FUNCTION ... DESTINATION 语句从任何 ABAP 程序实现调用。使用前，必须首先通过事务 SM59 将目标创建为 RFC 连接。

对于在 SAP 系统和非 SAP 系统之间使用 RFC，SAP 提供了一个名为 SAP 连接器的工具集。一些常见的连接器：

  • SAP Java 连接器
  • SAP Connector for Microsoft .NET
  • SAP NetWeaver RFC SDK
  • Classic RFC SDK
  • PyRFC

使用这些工具，可以使用非 SAP 系统作为 RFC 客户端或 RFC 服务器，实现双向通信。

通过 RFC 进行通信的一种特殊形式被称为intermediate documents (IDocs) 。IDoc 是由 SAP 开发的一种文档格式，通过 RFC 调用在技术上进行传输。一个 IDoc 由三个区域组成：

• 控制结构：此结构包含有关 IDoc 类型和涉及的通信系统的技术信息。
• 数据集：数据集包含传输中的实际数据。根据 IDoc 类型，数据集的结构可能不同。
• 状态结构：状态结构包含有关处理 IDoc 的状态信息。

许多公司今天仍然使用 IDocs 在其系统之间进行通信，因为它支持很多现成的功能以及监控功能等。

SAP在近年来越来越依赖于使用Web服务或OData服务。然而，对RFC技术的基本理解对于集成开发人员和架构师是有用的，特别是在集成旧的SAP应用程序时，这种理解是必需的。

消息队列

消息队列遵循通过持久消息层交换消息的原则，异步交换消息。与从中间件或消息平台直接传送消息给接收者（例如，向ERP系统的SOAP端点发送消息）不同，消息队列允许通过队列发送消息。消息不是直接发送到接收器端点，而是放置在接收系统的输入队列中。消息可以在任何以后的时间从队列中取出。从消息发送者的角度看，这种情况也被称为“发射并忘记”：发送者“发射”消息后可以“忘记”它，因为发送者不等待接收系统的响应。图6展示了这个原则。


图6 消息队列的示意结构

消息会留在队列中，直到它们被取出或在定义的时间段后被删除为过时。通常，消息获取遵循先入先出（FIFO）的原则。然而，通过优先级对消息进行排序，可以首先取出优先级较高的消息，这样就可以跳过这个原则。消息队列允许以安全、计划和优先的方式发送消息，即使在发送时接收者无法被访问，也可以发送消息。接收者可以自己决定何时准备处理消息。这种能力使消息传送比如RFC更健壮、更不易出错，因为接收者不必在消息发送时直接响应。只要接收者再次可用并准备好从队列中取出消息，消息就会传送。然而，反过来说，消息队列及其基础设施必须稳定和安全，以防止消息丢失。

消息队列有各种标准。Java消息服务（JMS）是其中之一，它是一个API，而不是一个专用的协议，通过它，基于Java的应用程序可以交换消息，前提是使用的中间件也支持作为企业Java Beans（EJB）的一部分的JMS。寻址是通过队列或队列名称进行的：发送者/接收者确定应将哪个消息存储到哪个队列，或者应从哪个队列获取哪个消息。一个JMS消息由三个组件组成：首先是头参数；一般的消息信息，如消息ID、消息优先级、过期日期；其次是应用程序设置的包含附加信息的其他参数；最后是包含实际消息的消息体。

JMS存在对Java平台及其相关的编程语言依赖性的限制，因此需要一个标准化的、与编程语言无关的协议。集成环境相关的事高级消息队列协议（AMQP），而消息队列遥测传输（MQTT）协议主要用于物联网环境中的机器之间的通信。

消息队列可以在不需要直接响应的地方使用。两个应用程序的解耦使得可以保证消息的发送和接收，以及减轻接收应用程序中特别频繁的函数模块的负担。发送消息通常不是一个阻塞操作，因为发送者在发送后可以直接进行其他进程，但接收消息的情况通常是不同的：接收者等待新的入站消息，并启动对应的内部后续进程进行消息处理。在这种情况下，消息队列可以解耦进程或消息交换，并作为一种缓冲器，不会给接收系统带来负担。在SAP世界中，消息队列的实现可以在SAP Event Mesh中找到，你可以使用它来构建事件导向架构。

特别是在现代云架构中，由于它们越来越多地由较小的独立构建块或微服务组成，消息队列可以方便这些服务之间的通信和协调。与在经典的On-premise世界中，通常是单体应用程序进行通信不同，在云中，通常是独立封装的函数模块仅完成一个功能。图7显示了这种关系。


图7 消息队列和微服务

文件传输和数据库

在接口管理领域，通过文件传输和数据库通信是一个相当两极分化的话题。有人认为集成不应再通过这两种技术进行。完全不使用这些技术也有很大困难，因为并不是每个应用程序都支持人们认为的更有用的技术。

文件传输

原则上，在文件传输过程中可以处理任何类型的文件；然而，这要取决于集成平台的能力。要在集成平台内处理文件，并且例如进行结构映射，必须将文件转换为可以被集成平台读取的格式。

这种转换称为内容转换。SAP Cloud Integration和SAP Process Orchestration都提供了执行内容转换的标准选项。在SAP Process Orchestration中，选项限制为XML；在SAP Cloud Integration中，也可以使用JSON。有了这些功能，你可以选择仅通过配置来定义转换。

从技术角度来看，执行文件传输有不同的选项。在最简单的情况下，文件传输通过本地目录进行。在这种情况下，你必须在操作系统级别共享相应的文件夹。其优点是在集成平台中配置这样的文件传输非常简单，并且通常可以使用现有的基础设施。然而，集成平台的应用程序开发者并不总是能访问这些目录，这使得测试集成变得更困难。

另一种可能性是通过文件传输协议（FTP）或安全文件传输协议（SFTP）传输文件。在这种情况下，需要一个单独的服务器，通过该服务器进行文件交换。这种方法的一个优点是可以通过带有FTP客户端的本地计算机轻松建立连接，这使得测试连接更容易。出于安全原因，应该默认优先选择SFTP而不是FTP。

另一个重要的概念是轮询原则。轮询用于设置系统应该多久搜索一次目录中的新文件。频率通常取决于接口场景，可能是几秒钟或几个小时。时间戳用于追踪文件在目录中创建的时间。在很多情况下，这个功能都方便了错误分析。

原则上，集成平台可以根据目录和文件名定位要处理的文件。可以使用通配符动态搜索文件名。建议尽可能详细地描述要在你的集成平台中处理的文件的文件名，而不是使用通用的通配符。通过这种方式，可以降低处理错误文件的概率。

文件传输领域的一个特性是文件到文件传输的实现。在这种情况下，也称为管理文件传输，集成平台仅将文件从一个目录复制到另一个目录。在此过程中，不会进行任何转换或内容转换。

文件传输的一种特殊形式是通过Applicability Statement 2（AS2）或Odette文件传输协议（OFTP）进行传输。这种形式的文件传输主要用于B2B通信环境。这两种形式的一个特点是它们提供电子收据确认。在AS2中，这个功能被称为消息处置通知（MND），在OFTP中，这个功能被称为端到端响应（EERP）。此外，这两种传输形式都提供了消息加密。AS2和OFTP与其他两种技术的区别在于，消息是主动发送的，而本地目录和（S）FTP都需要“获取”文件。

数据库

连接数据库是一个简单但功能强大的选项。在数据库中，你可以定义自己的结构来交换消息。SAP Cloud Integration 和 SAP Process Orchestration 都可以通过 Java Database Connectivity (JDBC)，这是一个用于连接数据库的 Java 开发的库，来访问数据库。根据使用的数据库，你可以通过数据库提供商在集成平台上找到合适的 JDBC 驱动程序。

通信通过单个表进行。原则上，也可以在集成中使用多个表，但在这种情况下，必须考虑表之间的依赖关系，这会为集成引入更多的复杂性。

实践提示： 永远不应该通过应用程序使用的表进行连接，因为有可能会意外销毁后端的数据，例如，通过未完全测试的接口。因此，我们建议使用传输表，这些表是实际数据源的副本或必要时的部分，仅用于通信。

在集成数据库表的过程中，使用 Structured Query Language (SQL) 命令读取、写入或更新数据。根据集成平台，有不同的生成 SQL 命令的选项。

经常用的一种格式是 XML-SQL 格式。通过这种格式，可以在 XML 结构中定义 SQL 命令。列表2.3 显示了如何在 Users 表中定义一个 INSERT 命令的例子。
参考：Defining XML Documents for Message Protocol XML SQL Format

此外，在通过数据库通信时，轮询是从传输表中读取信息的常见方法。我们通常与表中的状态列结合使用此功能。你以使用状态来控制表中相应条目的状态，并确定它是否仍然可以被接口处理。也可以使用状态来设置错误处理。例如，可以通过重置状态来再次处理含有错误的消息。

热门相关：绍宋   试婚100天：夜少，轻轻宠   覆汉   至尊剑皇   青莲剑说