異構應用環境給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檢索數據和信息。 | |
| HTTP(S) | 通過HTTP(S)協議實現應用程序的連接。 |
| IDoc | 通過SAP Cloud Integration實現IDoc消息的交換。 |
| JDBC | 實現對SAP HANA或SAP Adaptive Server Enterprise(ASE)數據庫以及其他第三方數據庫的訪問。 |
| JMS | 通過SAP Cloud Integration中的消息隊列實現異步消息處理。 |
| LDAP | 通過輕量級目錄訪問協議(LDAP)實現與系統的連接。 |
| 使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檢索數據和信息。 | |
| 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進行集成。但是，這種方法與企業服務總線的架構方法相矛盾，並且出於監控原因也不推薦使用。這麼做的結果將是退化到點對點集成。直通集成必須滿足以下先決條件:
- 一致的域模型
- 一致的技術協議
- 一致的編排(例如，推送或拉取)