SAP PI入門

本教程的目的是讓讀者理解：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划分為多個領域：

1. 集成服務器（Integration Server）
2. 集成構建器（Integration Builder）
3. 系統規划（System Landscape）
4. 配置和監控（Configuration and Monitoring）

集成服務器是SAP PI的中心處理引擎。所有消息都在這里以一致的方式處理。它包含三個獨立引擎：

1. 集成引擎（Integration Engine）
2. 適配器引擎（Adapter Engine）
3. 業務處理引擎（Business Process Engine）

集成引擎可以被看做是中心，而適配器引擎則是輪輻。

關於業務處理引擎，本文會晚些解釋。

集成構建器是一個用於訪問和編輯集成對象的C/S框架，它包含兩個相關的工具：

1. 企業服務庫（Enterprise Service Repository ，ESR）——用於設計和開發在不同場景下使用的對象。
2. 集成目錄（Integration Directory，ID）——用於配置開發場景的ESR組件。

二者放在一起，就是通常被成為場景的集成過程。

系統規划是數據中心的一個有關軟件和系統的信息的中心庫，簡化了系統規划的管理。

在配置和監控中，可以監控消息和適配器。

單棧與雙棧

在PI初次發布的時候，不是所有的組件都是在同一個平台上構建的。集成引擎和業務處理引擎由ABAP構建，然而適配器引擎、集成構建器、SL、CM和Mapping Runtime由Java構建。因此PI需要Java和ABAP環境來運行，這被稱為雙棧。

ABAP Stack	Java Stack
Integration Engine Business Process Engine Integration Builder	Enterprise Service Repository Integration Directory Runtime Workbench System Landscape Directory Adapter Engine Mapping Runtime

但是在晚些的版本中，所有組件都是由Java構建的。某些雙棧組件已經廢除，或者在被修改后運行在Java棧。因此PI只需要Java環境來運行。這就是單棧。

（單雙棧各有利弊，但是本文不會涉及到相關內容）

集成引擎

集成引擎負責中央集成服務器服務，例如管線步驟：路由和映射。如果源消息結構和目標的消息結構不同，集成引擎調用Mapping Runtime，源結構會被轉換成目標結構。Mapping Runtime基於Java棧。集成引擎也可以利用ABAP程序來轉換，這個基於ABAP棧。

消息可以是兩種類型：

1. 同步的——有請求和響應兩部分。
2. 異步的——只有請求或者響應二者之一。

 

在PI中，消息由接口表示。

接口：XML格式的消息結構和說明。

基於上面的限制，會有三種接口類型：

1. 外向接口——連接發送系統。
2. 內向接口——連接接收系統
3. 抽象接口——連接BPE。

在PI中為每一個業務需求配置集成邏輯（場景）的時候，集成引擎會以循序漸進的方式執行配置。術語“管線”指的是在處理XML消息的時候執行的所有步驟。管線步驟包含：

1. 接收者識別——決定參加消息交換的系統。
2. 接口識別——判斷應該使用何種接口接受消息。
3. 消息分割——如果找到了不止一個接收者，PI會為每一個接收者實例化新的消息。
4. 消息映射——把源消息映射為目標消息的格式。
5. 技術路由——為消息綁定特定的目標和協議。
6. 調用適配器——發送轉換過的消息給適配器或者代理。

適配器引擎

你一定已經發現，集成引擎只使用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，包含以下功能：

1. 全狀態消息處理：集成過程的狀態可以在集成服務器上持久化。
2. 可以使用相關性建立消息間的語義關系。
3. 當你想要定義、控制、監控復雜的集成過程的時候，比如擴展到企業和應用程序邊界，即收集/合並、拆分、多播的時候，需要實現集成過程。

在運行期間，BPE執行集成過程。集成過程可以只通過抽象接口發送和接收消息。

在SAP PI中建立場景

如果需要在PI中建立場景（scenario），要從主頁開始。

主頁界面如下：

主頁有以下四個工作區的超鏈接：

1. 企業服務庫（ESR）
2. 集成目錄（ID）
3. 系統規划（SL）
4. 配置和監控（CM）

每個超鏈接都可以打開對應的應用。這四個都是Java應用。ESR和ID是swing應用。它們基於JNLP，需要從瀏覽器啟動，所以第一次會花較多的時間來下載整個庫文件。但是從第二次開始，加載時間就會變短了。SL和CM是純web應用，運行在瀏覽器上。

企業服務庫

 使用企業服務庫設計和創建用於制作場景的對象。PI中的數據流是這樣的：

找到以下設計的選項：

1. 接口對象——服務接口，消息類型，數據類型。
2. 映射對象——操作映射和消息映射。
3. 集成過程。

PI使用集成庫來為發送者和接收者設計消息結構，並且通過相應的消息結構開發接口消息，接口消息是與外部世界互動的一個點。數據類型和消息類型可以用來對復雜接口進行簡化和模塊化設計。

操作映射允許源結構和目標結構之間的轉換。但是如果源結構和目標結構是相同的，那該過程可能會免於執行。和服務接口類似，消息映射用於簡化和木塊話復雜的操作映射。消息映射可以通過四種方式進行：

1. 圖形化映射。
2. Java映射
3. XSLT映射
4. ABAP映射

圖形化映射是最常用的手段，因為它允許開發者圖形化地映射結構的屬性，以通過服務接口傳遞數據。對於其它三個，需要通過寫代碼來開發映射。如果是如果是單棧服務器，ABAP映射是不可用的。

（還有些其它方面，本文沒有涉及）

集成目錄

這里我們通過早先配置的ESR對象來制作管線步驟。這些步驟在運行期間通過集成引擎執行。

在我們開始配置之前，我們需要在DIR創建/導入以下的對象：

1. 服務——業務系統/業務服務/集成過程
2. 通信通道

服務允許你處理消息的發送者或者接收者。根據你使用這些服務的目的，你可以選擇以下的服務類型：

1. 業務系統——如果你想要將指定的業務系統作為消息的發送者或者接收者處理，選擇該消息類型。在系統規划中，業務系統是真實的應用系統。
2. 業務服務——如果你想要將抽象業務實體作為消息的發送者或者接收者處理，選擇這個服務類型。業務服務不會再系統規划中定義。
3. 集成過程服務——如果你想要將集成過程作為消息的發送者或者接收者處理，選擇這個服務類型。在運行期間，這些集成過程由消息控制，他們自己也可以發送消息。

通信通道決定了消息的內向和外向處理。消息會通過適配器從原生格式被轉換為soap-xml指定的消息格式，或者相反。通常一個場景中會有兩個通信通道：

1. 發送者信道。
2. 接收者信道。

必須為服務分配一個信道。根據服務被視為消息的發送者或接收者，信道也會有一個發送者/接收者角色，二者必須匹配。不可以把信道分配給集成過程服務。

管線步驟DIR中的通過以下四步配置：

1. 發送者協議
2. 接收者判定
3. 接口判定
4. 接收者協議

發送者協議定義了發送者的消息如何轉換，因此它可以由集成系統處理。它包含：

1. 發送者組件
2. 發送者接口
3. 發送者信道

發送者協議類似於表中的主鍵。同一個規划中不可以有兩個相同的發送者協議。

接收者協議則定義了消息如何被轉換為接收者可以處理的形式。它包含：

1. 發送者組件
2. 接收者組件
3. 接收者接口
4. 接收者信道

使用接收者判定來指定消息發送的對象。可以通過定義條件以轉發消息，它包括：

1. 發送者組件
2. 發送者接口
3. 接收者組件

接收者判定包含2個類型——標准的和擴展的。使用哪個取決於你想要手工指定接收者、還是在在運行期間通過映射動態地指定。

接收者判定和接口判定——加在一起通常稱為邏輯路由。發送者協議和接收者協議——這兩個加在一起通常成為合作協議。

系統規划

SAP System Landscape Directory（SLD）是系統規划中的核心信息的提供者。在web頁面上你可以發現以下連接：

1. 技術系統——技術系統是在你的系統規划中安裝的應用系統。
2. 業務系統——業務系統是邏輯系統，在PI內作為發送者/接收者存在。業務系統與相關的技術性同有着一對一的依賴關系。
3. 產品和組件——這是有關所有SAP產品和組件的信息，包含他們的版本。如果系統規划內有任何第三方產品，它們也會注冊在這里。

SLD的界面如下圖所示：

產品和組件都可以叫做組件信息。

技術系統和業務系統都叫做規划描述（Landscape Description）。

一個業務系統可以配置為集成服務器或者應用系統。

1. 集成服務器（Integration server）——集成服務器只運行在集成構建器中配置的集成邏輯。它們也可以被識別為管線步驟。它接受XML信息、判斷接收者、運行映射、路由XML信息到相應的接收者系統。因此配置過的集成引擎被識別為中央配置集成引擎。
2. 應用系統（Application system）——應用系統不會執行集成邏輯。它一次調用集成服務器以運行集成邏輯。它會扮演XML消息的發送者或接收者的角色。因此，帶有本地集成引擎的應用系統需要集成服務器來執行集成邏輯。

只有一個SAP系統中的客戶端可以配置為集成服務器。

以下信息從SLD提取到ESR和DIR中：

1. ESR中用到的用於定義產品的組件信息和SWCV。

2. 在目錄中用於定義消息發送者和消息接收者的業務系統。

配置和監控

配置和監控是監測的中心入口。它給予了你導航到集成引擎的功能，也可以與計算中心管理系統（Computing Center Management System，CCMS）、SAP的進程監控設施（Process Monitoring Infrastructure，PMI ）集成。

配置和監控的界面如下圖：

配置和監控支持以下監控功能：

1. 組件監控——監控不同的SAP PI組件，包括Java和ABAP部分。
2. 消息監控——跟蹤SAP PI組件中的消息處理狀態，以及錯誤偵測和分析。
3. 端對端監控——從PI的視角監控消息的生命周期。
4. 性能監控——可以通過RWW統計SAP PI的不同方面的性能。這里，你可以選擇並聚合性能數據，比如，根據組件、時間序列、消息屬性等。
5. 索引管理——通過管理和監控每個PI組件的消息的索引，可以在消息監視中啟用基於索引的消息搜索。這種消息搜索提供了增強的選擇標准，包含指定適配器的消息屬性和消息載荷中的術語或短語。
6. 警報配置——通過使用警報框架，PI中的中心監控可以在消息處理期間獲得所有的錯誤報告。它可以幫助改進ABAP運行期間和基於Java的適配器引擎來改進對錯誤的處理。為此，警報框架包含了基於確定時間的規則，相關內容處於PI消息協議的頭部。這些規則決定了警報是否發送。如果發送了警報，警報可以用於錯誤分析。
7. 警報信箱——警報信箱是用戶特定的、顯示各個警報服務器中根據警報配置而產生的所有警報。
8. 緩存監控器——緩存監控器顯示當前運行時緩存中的緩存對象。不同的緩存對象的監控是依據緩存實例進行的。

同步 vs. 異步

處理可以定義為同步或者異步。

• 同步處理通過請求/響應操作調用，處理的結果立刻通過操作返回給調用者。
• 異步處理通過單方向的操作調用，結果和錯誤會通過另一個單向的操作調用。結果通過回調操作返回。

計算機的世界里沒有異步通信，所有的兩個系統之間的通信總是通過方法調用進行（請求/響應操作）。所以如何使其異步呢？答案是，在調用者和被調用者之間引入一個第三方的系統。

 假設存在兩個系統——A和B。A與B之間所有的通信通過一個方法調用來進行，因此他們是同步的。我們在AB間引入一個第三方系統，稱其為中間系統I。A和I之間的通信通過方法調用，I和B之間的通信也是通過方法調用進行。但是A和B之間的調用可以是異步的，因為A不需要等待來自B的響應。

這是異步通信的基本原理，那么什么是中間系統呢？答案是隊列。A被稱為調用者，B被稱為接收者。來自於A的消息首先添加到隊列中，接着它再次被從隊列中拉出，並且發送給B。B的響應通過相同的方式返回給A。在某些情況下，業務需求要求消息按照以A觸發的時順序發送給B，這種情況下可以依據先進先出策略。如果沒有這樣的需求，則消息會以隨機順序從隊列發送至B。

因此可以把消息通信分為三類：

1. 同步的
2. 異步且無序的
3. 異步且有序的

在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中存在着以下類型的確認：

1. 系統確認——系統確認在運行期間使用，以確認異步消息已抵達接收者。
2. 應用確認——應用確認用以確保異步消息成功地被接收者處理。

Remote Function Call

在進行PI工作時，你會接觸到名詞——RFC。這是什么？為了建立兩個SAP系統之間的連接，比如R/3和PI，我們創建了RFC目標。RFC目標需要配置以下內容：

1. 連接類型
2. 接收者的IP地址和端口

連接類型描述了系統連接的類型，比如R/3，TCP/IP，內部連接等等..

創建的RFC目標可以根據通信類型分類。按照異步或者同步通信可以分為：

1. 同步通信——同步RFC
2. 異步通信且無順序——Transactional RFC（tRFC）
3. 異步通信且有順序——Queued RFC（qRFC）

（譯者注：此外還有bgRFC）

 

原文標題：SAP PI for Beginners

 

有關RFC的介紹：SAP RFC介紹：關於sRFC，aRFC，tRFC，qRFC和bgRFC