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進行整合。但是，這種方法與企業服務匯流排的架構方法相矛盾，並且出於監控原因也不推薦使用。這麼做的結果將是退化到點對點整合。直通整合必須滿足以下先決條件:

• 一致的域模型
• 一致的技術協議
• 一致的編排(例如，推送或拉取)