SAP PI入门
?
https://www.cnblogs.com/hhelibeb/p/7105070.html
?
?SAP PI入門
目錄
- SAP ERP是什么
- 遺留系統
- 為什么我們需要SAP PI
- SAP PI架構
- 單棧與雙棧
- 集成引擎
- 適配器引擎
- 業務處理引擎
- 在SAP PI中建立場景
- 企業服務庫
- 集成目錄
- 系統規劃
- 配置和監控
- 同步 vs. 異步
- 確認
- Remote Function Call
?
正文
本教程的目的是讓讀者理解：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劃分為多個領域：
集成服務器是SAP PI的中心處理引擎。所有消息都在這里以一致的方式處理。它包含三個獨立引擎：
集成引擎可以被看做是中心，而適配器引擎則是輪輻。
關于業務處理引擎，本文會晚些解釋。
集成構建器是一個用于訪問和編輯集成對象的C/S框架，它包含兩個相關的工具：
二者放在一起，就是通常被成為場景的集成過程。
系統規劃是數據中心的一個有關軟件和系統的信息的中心庫，簡化了系統規劃的管理。
在配置和監控中，可以監控消息和適配器。
回到頂部單棧與雙棧
在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格式的消息結構和說明。
基于上面的限制，會有三種接口類型：
在PI中為每一個業務需求配置集成邏輯（場景）的時候，集成引擎會以循序漸進的方式執行配置。術語“管線”指的是在處理XML消息的時候執行的所有步驟。管線步驟包含：
適配器引擎
你一定已經發現，集成引擎只使用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），要從主頁開始。
主頁界面如下：
主頁有以下四個工作區的超鏈接：
每個超鏈接都可以打開對應的應用。這四個都是Java應用。ESR和ID是swing應用。它們基于JNLP，需要從瀏覽器啟動，所以第一次會花較多的時間來下載整個庫文件。但是從第二次開始，加載時間就會變短了。SL和CM是純web應用，運行在瀏覽器上。
回到頂部企業服務庫
?使用企業服務庫設計和創建用于制作場景的對象。PI中的數據流是這樣的：
找到以下設計的選項：
PI使用集成庫來為發送者和接收者設計消息結構，并且通過相應的消息結構開發接口消息，接口消息是與外部世界互動的一個點。數據類型和消息類型可以用來對復雜接口進行簡化和模塊化設計。
操作映射允許源結構和目標結構之間的轉換。但是如果源結構和目標結構是相同的，那該過程可能會免于執行。和服務接口類似，消息映射用于簡化和木塊話復雜的操作映射。消息映射可以通過四種方式進行：
圖形化映射是最常用的手段，因為它允許開發者圖形化地映射結構的屬性，以通過服務接口傳遞數據。對于其它三個，需要通過寫代碼來開發映射。如果是如果是單棧服務器，ABAP映射是不可用的。
（還有些其它方面，本文沒有涉及）
回到頂部集成目錄
這里我們通過早先配置的ESR對象來制作管線步驟。這些步驟在運行期間通過集成引擎執行。
在我們開始配置之前，我們需要在DIR創建/導入以下的對象：
服務允許你處理消息的發送者或者接收者。根據你使用這些服務的目的，你可以選擇以下的服務類型：
通信通道決定了消息的內向和外向處理。消息會通過適配器從原生格式被轉換為soap-xml指定的消息格式，或者相反。通常一個場景中會有兩個通信通道：
必須為服務分配一個信道。根據服務被視為消息的發送者或接收者，信道也會有一個發送者/接收者角色，二者必須匹配。不可以把信道分配給集成過程服務。
管線步驟DIR中的通過以下四步配置：
發送者協議定義了發送者的消息如何轉換，因此它可以由集成系統處理。它包含：
發送者協議類似于表中的主鍵。同一個規劃中不可以有兩個相同的發送者協議。
接收者協議則定義了消息如何被轉換為接收者可以處理的形式。它包含：
使用接收者判定來指定消息發送的對象。可以通過定義條件以轉發消息，它包括：
接收者判定包含2個類型——標準的和擴展的。使用哪個取決于你想要手工指定接收者、還是在在運行期間通過映射動態地指定。
接收者判定和接口判定——加在一起通常稱為邏輯路由。發送者協議和接收者協議——這兩個加在一起通常成為合作協議。
回到頂部系統規劃
SAP System Landscape Directory（SLD）是系統規劃中的核心信息的提供者。在web頁面上你可以發現以下連接：
SLD的界面如下圖所示：
產品和組件都可以叫做組件信息。
技術系統和業務系統都叫做規劃描述（Landscape Description）。
一個業務系統可以配置為集成服務器或者應用系統。
只有一個SAP系統中的客戶端可以配置為集成服務器。
以下信息從SLD提取到ESR和DIR中：
在目錄中用于定義消息發送者和消息接收者的業務系統。
配置和監控
配置和監控是監測的中心入口。它給予了你導航到集成引擎的功能，也可以與計算中心管理系統（Computing Center Management System，CCMS）、SAP的進程監控設施（Process Monitoring Infrastructure，PMI?）集成。
配置和監控的界面如下圖：
配置和監控支持以下監控功能：
同步 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目標需要配置以下內容：
連接類型描述了系統連接的類型，比如R/3，TCP/IP，內部連接等等..
創建的RFC目標可以根據通信類型分類。按照異步或者同步通信可以分為：
（譯者注：此外還有bgRFC）
?
原文標題：SAP PI for Beginners
?
轉載于:https://www.cnblogs.com/DicksonJYL/p/11145946.html
總結
- 上一篇： QTP的随机数问题
- 下一篇： Django后台admin的使用