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

2024-5-20 11:54| 发布者: admin| 查看: 72| 评论: 0|原作者: 道家人

摘要: 异构应用环境给IT带来了各种标题。在这种情况下，混合集成环境尤其受到影响。同时，对于建立在混合IT环境上的数字化转型项目，数据集成和跨系统访问已经开始发挥核心作用。为了满足不停增长的需求，SAP Business Tec ...

异构应用环境给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。由于在发送方和接收方两侧消息结构相同，因此不必要进一步转换消息。