SAP集成技术（十三）SAP Cloud Integration

异构应用环境给IT带来了各种问题。在这种情况下，混合集成环境尤其受到影响。同时，对于建立在混合IT环境上的数字化转型项目，数据集成和跨系统访问已经开始发挥核心作用。为了满足不断增长的需求，SAP Business Technology Platform (SAP BTP)提供了自己的服务SAP Cloud Integration。借助这个集成平台即服务(iPaaS)，企业可以干净、统一、清晰地连接数据、应用、流程和系统。IT和业务流程可以无缝链接，不间断运行。SAP Cloud Integration能够无缝连接来自SAP和第三方供应商的云应用与其他基于云和本地的应用，帮助实现混合环境的集成。

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

本文使用了claude 3翻译，加上了一些人工调整。感觉效果比gpt4更好。

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

概述

如果分布在各个系统中的处理数据没有纳入处理上下文，则混合环境的设计是无效的。作为数字化项目或其他重组项目的一部分，新增加的云应用程序必须集成到现有的流程链中。除了业务流程和价值链的功能适应外，还必须考虑现有IT环境中系统之间的技术通信。

从架构上讲，SAP Cloud Integration对应的是企业服务总线模型。作为以消息为导向的中心平台，它确保系统A发送的消息以系统B可以接收和处理的方式进行转换和传输。

SAP Cloud Integration的核心组件是集成流(iFlow)，它定义了所涉及应用程序之间消息的协议和转换步骤。图1显示了示意图。来自应用程序A的数据可以通过各种互联网协议和适配器访问或接收。根据定义的处理逻辑对数据进行处理，并通过支持的协议和适配器提供给应用程序B。

图1 iFlow示意图

这些iFlow使用基于Web的用户界面Integration Designer建模。根据场景，可以寻址多个接收系统，并定义路由和处理逻辑，后文有详细描述。

除了可以在集成设计器中自由建模这些iFlow，从而自行确定必要的集成步骤和转换外，SAP Cloud Integration还提供了许多预定义的集成包和模板，用于SAP和非SAP应用程序之间的流程和数据集成。例如，在集成SAP S/4HANA Cloud、SAP SuccessFactors、SAP Customer Experience(前身为SAP C/4HANA)和许多其他应用程序时，可以依赖这些预定义的数据结构映射和整个iFlow。这些内容最大限度地减少了集成工作，节省了实施时间和成本。

这种方法遵循前面文章里介绍的公民集成者角色的理念。目标是将集成任务更贴近业务部门。可以通过集成设计器直接调整集成包，在那里可以根据现有内容调整iFlow以满足需求。关于完整的集成目录，包括所有可用的集成包，参见SAP API Business Hub。

除了在集成设计器中配置集成内容外，SAP Cloud Integration还提供了自己的监控环境，用于监控集成组件和消息流。各个监控区域提供有关消息状态、是否发生错误以及通信证书是否即将过期并需要续期的信息。如表6.1所示。

监控区域	描述
消息处理	显示指定时间窗口内已处理消息的数量和状态信息。
集成组件	提供当前已部署iFlow的状态和数量信息。
安全	显示与安全相关的组件(例如证书)的数量和状态信息。
访问日志	提供系统更改和系统调用的信息和日志记录。
消息锁	显示和管理消息的锁定条目，以防止消息被并行多次处理。

表1 SAP Cloud Integration中的监控区域

接口管理功能

业务流程很少仅发生在一个应用程序中。通常，数据必须从一个应用程序传输到另一个应用程序。例如，必须根据现场服务记录的客户订单触发某些后端流程以进行服务订单处理，或者必须让供应商访问云应用程序中的本地数据。你的主要目标不应该是创建新的数据孤岛来组织这些数据，而是跨系统提供现有信息。涉及的应用程序越多，整个IT环境就越异构，因为使用了不同的协议，或者数据结构因应用程序而异。

支持的集成领域

SAP Cloud Integration支持实现跨不同集成领域的集成场景。有关不同集成领域的概述，参见# SAP集成技术（七）集成解决方案咨询方法论（ISA-M）。其中，SAP Cloud Integration本地到云和云到云集成领域的优势最为明显。

本地到本地

一个仍然相当普遍的典型集成领域是两个本地运行的应用程序的经典集成。在# SAP集成技术（十二）SAP PO中，我们讨论了作为本地中间件平台的SAP PO。这个集成平台与SAP Cloud Integration的主要区别之一是SAP PO在公司自己的数据中心本地运行，而SAP Cloud Integration作为服务运行，具体取决于系统环境，在SAP数据中心或亚马逊、微软、谷歌等运营的数据中心。因此，SAP Cloud Integration位于公司自己的网络环境之外。

假设您的本地ERP系统和仓库管理系统相互交换数据，而同时拥有SAP PO和SAP Cloud Integration作为集成平台。虽然这两种场景在技术上都是可行的，但在这种情况下，出于性能原因，我们仍然主要推荐SAP PO：通过SAP Cloud Integration路由本地数据的情况意义很小。特别是在网络利用率方面，在这种情况下的传输过程中，公司网络中会产生传入和传出的数据流，因此可能会出现延迟。此外，必须在网络端确保对内部系统的访问是安全的。图2概述了使用SAP Cloud Integration的可能集成环境的概览。根据中间件策略和个别因素，此场景也可以是SAP PO的替代方案。

图2 本地到本地集成中的SAP Cloud Integration

本地到云

如果图2中提出的场景扩展到包括更多外部应用程序，则集成场景的重点可能会从之前纯粹基于本地的场景转移到本地和云应用程序的混合形式。典型的用例包括跨公司通信(例如，与外部服务提供商或个别外包的云应用程序)。目的是确保朝向云的集成，而不危及对本地环境的现有投资。特别是那些希望在现有本地解决方案的基础上，同时寻求针对特定问题的轻量级应用程序的企业会使用这个领域。

图3示意性地显示了这样一个场景。与前面的示例一样，确保公司端传入和传出的网络通信安全尤为重要。

图3 本地到云集成中的SAP Cloud Integration

云到云

作为基于云的集成平台，SAP Cloud Integration自然支持纯基于云的集成场景。在这些情况下，整个IT环境或至少大部分IT环境都在云中。除了与外部合作伙伴或应用程序的通信外，重点是在纯粹在云中运行的这些应用程序之间的集成。图4示意性地概述了这样一个集成环境。所有消息处理都在SAP Cloud Integration中进行。只有在绝对必要的点上才会与公司自己的企业环境进行通信。

图4 云到云集成中的SAP Cloud Integration

为了完整起见，我们将在此讨论两个进一步的用例模式，它们通常被归类到本地到云领域。但是，严格来说，这些用例模式不再是独立的集成领域。

企业对企业

除了公司自己业务流程的跨系统集成和数据提供外，合作伙伴和第三方的集成在混合集成环境中也发挥着重要作用。这个集成领域也称为B2B集成。

为了映射各种行业标准和消息结构(如EDIFACT、EANCOM、VDA、X12等)以及跨公司通信中的协议，包括Odette文件传输协议(OFTP)、适用性声明2(AS2)等，Integration Advisor服务被用作SAP Cloud Integration内的运行时环境。该服务的目的既是简化在您自己的公司和合作伙伴公司之间定义新消息格式所涉及的工作，也是最大限度地减少实现接口所涉及的工作。基于先前定义的接口描述，使用机器学习算法和共享知识数据库来确定用于映射各种数据结构的建议，并将创建的组件直接部署到SAP Cloud Integration。图5显示了使用Integration Advisor进行B2B接口开发的基本流程。

图5 作为SAP Integration Suite一部分的SAP Integration Advisor

基于包含不同消息结构和典型B2B行业标准及其文档的消息库，首先创建消息实现指南(message implementation guideline，MIG)。MIG定义了接口的正式框架，是针对特定业务上下文量身定制的B2B消息类型的详细文档，精确地解决了公司或合作伙伴公司的必要方面和约束。由于您自己公司的消息结构可能与合作伙伴公司的消息结构不同，因此需要为发送方和接收方定义正式的结构定义。

根据之前为发送方和接收方结构创建的MIG，生成映射指南(MAG)。在先前定义的MIG的基础上，借助中央知识数据库，映射的创建在很大程度上是全自动的。但是，可以随时对映射进行单独调整。最后，可以生成一个iFlow，该iFlow可以在SAP Cloud Integration中部署和操作。

企业对政府

企业对政府(B2G)通信是与政府机构的集成，以满足法律要求，例如报表要求。

在国际上运营的公司通常必须支持不同国家/地区关于电子发票程序的不同标准和法规。为了简化对这些要求的遵守，SAP Cloud Integration提供了现成的集成包以供实施。要了解可用的不同集成包，前文SAP API Business Hub是一个很好的起点(参见http://s-prs.co/v546729)。

集成能力

上一节介绍的集成领域中实施集成场景需要在发送方和接收方之间的集成方面具有不同的功能。根据使用领域和用例，需要不同的集成模式。在本节中，我们将更仔细地了解SAP Cloud Integration的不同集成或转换能力。

数据转换是指将传输消息的数据结构转换为目标系统可以理解和处理的格式。有各种各种运算符可用：在图形映射中，源结构的数据字段被映射到编辑器中目标结构的数据字段。为此，SAP Cloud Integration支持XML模式定义(XSD)、JSON和实体元数据XML(EDMX)消息模式，还支持用于转换和格式化XML文档的XSLT映射。可以通过脚本本身编程实现自己的转换，这也支持JavaScript和Groovy Script。此外，可以通过内容修改器运算符专门设置消息的各种参数(例如，标头)。

（Groovy 是一种基于 Java 平台的脚本语言，它的语法与 Java 非常相似，同时又集成了 Python、Ruby 等脚本语言的许多特性。它提供了比 Java 更高的开发效率，适合完成一些自动化任务或者快速搭建小型应用。）

在消息运行时，消息可以存储在SAP Cloud Integration自己的数据库中。如果在运行后再次需要消息或其内容，或者要保存消息以供以后分析之用，则可能需要这种持久性。消息持久性是指在特定时刻消息状态的持久性。

通过加密和解密(通过加密器和解密器运算符)可以提高交换消息的数据安全性。因此，消息可以以加密形式持久化在数据库中，或者在消息处理期间进行加密。SAP Cloud Integration支持诸如Pretty Good Privacy(PGP)或公钥密码学标准(PKCS)之类的加密程序。使用签名和验证器运算符，还可以对消息进行数字签名并验证现有签名。

SAP Cloud Integration可以通过消息路由确定接收者。消息可以有一个或多个接收者。可以使用多播运算符来确定消息是要并行处理还是按顺序处理——换句话说，消息是应该同时发送给所有接收者，还是按照定义的顺序发送。还可以使用路由器运算符基于消息内容定义在运行时控制消息流的规则。

如果源系统发送的数据不足以在目标系统中成功处理消息，则可以使用内容丰富器运算符访问其他应用程序的数据，并使用这些数据丰富原始消息。此过程称为消息组合。可以使用请求-回复运算符在运行时对外部系统进行同步过程调用，以处理服务的响应。

消息处理不一定必须由源系统发送消息触发。可以使用各种事件运算符以这样的方式自动化或控制消息处理：基于事件(例如，在特定时间)启动消息处理。也可以使用存储的计划定期安排消息处理。

连接器

为了与多个SAP和非SAP应用程序集成，SAP Cloud Integration提供了各种适配器类型，如表2所示。

适配器类型	描述
AMQP	使SAP Cloud Integration能够通过高级消息队列协议(AMQP)连接到消息代理。
Ariba	使SAP Cloud Integration能够连接到Ariba网络。
AS2	通过AS2协议实现B2B合作伙伴的连接。
AS4	通过AS4协议实现B2B合作伙伴的连接。
Elster	实现税务局和电子税务申报的连接。
Facebook	实现从Facebook检索数据和信息。
HTTP(S)	通过HTTP(S)协议实现应用程序的连接。
IDoc	通过SAP Cloud Integration实现IDoc消息的交换。
JDBC	实现对SAP HANA或SAP Adaptive Server Enterprise(ASE)数据库以及其他第三方数据库的访问。
JMS	通过SAP Cloud Integration中的消息队列实现异步消息处理。
LDAP	通过轻量级目录访问协议(LDAP)实现与系统的连接。
Mail	使SAP Cloud Integration能够通过连接的邮件服务器发送或接收电子邮件。
OData	使SAP Cloud Integration能够通过OData连接服务提供商。
ODC	通过OData实现SAP Gateway的连接。
Open Connectors	允许访问Open Connectors服务提供的其他适配器。
Process Direct	实现同一SAP云集成系统内iFlow的直接通信。
RFC	使SAP Cloud Integration能够对本地内部部署系统进行远程函数调用(RFC)。
SFTP	使SAP Cloud Integration能够通过安全文件传输协议(SFTP)访问应用程序。
SOAP	使SAP Cloud Integration能够通过SOAP协议提供基于Web服务的通信。
SuccessFactors	通过OData或SOAP协议实现对SAP SuccessFactors系统资源的访问。
Twitter	实现从Twitter检索数据和信息。
XI	通过XI消息协议实现与应用程序的连接。

表2 SAP Cloud Integration中的适配器类型

除了表2中提到的预定义适配器外，还可以通过适配器开发工具包(ADK)编程自己的适配器。根据应用程序、所需协议和安全标准，可以单独创建用于发送和接收系统的适配器。由于SAP Cloud Integration本身的开发和基础设施都基于Apache Camel路由引擎，因此可以使用大量已经可用的Apache Camel组件。这些组件的列表可以在apache上找到。ADK提供了一个独立的开发环境，确保新开发的组件与SAP Cloud Integration基础架构以及它们自己的iFlow中使用的开发环境兼容。因此，SAP合作伙伴解决方案包括其他适配器，例如，用于连接Microsoft Dynamics或Salesforce。

OData

除了上面提到的流程和数据集成领域的功能外，SAP Cloud Integration还提供了整合现有数据源并将数据源提供为OData服务的选项。

在经典的集成工作流中，发送方系统获得一个基于定义的具有消息处理步骤和相应接收器适配器的流程的端点，而OData供应使您能够在SAP Cloud Integration中的服务内捆绑和提供多个对象资源和实体。这种方法允许您发布一个OData服务，该服务在后台访问多个数据源，将它们整合到一个服务中，并提供给发送方系统。与经典的iFlow相比，它可以同时为发送方系统提供多个具有多个相关操作的实体。如图6所示，可以基于SOAP、REST、OData和SAP Gateway OData Channel(ODC)等协议整合现有数据源，以便在OData服务中使用。然后可以使用此端点允许现有应用程序通过OData访问数据源。

图6 SAP Cloud Integration中的OData供应

图7所示的能力图以图形方式总结了上文介绍的功能。请思考，如何通过预构建或自行开发的适配器接收来自云和本地应用程序的数据，使用自定义处理逻辑进行处理，并提供给接收者。集成监控允许监控和跟踪消息传输。

图7 SAP Cloud Integration的能力图

用例介绍

构建集成架构已经走过了漫长的道路。虽然对于少量应用程序，点对点集成似乎仍然可行，但在超过一定数量的接口时，应该考虑使用中间件(例如，以企业服务总线的形式)来降低复杂性。

使用标准iFlow

作为基于云的集成平台，SAP Cloud Integration的优势自然存在于纯基于云的集成中。在这方面尤其如此，SAP Cloud Integration中提供了大量标准集成内容，用于集成各种云应用程序。让我们以图8所示的用于将业务伙伴从SAP S/4HANA复制到SAP Sales Cloud(以前称为SAP Cloud for Customer)的预定义iFlow为例。更多集成包可以在SAP API Business Hub中找到(参见(http://s-prs.co/v546729)[http://s-prs.co/v546729])

图8 带有转换的iFlow

如图8所示，从SAP S/4HANA到SAP Sales Cloud初始传输业务伙伴的所有相关转换对象都是可用的。发送方和接收方适配器以及不同数据结构之间的映射已经在标准中交付。但是，由于通常必须对映射进行自定义的调整，因此可以通过内置的用户出口将这些调整与标准映射分开。因此，交付的iFlow保持其形式，如果涉及的应用程序对映射进行结构更改或调整，则可以更新iFlow。因此，客户特定的映射调整可以外包，并在标准映射之后单独运行。后处理步骤调用另一个iFlow，进行适当的客户特定调整。这种无修改的适应过程如图9所示。在这种方法中，SAP提供集成标准，企业可以在单独的iFlow中进行个性化调整。

在此示例中，消息A从发送方传输到SAP Cloud Integration。交付的标准映射的结果是消息结构B。不是直接将此消息传输到接收系统，而是要进行进一步的调整:典型的用例是映射附加字段或执行偏离标准映射的映射步骤。通过存储在iFlow中的用户出口，将消息B发送到下游单独的iFlow，生成消息C。此消息现在基于标准SAP交付的转换逻辑和个人转换逻辑。通过这种方式，您可以确保对标准映射的更改(例如，由于更新)不会影响为个别客户所做的定制。

图9 标准集成内容的扩展

创建个人集成场景

如果在手头的集成场景中无法识别标准内容，并且在这种情况下集成应用程序，您还可以基于第上文介绍的工具和连接器构建个人的iFlow。

与流程流类似的iFlow提供了许多实现集成过程的选项，我们希望通过一个示例来说明这一点。图10显示了一个包含各种流程步骤和处理逻辑的iFlow。在这个场景中，系统A发送的销售订单在发送到目标结构的系统B之前，根据订单量通过不同的映射。如果订单量小于10000欧元，销售订单将直接发送到系统B。如果订单量为10000欧元或更多，则必须将负责销售代表的姓名添加到目标消息中。这个名字也是从系统A中检索的。

图10 个人iFlow

在这个场景中，如图10所示，系统A在步骤1中将清单1所示的消息发送到SAP Cloud Integration。订单量为11000欧元，超过了10000欧元的限制，订单可以直接转发到系统B。

如图10所示，在步骤2中，使用Call Process调用执行实际消息处理的本地子流程。我们建议这个过程不仅可以提高iFlow的可读性，而且可以为复杂的需求重用单个流程步骤。顺便说一下，可以在SAP帮助门户的集成流设计指南部分找到有关设计和建模建议的更多信息，网址为http://s-prs.co/v546730

在消息传递给子流程后，Router工件在步骤3中决定选择两条路径中的哪一条。根据使用xPath查询语言读取订单量的存储规则，消息将传递到适当的路径。规则是:

/order/orderVolume '>= 10000'

（XML Path Language，XPath是一种用于在XML文档中选取节点的查询语言）

由于订单量超过10，000的阈值，因此满足规则，在步骤4中采用该路径。根据业务要求，必须将相应销售代表的姓名添加到销售订单中。由于系统的原因，此名称不包含在出站消息中，但可以通过相应的OData接口从系统A中检索。Content Enricher工件可用于丰富或将查询结果添加到出站消息中。

根据存储的聚合方法，查询结果将与原始消息合并。现在，消息包含原始消息以及负责销售代表的名称。在步骤5中，该消息传递给接收系统B的适配器。同时，通过使用对应的Receiver Agreement工件，可以将多个消息传递到一个或多个目标系统。如果未满足Router工件中的条件，则消息将直接传递到相应的接收器适配器(步骤6)。

在步骤7中，系统B现在收到扩充的消息(如果订单量超过了10，000欧元的阈值)或原始消息。

根据存储的聚合方法，负责订单的销售代表的查询结果被附加到原始消息中。

现在所有相关信息都可用了，在步骤5中使用Message Mapping，可以根据系统B所需的结构映射消息。此过程完成后，子流程结束，消息将传递到更高级别的流程。

在最后的处理步骤6中，使用Content Modifier为头设置与接收者相关的消息参数。在我们的示例中，除了进一步指定发送的消息类型的内容类型外，还将用于验证发送者(在本例中为SAP Cloud Integration)的身份验证密钥传输给系统B。

设置以下头参数:

Content-Type = application/xml

API-KEY = 46d8d52f4...

现在，系统A发送的消息包含所有相关信息，并与系统B预期的结构相匹配，它通过步骤7中的SOAP适配器转发到系统B提供的端点。

对齐的应用程序编程接口

经典集成场景涉及两个具有不同消息结构的应用程序之间的集成。但是，在对iFlow进行建模时，趋势已转向所谓的两个应用程序之间的对齐应用程序编程接口(对齐API)，如图11所示。

图11 iFlow的变化

对齐API的目的是通过让所有相关应用程序"使用相同的语言"来最小化新应用程序的集成工作。这种方法消除了对消息转换的需求，为SAP One Domain Model铺平了道路。，在SAP API Business Hub可以找到有关所有API的具体信息以及用于集成各种应用程序的预定义集成包。

这些对齐API的结果是iFlow，它们只建立系统之间的连接，而无需更改消息，也称为直通集成场景。图12显示了一个这样的iFlow。由于在发送方和接收方两侧消息结构相同，因此不需要进一步转换消息。

图12 没有转换的iFlow

可以想象，您可以直接将两个系统相互连接，完全放弃通过SAP Cloud Integration进行集成。但是，这种方法与企业服务总线的架构方法相矛盾，并且出于监控原因也不推荐使用。这么做的结果将是退化到点对点集成。直通集成必须满足以下先决条件:

一致的域模型
一致的技术协议
一致的编排(例如，推送或拉取)