SAP PI入門

時間 2019-11-07

標籤 sap 入門简体版

原文原文鏈接

本教程的目的是讓讀者理解：SAP Process Integration（如下簡稱SAP PI）是什麼。咱們不須要探究課題的本質，可是會討論SAP PI的架構和不一樣特色。本文只會覆蓋到PI的基本特色，而不是討論所有。html

本文連接：http://www.cnblogs.com/hhelibeb/p/7105070.htmlweb

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不是一個單獨的組件，而是不少個能夠根據集成場景靈活地一塊兒工做的組件的集合。該架構包含了在設計期間使用的組件、在配置期間使用的組件和在運行期間使用的組件。app

咱們能夠把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

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棧。

消息能夠是兩種類型：

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

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