IDoc(wedi)
IDoc:intermediate(媒介)document
IDoc是一種系統間通用的數據交換格式,通過IDoc接口可以實現SAP系統之間以及SAP系統與其他系統之間的數據交換。
基於IDoc的應用技術有:
ALE:多用於同一個企業中不同SAP系統之間的數據交換,通過IDoc格式的數據創建分布式系統
EDI(electronic data exchange,電子數據交換):用於實現不同企業間的電子數據交換
IDoc的事務碼比較多,不常用的話記不住,但SAP提供了一個事務碼列出的基本上所有的IDoc相關的事務碼,即wedi,運行結果如下:
Process code處理代碼設定(WE41、WE42、WE40、WE64)
處理代碼用於確定數據寫入IDoc或從IDoc讀取的處理方式,處理代碼對應具體的功能模塊或者工作流。入站和出站處理的伙伴參數中都可以指定處理代碼
對於IDoc異常處理,有如下兩種類型的處理代碼,通過WE40進行設置:
系統處理代碼,應用於入站或出站過程中的IDoc異常重處理
狀態處理代碼,應用於狀態確認過程中的異常處理
消息類型和處理代碼之間的關系是多對多,即一個消息類型的處理可通過多個處理代碼實現;而一個處理代碼也可以應用於多個消息類型。要查看一個業務過程中消息類型的可用處理代碼,可以首先找到該消息類型,然后通過事務WE64列出消息類型全部可用處理代碼:
Idoc生成XML(WE60)
Tools--ALE--ALE Administration--Services--Documentation進入文檔工具,可選輸出為XML
基本概念
ALE
ALE(Application Link and Enabling)是SAP專門為SAP與SAP之間所設計的整合中間件。ALE從SAP 3.0版本開始就作為SAP整個應用體系的一部分,分布式數據交換提供了可靠安全的通訊機制。ALE的設計,原本作為兩個SAP流程之間的一種消息傳遞服務,使SAP與SAP的業務流程之間數據能夠有效的交換,為兩個獨立的SAP系統提供整合服務。不過隨着應用的發展,ALE接口機制也成為了其它非SAP系統的標准整合方式。
EDI
EDI(Electronic Document Interchange,電子數據交換)其實就是采用標准格式的電子數據,用於在通訊網絡中在業務伙伴間交換業務文檔所用。你可這樣理解EDI,就是大家都按相同的排列放置數據到一個數據文檔中,並按相同的排列解析此文檔以得到所需的內容。 EDI又被叫做無紙化交換。
IDoc
IDoc(Intermediate Document,中轉文檔)是SAP提供的系統整合專用的數據/消息格式,它通過ALE方式來進行交換,而SAP就是IDoc提供了EDI的支持,你也可以把IDoc認為是EDI的一個實現。
交換
EDI的交換有兩個流程:
? 外發(Outbound process或簡稱OP)
接收(Inbound process或簡稱IP)
SAP也是完全遵循着EDI的這兩個流程,並做了相應的實現。在外發過程中:
1. 應用文檔被創建
2. IDoc生成
3. IDoc從SAP傳送到操作系統
4. IDoc被轉換成EDI標准格式
5. EDI文件被傳送到業務伙伴處(所以業務伙伴可以沒有SAP,因為EDI是個標准)
6. EDI子系統將傳送的狀態回報給SAP
在接收過程中:
1. EDI文檔被接收
2. EDI文檔被轉換成IDoc
3. IDoc傳送到SAP層
4. 應用文檔在SAP中創建
5. 應用文檔現在可供瀏覽了
IDoc的特性
每個IDoc都被分派了唯一的號碼,用於跟蹤及其后參考所用
IDoc包含多個段(segment),而段內包含有多個字段
IDoc包含有三種類型的記錄:一條控制記錄,一個或多個數據記錄,一個或多個狀態記錄
端口(Port)
端口用於外發流程,它判斷EDI子系統程序名稱、IDoc文件傳送到操作系統的目錄,IDoc文件名和RFC目的地
RFC目的地
用於定義到遠程系統通訊連接的特性以及需要調用何種功能
Partner Profile
Partner Profile指定在外發過程中所用的各類組件(業務伙伴號、IDoc類型、信息類型、端口、處理碼等),通訊方式(異步或同步)以及當錯誤時通知何人
IDoc定義及擴展(WE30)
IDoc type:IDoc結構,不同的SAP業務對象對應不同的IDoc類型(一個或多個)。IDoc類型中定義了數據段以及數據段的層級和次序
標准SAP系統提供的IDoc類型稱為基本類型(Basic type),該類型可以通過IDoc擴展(Extention)進行調整,即在SAP IDoc類型結構的基礎上增加新的數據段或者在數據段中增加新字段
通過事務碼WE30,可以查看IDoc類型的定義結構:
如下面的FIDCCP01 IDoc類型對應於業務對象:賬務憑證(FI Document):
從上圖可以看出 IDoc類型中的數據段有層級的
IDoc基本類型(Basic type)、擴展(Extension)類型
如果是自己完全創建一個新的類型,不擴展任何類型,則選擇“Basic Type”,否則如果是要從已存在類型來擴展出新的類型時,需要選擇“Extension”,並且需要指定basic type:
在IDoc的控制記錄數據庫表中,通過下列字段來確定IDoc類型:
l IDOCTYP,基本類型名稱
l CIMTYP,擴展名稱
如,ORDERS01是一個SAP標准系統中的IDoc類型:
l 該IDoc類型的控制記錄字段IDOCTYP值為ORDERS01;
l 該IDoc類型的控制記錄字段CIMTYP為空;
IDoc類型ORDERS01被用戶擴展之后,則:
l 該IDoc類型的控制記錄字段IDOCTYP值為ORDERS01;
l 該IDoc類型的控制記錄字段CIMTYP為其擴展名,如ZORDERS01;
一個標准系統中的IDoc類型只能被擴展一次
除去使用SAP標准或擴展該IDoc類型之外,還可以完全不依賴於SAP標准IDoc,開發新的IDoc類型,並通過為其分配處理代碼完成相關處理過程
數據段類型和數據段定義(WE31)
數據段是IDoc的基本結構塊,用於存放應用數據。
數據段是IDoc結構組件,是IDoc的構成的單元。它由Segment type(數據段類型)與Segm. definition(數據段定義)兩部分組成,其中Segment type的名稱與SAP版本無關,但Segm. definition名稱是與SAP版本有關的,外部系統就是根據Segm. definition名稱來確定當前數據段的版本的:
SAP提供的標准數據段類型定義中,Segment type名稱以“E1”開頭,而Segm. definition名稱則以“E2”開頭(如果為用戶自定的數據段,則數據段類型名應以“Z1”開頭,數據段定義名稱應以“Z2”開頭),且后面跟上版本號(如上面的006),如數據段類型E1FIKPF對應多個版本的數據段定義(包括最初版本在內共7個版本):
雙擊006版本,即可查看數據段類型F1FIKPF的最新具體定義,如上上圖所示。
IDoc數據段中各個字段的數據類型均為字符類型(如上上圖中的Export leng),在出站時已將原數據類型都轉換為字符型了。另外,在ABAP程序中,訪問IDoc中的具體某個字段時,需要通過Segment type(數據段類型)名而不是Segm. definition(數據段定義)名,如:E1FIKPF-BUKRS,而不是E2FIKPF006-BUKRS之類的。
IDoc Type中的數據段類型實質上都是定義在數據字典中的ABAP結構(如上圖數據段類型E1FIKPF ,在SE11顯示如下,但數據段之間的層級關系在結構里沒有體現出來,再就是層級關系起什么作用?):
IDoc類型定義相關函數
除IDoc類型定義工具外,SAP還提供了一系列與IDoc類型和數據段開發相關的功能模塊
函數組EDIM中的SAP內部功能模塊用於操作IDoc基本類型和擴展:
IDoc版本控制
通過數據段Segment定義工具 WE31定義段時,版本由工具自動控制,如在定義時,工具會根據當前修改的次數來管理版本號,以下Segm.definition不能輸入,是自動生成的:
當前版本發布后,就可以通過按鈕增加下一個版本(前提條件是當前版本已經發布):
發布當前版本:
如果在同一個SAP系統版本中(如這里為731)點擊按鈕增加一個新的版本時,狀態欄會出現警告(這是因為在同一SAP版本中不必要創建不同版本的數據段,完全可以先通過菜單“取消發布”后,再次在原來版本上修改數據段),回車,可繼續增加新版本:
所以,每個發布創建之后,開發工作都會產生新的IDoc版本。所有舊版本仍然存儲於系統中,從而保留了將現有版本回設為舊版本的可能,確保向后兼容,所以同樣為了向后兼容,新的IDoc版本相對舊版本只能增加數據段和數據字段,而不能減少
在出站處理過程中,需要通過伙伴參數注明IDoc類型,並指定數據段的SAP發布版本。如果指定一個舊版本的發布,IDoc類型中所有數據段都回設為對應的舊版;如果該字段為空,則使用當前發布相關的最新所有活動版本
在入站處理過程中,不需要再次進行版本相關的設定,IDoc接口將負責識別版(根據Segment數據段名來確定)本並進行數據處理
IDoc其他工具
WE02:IDoc顯示工具
WE09:在不知道IDoc類型、伙伴參數等技術細節情況下,有時不能通過IDoc控制記錄中的信息來確定一個IDoc,如在需要通過其中所包含的應用數據來確定一個IDoc的情況下。如,需要查找包含物料A001的采購訂單,此時就需要通過IDoc查找工具,該工具可以查找數據庫及已經歸檔文件中的IDoc
IDoc狀態(BD87)
配置IDoc應用示例
環境介紹
在同一套IDES系統中,將兩個client模擬成發送方與接收方。因為所需傳送的數據是client相關的,所以這個方案可行。
選擇了800作為發送方,而810作為接收方。我將從800發送物料主數據到810中。
操作步驟
第一步為Client創建邏輯系統(SALE)
在ALE過程中,消息在系統之間,每一個ALE分布處理的參與系統必須擁有唯一的ID,這個ID即為邏輯系統。一般一個邏輯系統代指一個集團如果沒有兩個SAP系統,可以在一個SAP系統中的兩個不同的Client端完成。我選擇了800作為發送方,而810作為接收方。我將從800發送物料主數據到810中
如果參與ALE的兩個集團不在同一SAP系統中,則需要在兩邊系統中分別為這兩個集團設定邏輯系統名稱,且要相同;如果是在同一SAP系統中不同集團之間,則只需要進行一次邏輯系統名稱的定義即可,因為該設定是跨集團Client的。
第二步為Client指派邏輯系統(SALE)
定義好邏輯系統名后,可將名分配給相關的集團
系統中已經分配了邏輯系統的,只能重新分配了(即修改邏輯系統):
第三步維護RFC目標(SM59)
ALE的通信實例技術是RFC,需要為數據交換的對方維護RFC目標,以建立通信連接。由於是在SAP系統之間通信,所以選擇ABAP連接類型
名稱最好跟邏輯系統名稱一致,以便於自動生成partner profile
第四步在發送端創建Distribution Model(BD64)
分布模型用於描述業務對象在邏輯系統間的分布流程。分布模型視圖將所有系統分布情景組織起來集中維護,一旦在其視圖中為兩個邏輯系統分配了消息類型或BAPI,即建立了兩個系統之間的連接
點擊“創建模型視圖”按鈕:
選擇剛創建的模型視頻,點擊“添加消息類型”按鈕(或者點擊“Add BAPI”以BAPI的方式實例ALE)
第五步在發送系統中創建伙伴參數(BD82)
伙伴參數(partner profile)是Idoc發送和接收過程中的基本連接設定。在ALE中,需要將另一方設為伙伴,定義類型為邏輯系統的伙伴參數,才可完成通信。
輸入BD82(或在BD64界面選中上一步所創建的模型視圖,則點擊菜單,這樣在下圖中就不用輸入模型視圖了),在下圖中輸入分布模型視圖(為上一步所創建的模型視圖)以及伙伴系統,伙伴系統應該ALE另一方的邏輯系統名,而不是當前系統:
選擇執行功能后,系統將自動生成邏輯伙伴、端口(自動分配)以及輸出參數。成功生成接收系統810伙伴參數后,日志界面:
第六步檢查發送端端口配置(WE21)
IDoc或其狀態記錄總是通過端口和外部系統進行傳遞的,是IDoc接口中系統通信相關的基礎配置,代表SAP系統和伙伴系統的通信途徑。對於每個外部系統都至少需要配置一個端口。在端口配置需指定目標系統
上一步中,從日志發現自動創建了A000000059的端口,並且使用的是前面我們創建RFC目標,可以使用WE21,展開事務性RFC,可以查看:
目標系統使用的是前面創建的RFC接連
6種端口類型,應用於不同的的IDoc傳輸實現方式:
第七步在發送端修改伙伴參數文件Partner Profile(WE20)
伙伴參數可以通過WE20手工設定,這里是自動生成的
在第五步之后,創建自動產生伙伴參數文件,通過事務代碼WE20,可以查看與修改剛創建好的伙伴參數。
每個在ALE過程中需要傳輸的消息類型都將添加到端口的出站參數中,本例中所需關注的是物料主數據對應的消息類型MATMAS(CREMAS為其他模型視圖所生成的):
雙擊 MATMAS消息,可以對其修改,將基本類型修改為MATMAS01:
第八步向目的端發布Distribution Model(BD64)
在發送系統800中維護了分布模型視圖並根據該視圖生成接收系統伙伴參數之后,還需在接收系統810中為發送系統維護伙伴參數,但目前接收系統中還不存在ALE分布模型視圖,因此不能夠自動創建伙伴參數。一個簡單的解決方法是:將相關的ALE分布模型視圖發布到接收系統中,然后就可以通過同樣的視圖在目標系統中自動生成發送系統的伙伴參數了,在800系統中,進入BD64界面,並選中MATMAS消息(否則有可能發布不了):
再登錄810查看:
第九步在目的端生成Partner profile(BD64)
登錄到810,T-code:BD64
選定傳輸過來的Distribution Model,點擊菜單Environment -> Generate Partner Profiles:
第十步檢查接收端端口號(WE21)
已經自動建立了端口,並且使用的是此前建立的目標連接
第十一步調整接收端Partner Profile(WE20)
選擇新創建的Partner Type:ZCLIENT800,雙擊Inbound下的MATMAS:
該界面中最重要的內容是處理代碼(即為進行具體IDoc處理的功能模塊或工作流的代號),數據在所指定的處理中被寫入IDoc或是從IDoc中讀取出
將其Process code改成MATM,保存。如果你不修改這個,默認情況下它自動選擇了以A打頭的Process code,而並非物料主數據需要的MATM處理碼:
一旦傳輸數據過來后,相應的處理模型不對應,會產生錯誤:
至此,整個IDoc發送與接收配置工作已經完成。
測試
第一步在發送方創建物料
上面紅框中需要輸入,否則接收端可能接收不了。
此時登錄到810用T-code:MM03來查找這個物料是不存在的。
第二步發送物料主數據(BD10)
輸入你要傳輸的物料主數據(一定要輸的,不然會當前client里的所有物料主數據發送到對端系統去),點執行這時再到810里用MM03就可以查看此物料了
第三步查看發送與接收的IDOC(BD87)
發送端:
接收端:
IDoc進階應用
數據過濾
第一步在發送端設定過濾(BD64)
登錄800,我們回到BD64,看到這個Distribution model下顯示的是No filter set,也就是說沒有設定過濾。雙擊No filter set
在新生成的Filter group中雙擊Material Type:
增加“成品”過濾條件,即只有物料類型為成品的物料才會被傳輸到目標系統:
最后確認並在BD64界面上保存
第二步在發送端重新分發Distribution model
選中過濾條件,依次點擊如圖菜單:
打開800檢查,可看到已發布成功:
第三步測試
我們先在800端創建兩個物料:zjzjmara2、zjzjmara3兩個物料,類型分別為成品與半成品
創建完物料后,開始傳輸測試:
它會生成2個IDoc:
但只有1個會被發送,證明我們的過濾器起作用了:
段及字段過濾
如果只更新某些字段,而不是所有數據時,上面所提到的Distribution model過濾器就無法勝任了。那么又如何解決此問題呢?答案就是通過消息類型來對段及字段進行過濾。
第一步創建自定義消息類型(BD53)
輸入此新類型從何處參照而來,這里輸的是MATMAS:
這時會出現基於MATMAS下的IDoc數據結構樹,其中綠色表示的是必須的字段,而紅色表示的是可選的字段。
雙擊E1MARAM。假如我只想每次更新毛重和凈重的值,而其它的值不修改目標系統的值,從彈出窗口列表我選擇了BRGEW和NTGEW:
請注意,先鈎先,再點擊“選擇”,最后點確認。點“選擇”后,變為綠色:
最后保存,保存之后,查看整體效果:
(消息類型創建完成並保存之后,消息類型名與描述會在WE81中顯示出來)
第二步創建物料及發送
T-code:MM01
在發送端800先創建一個新的物料,分別維護了毛重、凈重和容量的值:
T-code:BD10
然后,在810中可以看到這個物料的對應值都被傳送過來了:
第三步修改Partner profile(WE20)
選邏輯系統ZCLIENT810,在Outbound參數表中,將MATMAS刪除,並點添加按鈕:
最后結果:
第四步修改並分發Distribution model(BD64)
在發送端800中,刪除原來MATMAS消息:
保存后,重新分發一下Distribution model,目的是讓接收系統更新Distribution model:
模型修改后,需重新生成partner profile:
第五步修改目的端Partner profile
到接收端810端重新生成partner profile
選擇ZCLIEN800,選中Inbound的參數中的MATMAS消息類型,刪除它
然后點擊新增按鈕:
最后消息類型被替換成前面發送端創建新的消息類型了:
第六步測試
在800端,T-code:MM02
修改物料DEMO004,毛重改為400,凈重改為300,而容量改為10:
T-code:BD10
發送數據,信息類型選為新建的ZMATMAS_DEMO,執行
再到810,T-code:MM03,看到的值中,毛重和凈重已經改變而容量不變
數據轉換
也會有這樣的業務場景:當數據傳輸至目的端時,目的端的數值需要做一些轉換。
比如仍是這個DEMO004的物料,現在希望其凈重等於毛重,而容量是個常量值200:
第一步創建信息類型(BD53)
我現在需要把所有的字段都選擇進來,所以先點E1MARAM,再點頂上的Select:
然后雙擊E1MARAM,從彈出的窗口中點全選按鈕后,再點Select,最后確定:
要對所有的樹狀結構都做相同的操作,如果有子目錄,要展開,完成后保存。最后的結果如下:
第二步創建規則(BD62)
創建了自己的規則,針對的是E1MARAM段:
第三步修改規則(BD79)
凈重值設定為從毛重值處獲取,而容量值為固定的200:
第四步指派規則與消息類型的對應關系(BD55)
第五步修改Partner Profile(WE20)
Outbound參數中選定了新建的消息類型
第六步修改Distribution model(BD64)
替換消息類型,保存並分發
第七步在目的端生成Partner Profile(BD64)
第八步調整目的端Partner profile(WE20)
調整Process code:
調整Inbound的消息類型:
第九步測試
T-code:MM02
只保留了毛重的消息:
T-code:BD10
回到810端進行查看:
自動同步
到目前為止,我們演示的都是手工發送IDoc,但在很多業務場景下,許多數據是需要自動觸發來發送IDoc的,比如訂單之類的。如何解決呢?SAP提供了Change Pointer這個工具可以幫助我們輕松的搞定這個需求,下面就來演示如何進行操作。
第一步激活Change Pointer(BD61)
在Change pointers activated – generally前打上勾,保存即可
第二步激活消息類型的Change pointer(BD50)
我這個例子中會用到自己的消息類型:ZMATMAS_DEMO2,這個消息類型直接從MATMAS中拷貝而來,只傳送毛重、凈重和容量三個字段,不做其它操作。
T-code:BD53
T-code:BD50
默認情況下這個消息類型不會出現在列表中,你可以添加,然后在后面的復選框中打上勾
第三步指定消息類型觸發Change pointer的條件(BD52)
填入你所想要的對象、表名及字段名,這個示例演示的是當物料主數據中的毛重這個字段發生變化時,會觸發Change pointer並生成IDoc發送,保存。
第四步測試
T-code:MM02
將毛重從400改為600,保存
T-code:SE38
運行報表RBDMIDOC
再到目的端810查看,數據修改成功:
另一個實驗不再詳細截圖,即修改其它非毛重的值,再運行ABAP報表(只截了個運行報表時出現的報告,有0個數據產生),則此時目的端數據不會產生更改(因為IDoc沒有生成且傳送也沒有發生):
我們可以將這個ABAP程序安排成后台進程,定期運行,這樣就能自動發送設置好觸發條件的IDoc了,下面做了個截屏,是用SM36安排后台進程時所做的定義:
只要把這個任務安排成定期執行的后台進程,自動發送就變成可能
自定義IDoc發送與接收實例
idoc是基於sap自己的類似xml格式的文檔數據交換的方式。idoc基於文檔,可以實現異步的。
該實例使用800發送端向810接收端發送Idoc進行實驗
在發送端(outbound)中配置
以下步驟都是在Client 800進行設置
1、創建segment(WE31)
segment,類似於創建XML的節點及節點屬性,即定義XML文檔中的節點及節點屬性。
這里先輸入YPOHEAD,點擊創建,在接下來的屏幕中,錄入EBELN, BUKRS, BEDAT等字段及他們對應的data element:
接着創建YPOITEM,輸入EBELN, EBELP, MATNR, MENGE, MEINS等字段及他們對應的data element:
保存后用SE11查看你將發現,系統自動添加了YPOHEAD和YPOITEM兩個結構,每個字段都成了CHAR類型,長度就是WE31中的EXPORT LENG(輸出長度)。
2、創建IDOC Type(WE30)
創建IDOC Type,定義結點間的相互邏輯關系
先輸入YPOIDOC,然后點擊創建,緊跟着點擊create new進入:
在主界面中,先點擊創建按鈕,將YPOHEAD添加,設置Mandatory seg打勾,min = 1, max = 1,代表我們每個IDOC僅包含一張采購訂單:
然后在YPOHEAD下添加YPOITEM,同樣的Mandatory seg打勾,min = 1, max =99999:
3、創建Message Type(WE81)
先切換到編輯狀態,然后點擊New Entries,輸入YPO_MESS_TYPE即可。
4、關聯Message Type和IDOC Type(WE82)
5、創建接收端RFC Destination(SM59)
創建一個到接收端810的物理連接,由於是該實例是在同一個SAP系統內部進行實驗,所以“連接類型”選擇的是ABAP Connection連接,名為ZTO810:
6、創建到收端的端口(WE21)
注:這里講的端口不是單純的指定Socket端口號,而是指連接到RFC目標系統的統稱,包括IP、端口等信息,實質上是在SM59創建的物理連接基礎之上創建的另一種邏輯名而已
基於上面第5步創建的RFC Destionation,創建端口Port,類型選TRANSACTIONAL RFC,名為TO810PORT,RFC destination則填寫ZTO810:
7、創建發送端Logical System並分配(SALE)
為發送端800創建邏輯系統 Z800LS:
並將邏輯系統分配到發送端800:
注:這里不需在本端(Client 800)創建此邏輯系統的合作和伴配置文件,但需要在810配置
8、創建接收端Logical System(SALE)
為接收端810創建邏輯系統 Z810LS,這將在下一步創建到接收端的合作伙伴配置文件Partner profile(WE20)時用到:
但與上面創建發送端邏輯系統不一樣的是,在發送端系統800中是不需要將它分配給Client 810,但此分配操作需要在接收端810進行,這一分配操作請參考后面接收端(Inbound)配置章節
9、創建接收端合作和伴配置文件Partner profile(WE20)
合作和伴配置文件將Message Type消息類型、receiver port RFC目標端口、IDoc類型關聯起來
創建一個patner no為Z810LS的合作和伴配置文件,該配置文件描述了將IDoc發往何處:
上圖中合作伙伴編號填上一步創建的接收端邏輯系統,類型選擇LS。Ty.選擇是“用戶”類型,代理人為本系統(發送端800)中的用戶,如果在Idoc發送過程中出現什么問題,會向此用戶發送郵件,這里要注意的是:這不是目標系統(接收端810)中的用戶
當上面信息填好后,點擊保存(保存之后才可以對Outbound parmtrs進行設置)。
然后,點擊outbound下方的加號,創建一個outbound parameter。Message Type為YPO_MESS_TYPE,receiver port為TO810PORT,output mode選擇Transfer idoc immed.,Basic Type填寫YPOIDOC,保存即可:
10、通過Abap程序發送IDOC
程序的思路就是,把每個IDOC節點按字符串形式逐個添加,而字符串的添加次序自然也體現了IDOC節點間的邏輯關系。代碼如下:
DATA: ls_pohead TYPE ypohead,"IDoc數據段:頭
ls_poitem TYPE ypoitem,"IDoc數據段:Item
ls_edidc TYPE edidc,"IDoc的控制記錄
lt_edidc TYPE TABLE OF edidc,
lt_edidd TYPE TABLE OF edidd WITH HEADER LINE."IDoc的數據記錄
CLEAR ls_edidc.
*系統根據下面4行即可與WE20(合作和伴配置文件)設置關聯起來
ls_edidc-mestyp = 'YPO_MESS_TYPE'. "Message Type
ls_edidc-idoctp = 'YPOIDOC'. "IDOC Type
ls_edidc-rcvprn = 'Z810LS'. "partner Number of Recipient接收方合作伙伴
ls_edidc-rcvprt = 'LS'. "partner Type of Receiver接收方類型為邏輯系統
*添加IDOC節點
CLEAR lt_edidd.
lt_edidd-segnam = 'YPOHEAD'."頭節點
lt_edidd-dtint2 = 0.
CLEAR ls_pohead.
ls_pohead-ebeln = '4001122334'."采購單號
ls_pohead-bukrs = '1000'."公司代碼
ls_pohead-bedat = '20090630'."日期
lt_edidd-sdata = ls_pohead. "節點內容:ls_pohead結構中的數據最后被拼接成字符串再賦值給lt_edidd-sdata,最大長度不能超過1000
APPEND lt_edidd.
CLEAR lt_edidd.
lt_edidd-segnam = 'YPOITEM'."Item節點
lt_edidd-dtint2 = 0.
CLEAR ls_poitem.
ls_poitem-ebeln = '4001122334'."采購單號
ls_poitem-ebelp = '0001'."Item行號
ls_poitem-matnr = '000000000000004527'."物料號
ls_poitem-menge = '3'."數量
ls_poitem-meins = 'ST'."單位
lt_edidd-sdata = ls_poitem.
APPEND lt_edidd.
CLEAR lt_edidd.
lt_edidd-segnam = 'YPOITEM'."Item節點
lt_edidd-dtint2 = 0.
CLEAR ls_poitem.
ls_poitem-ebeln = '4001122334'."采購單號
ls_poitem-ebelp = '0002'."Item行號
ls_poitem-matnr = '000000000000009289'."物料號
ls_poitem-menge = '5'."數量
ls_poitem-meins = 'M'."單位
lt_edidd-sdata = ls_poitem.
APPEND lt_edidd.
CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'"發送IDoc
EXPORTING
master_idoc_control = ls_edidc "IDoc控制記錄
TABLES
communication_idoc_control = lt_edidc "接收:用來接收IDoc發送情況
master_idoc_data = lt_edidd "IDoc數據記錄
EXCEPTIONS"
error_in_idoc_control = 1
error_writing_idoc_status = 2
error_in_idoc_data = 3
sending_logical_system_unknown = 4
OTHERS = 5.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ELSE.
COMMIT WORK.
WRITE: 'Idoc sent:'.
LOOP AT lt_edidc INTO ls_edidc.
NEW-LINE.
WRITE: 'Idoc number is', ls_edidc-docnum,
'; receiver partner is', ls_edidc-rcvprn,
'; sender partner',ls_edidc-sndprn.
ENDLOOP.
ENDIF.
選中消息,並點擊“處理”按鈕后,該消息就會發往目的客戶端810,狀態從准備發送到成功發送:
發送的數據可以選擇數據記錄節點來查看:
以上都是在發送端800進行的,下面登錄到接收端810去看看IDoc接收情況:
由於在接收端810未配置到發送端800的合作伙伴配置文件,所以出錯。
下面章節在接收端810中進行發送端800的相關配置
在接收端(Inbound)中配置
以下步驟都是在Client 810進行設置
由於該實例是在同一服務器的同一實例中進行的,又由於Segment、IDoc Type、Message Type這些都是跨Client的,所以上面1、2、3、4步就不需要在810端再次配置了,這些是共享的(但如果不是在同一服務器上,則需要像上面那樣進行配置)
1、創建發送端RFC Destination(SM59)
創建一個到發送端810的物理連接
2、創建發送端的端口(WE21)
基於上面創建的RFC Destionation,創建端口Port,類型選TRANSACTIONAL RFC,名為FRM800PORT,RFC destination則填寫上面創建的RFC遠程目標ZFROM800:
3、將接收端Logical System分配到Client 810(SALE)
如果是在不同的服務器中,則這里需要像在發送端那樣:發送端邏輯系統Z800LS與接收端邏輯系統Z810LS都需要被創建,並且還需要將接收端邏輯系統Z810LS分配到Client 810,並且還需要以發送端邏輯系統Z800LS為基礎創建發送端合作伙伴配置文件
由於是在同一服務器的同一實例中,所以在發送端中創建的發送端邏輯系統Z800LS與接收端邏輯系統Z810LS在此端是通用共享,這里不需要再次創建(outbound中已經創建了這兩個邏輯系統了),但(outbound章節中並未分配到具體的Client)Z810LS邏輯系統沒有分配到相應的Client,這一步操作需要在接收端完成,所以需要在此進行分配:
4、創建入站處理函數
創建一個function:Y_IDOC_PO_PROCESS.
當IDOC設置完畢之后,SAP可以自動調用該Funtion Module處理IDOC,所以這個函數的參數接口是有規范的,可以從IDOC_INPUT_BBP_IV這些標准函數拷貝參數接口部分:
"ypohead\ypoitem實為上面定義的IDoc類型
DATA: ls_chead TYPE ypohead,
ls_citem TYPE ypoitem.
CLEAR idoc_contrl.
READ TABLE idoc_contrl INDEX 1.
IF idoc_contrl-mestyp <> 'YPO_MESS_TYPE'.
RAISE wrong_function_called.
ENDIF.
LOOP AT idoc_contrl.
LOOP AT idoc_data WHERE docnum = idoc_contrl-docnum.
CASE idoc_data-segnam.
WHEN 'YPOHEAD'.
"直接將字符賦值給結構,貶值過程中會按照結構中的字段長度來划分各字段
ls_chead = idoc_data-sdata.
WRITE: / 'Head',ls_chead.
WHEN 'YPOITEM'.
ls_citem = idoc_data-sdata.
WRITE: / 'Item',ls_citem.
WHEN OTHERS.
ENDCASE.
ENDLOOP.
"根據數據處理情況設置當前IDoc處理的狀態
IF 1 = 0.
CLEAR idoc_status.
idoc_status-docnum = idoc_contrl-docnum."當前正處理的IDoc
idoc_status-status = '53'. "IDOC處理成功
APPEND idoc_status.
ELSE.
CLEAR idoc_status.
idoc_status-docnum = idoc_contrl-docnum.
idoc_status-status = '51'. "IDOC不成功
idoc_status-msgty = 'E'. "錯誤信息
idoc_status-msgid = 'YMSG'.
idoc_status-msgno = '001'.
APPEND idoc_status.
ENDIF.
ENDLOOP.
ENDFUNCTION.
5、注冊入站處理函數(BD51)
填入函數名Y_IDOC_PO_PROCESS,Input Type=1
6、將入站函數與IDOC Type/Message Type關聯(WE57)
Function Module輸入Y_IDOC_PO_PROCESS,其下的Type填寫F;IDOC Type下的Basic Type填寫YPOIDOC;Message Type填寫YPO_MESS_TYPE;Direction填寫2(Inbound)
7、創建Inbound Process Code(WE42)
Process Code輸入YPC_PO,在Option ALE下選擇Processing with ALE service,在Processing Type下選擇function module:
保存后,在隨后的窗口中,輸入Inbound Module為Y_IDOC_PO_PROCESS。
8、創建發送端合作和伴配置文件Partner profile(WE20)
由於在發送端800中已創建了發送端邏輯系統Z800LS ,所以在此端不需要在創建(發送端邏輯系統Z800LS),只是需要以此為基礎創建和伴配置文件:
9、測試 BD87
在接收端810使用BD87,登錄進去后,會看到發送端發送過來的IDoc,但由於先前還沒有配置發送伙伴配置文件,所以失敗了:
現在在入站處理理函數中設置斷點:
再執行BD87事務,繼續處理出錯的消息,最后發現處理成功:
調試程序時,發現數據也傳遞過來了: