目錄
正文
本教程的目的是讓讀者理解：SAP Process Integration（以下簡稱SAP PI）是什麼。我們不需要探究課題的本質，但是會討論SAP PI的架構和不同特點。本文只會覆蓋到PI的基本特點，而不是討論全部。
本文連結： http://www.cnblogs.com/hhelibeb/p/7105070.html
SAP ERP是什麼
對於任何業務——無論是大的還是小的——都會有必須要執行的標準業務功能，比如：物料管理（MM），銷售與分銷（SD），財務（FI），人力資源（HR）等等。市場上有很多正在為業界所使用的軟體。一個簡單的例子：如果你前往一個大型零售商店、旅店的下屬的小店面，並且它們執行在ERP系統之上的話，收銀機器可以經由ERP生成銷售發票。
對於絕大多數業務實現來說，企業資源計劃（Enterprise Resource Planning，ERP）是一種可以改善生產力和業績的有效途徑。SAP ERP是SAP 公司推出的的企業資源計劃，它是一個整合了組織的關鍵業務功能的整合軟體解決方案。基本功能包括：HR，MM，SD，FICO等，在SAP中它們叫做業務模組。SAP把它們構建成產品並且在市場上銷售。有兩個（或者更多）模組是不直接支援業務功能的，而是用於展現和整合。前者叫做EP（企業門戶）後者叫做PI（過程整合）。所有的業務模組都是由ABAP開發的，然而這兩個模組卻主要由Java開發。這些模組不是可執行檔案，而是需要部署在應用伺服器上執行。
在我們進入主題之前，需要認識到這些點：
- SAP代表用於資料處理的一些系統、應用、產品。
- SAP AG是一個德國的跨國軟體公司，從事於製造管理業務操作和客戶關係的企業軟體。SAP ERP是該公司推出的企業資源計劃，一個整合了組織的關鍵業務功能的整合軟體解決方案。
- SAP NetWeaver Process Intergration（SAP PI）是SAP的企業應用整合（EAI）軟體，是NetWeaver產品組的元件，用於幫助公司內部的軟體、系統之間的資訊交換，以及與外部的資訊交換。
遺留系統
當在一個大型的機構中實施SAP的時候，並不是所有部件都可以放在SAP ERP中。其中的很多業務部件有它們自己的專有工具，可能極度複雜、並且無法被替代。它們和SAP系統平行執行。它們叫做“遺留系統”。有必要把這些先前存在的非SAP系統和SAP整合起來，這就是SAP PI出場的地方。
為什麼我們需要SAP PI
在大型的機構中，除了遺留系統之外，SAP ERP也不是由一個單一系統組成的，而是整合了多個系統，如CRM，SRM和FICO等。為了處理這種複雜性，SAP引入了PI：一個可以為所有系統提供單一整合點的平臺。它不需要接觸已有的遺留系統的複雜網路。這是一個可以為SAP和非SAP應用之間、企業內部和內部或者內部和外部之間提供平滑的端對端整合的強大的中介軟體。SAP PI支援B2B和A2A交換，支援同步和非同步訊息交換，並且包含了用於設計和執行PI的內建引擎。
SAP PI架構
SAP PI有著輪輻式結構，由中心和輻條組成；輻條連線外部系統，中心會在它們之間交換訊息。源系統成為傳送者系統，目標系統成為接收者系統。PI不是一個單獨的元件，而是很多個可以根據整合場景靈活地一起工作的元件的集合。該架構包含了在設計期間使用的元件、在配置期間使用的元件和在執行期間使用的元件。
我們可以把PI劃分為多個領域：
- 整合伺服器（Integration Server）
- 整合構建器（Integration Builder）
- 系統規劃（System Landscape）
- 配置和監控（Configuration and Monitoring）
整合伺服器是SAP PI的中心處理引擎。所有訊息都在這裡以一致的方式處理。它包含三個獨立引擎：
- 整合引擎（Integration Engine）
- 介面卡引擎（Adapter Engine）
- 業務處理引擎（Business Process Engine）
整合引擎可以被看做是中心，而介面卡引擎則是輪輻。
關於業務處理引擎，本文會晚些解釋。
整合構建器是一個用於訪問和編輯整合物件的C/S框架，它包含兩個相關的工具：
- 企業服務庫（Enterprise Service Repository ，ESR）——用於設計和開發在不同場景下使用的物件。
- 整合目錄（Integration Directory，ID）——用於配置開發場景的ESR元件。
二者放在一起，就是通常被成為場景的整合過程。
系統規劃是資料中心的一個有關軟體和系統的資訊的中心庫，簡化了系統規劃的管理。
在配置和監控中，可以監控訊息和介面卡。
單棧與雙棧
在PI初次釋出的時候，不是所有的元件都是在同一個平臺上構建的。整合引擎和業務處理引擎由ABAP構建，然而介面卡引擎、整合構建器、SL、CM和Mapping Runtime由Java構建。因此PI需要Java和ABAP環境來執行，這被稱為雙棧。
| ABAP Stack | Java Stack |
|
|
但是在晚些的版本中，所有元件都是由Java構建的。某些雙棧元件已經廢除，或者在被修改後執行在Java棧。因此PI只需要Java環境來執行。這就是單棧。
（單雙棧各有利弊，但是本文不會涉及到相關內容）
整合引擎
整合引擎負責中央整合伺服器服務，例如管線步驟：路由和對映。如果源訊息結構和目標的訊息結構不同，整合引擎呼叫Mapping Runtime，源結構會被轉換成目標結構。Mapping Runtime基於Java棧。整合引擎也可以利用ABAP程式來轉換，這個基於ABAP棧。
訊息可以是兩種型別：
- 同步的——有請求和響應兩部分。
- 非同步的——只有請求或者響應二者之一。
在PI中，訊息由介面表示。
介面：XML格式的訊息結構和說明。
基於上面的限制，會有三種介面型別：
- 外向介面——連線傳送系統。
- 內向介面——連線接收系統
- 抽象介面——連線BPE。
在PI中為每一個業務需求配置整合邏輯（場景）的時候，整合引擎會以循序漸進的方式執行配置。術語“管線”指的是在處理XML訊息的時候執行的所有步驟。管線步驟包含：
- 接收者識別——決定參加訊息交換的系統。
- 介面識別——判斷應該使用何種介面接受訊息。
- 訊息分割——如果找到了不止一個接收者，PI會為每一個接收者例項化新的訊息。
- 訊息對映——把源訊息對映為目標訊息的格式。
- 技術路由——為訊息繫結特定的目標和協議。
- 呼叫介面卡——傳送轉換過的訊息給介面卡或者代理。
介面卡引擎
你一定已經發現，整合引擎只使用XML-SOAP協議處理訊息。但是如果我們有一對傳送和接收系統，它們的資料格式是不同的呢？這時我們使用介面卡引擎中的不同的介面卡來將XML和基於HTTP的訊息轉換為這些系統需要的指定的協議和格式，或者相反。
如本文早先討論的那樣，SAP PI是輪輻式結構的，其中介面卡引擎可以被看作輪輻。我們使用介面卡引擎來連線整合引擎（中心）和外部系統。介面卡框架基於介面卡引擎，介面卡框架是基於SAP J2EE Connector Archtiecture（JCA）的。介面卡框架提供了用於配置、管理和監控介面卡的介面。
在雙棧系統中，大多數介面卡基於Java棧，只有兩個基於ABAP棧：
|
Java Stack |
RFC adapter, SAP Business Connector adapter, file/FTP adapter, JDBC adapter, JMS adapter, SOAP adapter, Marketplace Adapter, Mail adapter, RNIF adapter, CIDX adapter |
|
ABAP stack |
IDOC adapter and HTTP adapter |
在SAP PI從雙棧變為單棧的時候，這兩個介面卡成為了Java棧的一部分。修改後的介面卡引擎成為高階介面卡引擎，兩個介面卡分別叫做IDOC_AAE和HTTP_AAE。
業務處理引擎
業務處理引擎（ Business Process Engine ）的職責是執行和持久化整合過程。
BPM代表跨元件業務處理管理（ Business Process Management ）或者ccBPM，也叫做整合過程。整合過程是指可執行的、跨系統的訊息處理。在整合過程中，你可以定義所有需要執行的的處理步驟和相關的過程控制引數。業務處理管理提供了SAP Exchange Infrastructure，包含以下功能：
- 全狀態訊息處理：整合過程的狀態可以在整合伺服器上持久化。
- 可以使用相關性建立訊息間的語義關係。
- 當你想要定義、控制、監控複雜的整合過程的時候，比如擴充套件到企業和應用程式邊界，即收集/合併、拆分、多播的時候，需要實現整合過程。
在執行期間，BPE執行整合過程。整合過程可以只透過抽象介面傳送和接收訊息。
在SAP PI中建立場景
如果需要在PI中建立場景（scenario），要從主頁開始。
主頁介面如下：
主頁有以下四個工作區的超連結：
- 企業服務庫（ESR）
- 整合目錄（ID）
- 系統規劃（SL）
- 配置和監控（CM）
每個超連結都可以開啟對應的應用。這四個都是Java應用。ESR和ID是swing應用。它們基於JNLP，需要從瀏覽器啟動，所以第一次會花較多的時間來下載整個庫檔案。但是從第二次開始，載入時間就會變短了。SL和CM是純web應用，執行在瀏覽器上。
企業服務庫
使用企業服務庫設計和建立用於製作場景的物件。PI中的資料流是這樣的：
找到以下設計的選項：
- 介面物件——服務介面，訊息型別，資料型別。
- 對映物件——操作對映和訊息對映。
- 整合過程。
PI使用整合庫來為傳送者和接收者設計訊息結構，並且透過相應的訊息結構開發介面訊息，介面訊息是與外部世界互動的一個點。資料型別和訊息型別可以用來對複雜介面進行簡化和模組化設計。
操作對映允許源結構和目標結構之間的轉換。但是如果源結構和目標結構是相同的，那該過程可能會免於執行。和服務介面類似，訊息對映用於簡化和木塊話複雜的操作對映。訊息對映可以透過四種方式進行：
- 圖形化對映。
- Java對映
- XSLT對映
- ABAP對映
圖形化對映是最常用的手段，因為它允許開發者圖形化地對映結構的屬性，以透過服務介面傳遞資料。對於其它三個，需要透過寫程式碼來開發對映。如果是如果是單棧伺服器，ABAP對映是不可用的。
（還有些其它方面，本文沒有涉及）
整合目錄
這裡我們透過早先配置的ESR物件來製作管線步驟。這些步驟在執行期間透過整合引擎執行。
在我們開始配置之前，我們需要在DIR建立/匯入以下的物件：
- 服務——業務系統/業務服務/整合過程
- 通訊通道
服務允許你處理訊息的傳送者或者接收者。根據你使用這些服務的目的，你可以選擇以下的服務型別：
- 業務系統——如果你想要將指定的業務系統作為訊息的傳送者或者接收者處理，選擇該訊息型別。在系統規劃中，業務系統是真實的應用系統。
- 業務服務——如果你想要將抽象業務實體作為訊息的傳送者或者接收者處理，選擇這個服務型別。業務服務不會再系統規劃中定義。
- 整合過程服務——如果你想要將整合過程作為訊息的傳送者或者接收者處理，選擇這個服務型別。在執行期間，這些整合過程由訊息控制，他們自己也可以傳送訊息。
通訊通道決定了訊息的內向和外向處理。訊息會透過介面卡從原生格式被轉換為soap-xml指定的訊息格式，或者相反。通常一個場景中會有兩個通訊通道：
- 傳送者通道。
- 接收者通道。
必須為服務分配一個通道。根據服務被視為訊息的傳送者或接收者，通道也會有一個傳送者/接收者角色，二者必須匹配。不可以把通道分配給整合過程服務。
管線步驟DIR中的透過以下四步配置：
- 傳送者協議
- 接收者判定
- 介面判定
- 接收者協議
傳送者協議定義了傳送者的訊息如何轉換，因此它可以由整合系統處理。它包含：
- 傳送者元件
- 傳送者介面
- 傳送者通道
傳送者協議類似於表中的主鍵。同一個規劃中不可以有兩個相同的傳送者協議。
接收者協議則定義了訊息如何被轉換為接收者可以處理的形式。它包含：
- 傳送者元件
- 接收者元件
- 接收者介面
- 接收者通道
使用接收者判定來指定訊息傳送的物件。可以透過定義條件以轉發訊息，它包括：
- 傳送者元件
- 傳送者介面
- 接收者元件
接收者判定包含2個型別——標準的和擴充套件的。使用哪個取決於你想要手工指定接收者、還是在在執行期間透過對映動態地指定。
接收者判定和介面判定——加在一起通常稱為邏輯路由。傳送者協議和接收者協議——這兩個加在一起通常成為合作協議。
系統規劃
SAP System Landscape Directory（SLD）是系統規劃中的核心資訊的提供者。在web頁面上你可以發現以下連線：
- 技術系統——技術系統是在你的系統規劃中安裝的應用系統。
- 業務系統——業務系統是邏輯系統，在PI內作為傳送者/接收者存在。業務系統與相關的技術性同有著一對一的依賴關係。
- 產品和元件——這是有關所有SAP產品和元件的資訊，包含他們的版本。如果系統規劃內有任何第三方產品，它們也會註冊在這裡。
SLD的介面如下圖所示：
產品和元件都可以叫做元件資訊。
技術系統和業務系統都叫做規劃描述（ Landscape Description ）。
一個業務系統可以配置為整合伺服器或者應用系統。
- 整合伺服器（ Integration server） ——整合伺服器只執行在整合構建器中配置的整合邏輯。它們也可以被識別為管線步驟。它接受XML資訊、判斷接收者、執行對映、路由XML資訊到相應的接收者系統。因此配置過的整合引擎被識別為中央配置整合引擎。
- 應用系統（ Application system） ——應用系統不會執行整合邏輯。它一次呼叫整合伺服器以執行整合邏輯。它會扮演XML訊息的傳送者或接收者的角色。因此，帶有本地整合引擎的應用系統需要整合伺服器來執行整合邏輯。
只有一個SAP系統中的客戶端可以配置為整合伺服器。
以下資訊從SLD提取到ESR和DIR中：
- ESR中用到的用於定義產品的元件資訊和SWCV。
-
在目錄中用於定義訊息傳送者和訊息接收者的業務系統。
配置和監控
配置和監控是監測的中心入口。它給予了你導航到整合引擎的功能，也可以與計算中心管理系統（ Computing Center Management System，CCMS ）、SAP的程式監控設施（ Process Monitoring Infrastructure，PMI ）整合。
配置和監控的介面如下圖：
配置和監控支援以下監控功能：
- 元件監控——監控不同的SAP PI元件，包括Java和ABAP部分。
- 訊息監控——跟蹤SAP PI元件中的訊息處理狀態，以及錯誤偵測和分析。
- 端對端監控——從PI的視角監控訊息的生命週期。
- 效能監控——可以透過RWW統計SAP PI的不同方面的效能。這裡，你可以選擇並聚合效能資料，比如，根據元件、時間序列、訊息屬性等。
- 索引管理——透過管理和監控每個PI元件的訊息的索引，可以在訊息監視中啟用基於索引的訊息搜尋。這種訊息搜尋提供了增強的選擇標準，包含指定介面卡的訊息屬性和訊息載荷中的術語或短語。
- 警報配置——透過使用警報框架，PI中的中心監控可以在訊息處理期間獲得所有的錯誤報告。它可以幫助改進ABAP執行期間和基於Java的介面卡引擎來改進對錯誤的處理。為此，警報框架包含了基於確定時間的規則，相關內容處於PI訊息協議的頭部。這些規則決定了警報是否傳送。如果傳送了警報，警報可以用於錯誤分析。
- 警報信箱——警報信箱是使用者特定的、顯示各個警報伺服器中根據警報配置而產生的所有警報。
- 快取監控器——快取監控器顯示當前執行時快取中的快取物件。不同的快取物件的監控是依據快取例項進行的。
同步 vs. 非同步
處理可以定義為同步或者非同步。
- 同步處理透過請求/響應操作呼叫，處理的結果立刻透過操作返回給呼叫者。
- 非同步處理透過單方向的操作呼叫，結果和錯誤會透過另一個單向的操作呼叫。結果透過回撥操作返回。
計算機的世界裡沒有非同步通訊，所有的兩個系統之間的通訊總是透過方法呼叫進行（請求/響應操作）。所以如何使其非同步呢？答案是，在呼叫者和被呼叫者之間引入一個第三方的系統。
假設存在兩個系統——A和B。A與B之間所有的通訊透過一個方法呼叫來進行，因此他們是同步的。我們在AB間引入一個第三方系統，稱其為中間系統I。A和I之間的通訊透過方法呼叫，I和B之間的通訊也是透過方法呼叫進行。但是A和B之間的呼叫可以是非同步的，因為A不需要等待來自B的響應。
這是非同步通訊的基本原理，那麼什麼是中間系統呢？答案是佇列。A被稱為呼叫者，B被稱為接收者。來自於A的訊息首先新增到佇列中，接著它再次被從佇列中拉出，並且傳送給B。B的響應透過相同的方式返回給A。在某些情況下，業務需求要求訊息按照以A觸發的時順序傳送給B，這種情況下可以依據先進先出策略。如果沒有這樣的需求，則訊息會以隨機順序從佇列傳送至B。
因此可以把訊息通訊分為三類：
- 同步的
- 非同步且無序的
- 非同步且有序的
在PI中，我們定義它們為：同步——BE（Best Effort），非同步且無序的——EO（Exactly Once），非同步且有序的（Exactly Once in Order）。
確認
確認是非同步通訊的基礎，為什麼？
對於同步通訊，系統A呼叫系統B時，如果B傳送響應失敗，處理會失敗。但是在非同步通訊中，系統A呼叫系統I並且系統I會呼叫系統B。所以假設A與I之間的通訊成功，然而I和B之間的通訊失敗。A該怎樣得知傳送到B的過程失敗了呢？它透過確認來實現，該確認透過訊息從A到B相同的路由方式，反向傳送給A。如果從B到A的確認沒有成功抵達A，那麼A會認為處理失敗，並且再次傳送訊息。
當我們討論PI中的非同步的時候，我們會使用術語 ‘Exactly Once’ 來表示EO和EOIO。Exactly Onc的意思是一旦傳送的訊息不能再次傳送。為了實現這一特性，每一個從A發往B的訊息都會有一個確認。通訊的終端是介面卡，因此介面卡必須支援確認。
所有介面卡都提供系統確認（system-acknowledgment），比如傳送確認。支援同步通訊的介面卡除了支援系統確認以外還支援應用確認。
所以在PI中存在著以下型別的確認：
- 系統確認——系統確認在執行期間使用，以確認非同步訊息已抵達接收者。
- 應用確認——應用確認用以確保非同步訊息成功地被接收者處理。
Remote Function Call
在進行PI工作時，你會接觸到名詞——RFC。這是什麼？為了建立兩個SAP系統之間的連線，比如R/3和PI，我們建立了RFC目標。RFC目標需要配置以下內容：
- 連線型別
- 接收者的IP地址和埠
連線型別描述了系統連線的型別，比如R/3，TCP/IP，內部連線等等..
建立的RFC目標可以根據通訊型別分類。按照非同步或者同步通訊可以分為：
- 同步通訊——同步RFC
- 非同步通訊且無順序——Transactional RFC（tRFC）
- 非同步通訊且有順序——Queued RFC（qRFC）
（譯者注：此外還有bgRFC）