這份文檔主要是自己學習IDOC的一些練習過程及心得,可能講的不全面,但應該可以幫助大家了解IDOC的一些工作方式.
IDOC或者說是ALE,事實上,是SAP用於分布和集成數據的一種方式.所以,我個人就將這個東西理解為數據的發出和數據的接收處理.事實上,也就是ALE中的出站(outbound)和入站(inbound).然后,我們從ALE的出站開始說起.說明如何從頭開始自己配置一個消息段,並將這個消息發出.
出站在實際應用中,是當我們的一項業務數據生成后,系統自動將該數據內容發出給指定的系統的過程.那么,在這中間,我們將該部分內容分為兩步,一步是我們先調用函數將自己的數據發出,第二步,我們在說明如何使用系統的功能將一些數據發送出去.
在IDOC出站過程中,需要我們確定2個要素,一個是發給誰,還有一個是數據的內容.那么,SAP對於這兩點,分別是通過設置伙伴參數文件(partner profile)來確定信息接收對象,配置消息類型(Message Type)來確定發送的數據的數據格式.
我們先從配置消息類型開始.消息類型由一個或者數個信息段組成.配置過程為:
- 創建一個信息段 ,事務碼 WE31.該步驟的作用為創建我們需要傳輸的數據結構
- 創建一個基本憑證類型,事務碼WE30
在一個基本憑證類型下,可以掛多個段,用於保存多種不同類型的數據.
- 通過WE81創建一個邏輯消息類型,並使用WE82將創建的邏輯消息類型與憑證類型之間的關聯.
到這步為止,我們已經完成消息類型的創建.
下一步,我們需要確定發送目標.ALE的目標地址(合作伙伴)分為銀行,利益提供者,客戶,供應商,邏輯系統和客戶幾類,具體應用要看實際情況而定.當前,我們測試使用邏輯系統作為合作伙伴.
類型為邏輯系統的合作伙伴有消息類型和接收端口兩個主要數據
接收端口根據類型又分為事務性RFC,文件,CPI-C,Internet,ABAP-PI,XML等幾個類型
其中,文件和XML這兩種類型是通過文件方式傳輸的,因此,只需要配置文件存放目錄,不需要配置RFC目的地,其它幾種類型,均需要配置RFC目的地.
端口的作用,我們可以看作一種管道的作用,在ALE的發送過程中,只需要將數據從端口的這端放入,至於另外一端去了哪里,我們可以通過端口的配置進行靈活的動作.那當前測試過程中,我們使用事務性RFC作為端口類型.
事務性RFC的端口類型,與其對接的就是另一個SAP系統或者同一SAP的相同或者不同的集團.
下面開始配置步驟:
- 配置一個RFC目的地 事務碼 sm59,我測試中,需要將idoc 傳到同一服務器中,因此,選擇ABAP connections.
在target host中填寫目標服務器名稱,在登錄信息中,填寫相應的登錄信息即可.保存后,點擊connection test ,如果成功,表示該目標設置成功.
- 設置端口,事務碼we21
在創建時,我們可以選擇系統自動給號,也可以選擇自己編寫端口名稱.我們選擇自己命名端口名稱
在出現的頁面中,只需要填寫描述和rfc 目的地即可.
- 設置伙伴參數 ,事務碼we20
在設置伙伴參數前,需要先為目標對象定義一個邏輯系統名,路徑如下
在其中,我們增加一條記錄
定義完成后,我們使用we20進入如下界面
我們選擇邏輯系統(LS),
然后,在outbound paramtrs 中,增加一個參數,
保存后,我們在發送端的所有工作完成,這表示我們可以通過我們的配置,使用程序創建一條idoc.以下是程序.
REPORT ZTEST_IDOC .
DATA: BEGIN OF F_IDOC_HEADER.
INCLUDE STRUCTURE EDIDC.
DATA: END OF F_IDOC_HEADER.
DATA: BEGIN OF T_IDOC_DATA OCCURS 10.
INCLUDE STRUCTURE EDIDD.
DATA: END OF T_IDOC_DATA.
DATA: BEGIN OF T_IDOC_COMM_CONTROL OCCURS 10.
INCLUDE STRUCTURE EDIDC.
DATA: END OF T_IDOC_COMM_CONTROL.
start-of-selection.
F_IDOC_HEADER-MESTYP = 'ZBOBO'.
F_IDOC_HEADER-IDOCTP = 'ZBOBO'.
F_IDOC_HEADER-RCVPRN = 'IDOC800R'.
F_IDOC_HEADER-RCVPRT = 'LS'.
T_IDOC_DATA-SEGNAM = 'Z1BOBO'.
T_IDOC_DATA-SDATA = 'ABCD'.
“在sdata中賦值中需要注意的是,如果在這個段中,存在超過一個的字段,則需要將所有字段按照固定長度串在一起賦值.
APPEND T_IDOC_DATA.
CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'
EXPORTING
MASTER_IDOC_CONTROL = F_IDOC_HEADER
TABLES
COMMUNICATION_IDOC_CONTROL = T_IDOC_COMM_CONTROL
MASTER_IDOC_DATA = T_IDOC_DATA
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.
COMMIT WORK.
ENDIF.
執行該程序后,使用we02應該就可以看到一條成功的出站信息.
同時，由於IDOC800R指向的是本集團，因此，我們還能看到一條錯誤的入站信息。如下圖最后兩條
至此，出站部分已經測試完成。我們可以看到，事實上，IDOC的出站方式很簡單，即通過函數MASTER_IDOC_DISTRIBUTE ，將對應消息類型發送到指定的目的地，根據該目的地所對應的端口，找到實際的目標地址。
入站的相關處理
入站，其實就是SAP系統接收到相應的IDOC后，進行的一系列操作。那么，系統進行操作的步驟為：
首先，根據合作伙伴編號，確定消息來源，在上圖中，我們雙擊最后一條記錄，即可看到入站idoc的詳細資料，如下圖
我們從上圖可以發現，合作伙伴編號為T90CLNT090 ,這里，我們需要解釋一下，為什么我們在發送端沒有進行任何關於T90CLNT090 的設置，就會出現該伙伴編號。這是因為T90CLNT090這個編號是當前集團的邏輯系統號，我們可以通過事務碼SCC4查看得到。同時，如果我們如果希望接收方出現的伙伴編號不是默認的集團邏輯系統號，我們可以在發送函數設置中，設置
F_IDOC_HEADER-SNDPRN = 'XXXXXXXX' .
F_IDOC_HEADER-SNDPRT = 'XX'.
即可。SNDPRN 是發送方的合作伙伴編號，SNDPRT是合作伙伴類型。
在得到合作伙伴編號后，系統會根據該合作伙伴編號所對應的入站消息類型與當前IDOC的消息類型進行匹配。
如圖，系統發現T90CLNT090可以處理兩種入站類型，分別為ORDERS和ZBOBO。當前IDOC的消息類型為ZBOBO,則我們進入ZBOBO,雙擊ZBOBO所在行
我們可以發現，在該消息類型中，系統只配置了執行代碼。事實上，系統找到該消息類型后，執行對應的執行代碼來處理該IDOC。執行完畢后，該IDOC的入站操作即結束。
然后，我們開始講解如何進行入站的相關配置。入站的配置分為三部分，一是合作伙伴的確定，二是消息類型，三是執行代碼。
其中，消息類型的處理與出站的配置方法相同，而且，由於本測試是同一集團完成，就不再重復說明。
我們先來說明執行代碼的處理。
1． 創建處理函數。
首先，我們需要創建一個函數，用於處理對應的IDOC信息，該函數的參數必須與系統完全一致，見下圖列表
函數名沒所謂。
FUNCTION ZCHN_BOBO_IDOC_IN.
*"----------------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" REFERENCE(INPUT_METHOD) TYPE BDWFAP_PAR-INPUTMETHD
*" REFERENCE(MASS_PROCESSING) TYPE BDWFAP_PAR-MASS_PROC
*" REFERENCE(NO_APPLICATION_LOG) TYPE SY-DATAR OPTIONAL
*" REFERENCE(MASSSAVEINFOS) TYPE MASSSAVINF OPTIONAL
*" EXPORTING
*" REFERENCE(WORKFLOW_RESULT) TYPE BDWF_PARAM-RESULT
*" REFERENCE(APPLICATION_VARIABLE) TYPE BDWF_PARAM-APPL_VAR
*" REFERENCE(IN_UPDATE_TASK) TYPE BDWFAP_PAR-UPDATETASK
*" REFERENCE(CALL_TRANSACTION_DONE) TYPE BDWFAP_PAR-CALLTRANS
*" TABLES
*" IDOC_CONTRL STRUCTURE EDIDC
*" IDOC_DATA STRUCTURE EDIDD
*" IDOC_STATUS STRUCTURE BDIDOCSTAT
*" RETURN_VARIABLES STRUCTURE BDWFRETVAR
*" SERIALIZATION_INFO STRUCTURE BDI_SER
*"----------------------------------------------------------------------
*tables : ZBOBO1 .
*data : s_zbobo1 type zbobo1 ,
* t_zbobo1 type zbobo1 occurs 0 with header line .
*
*delete from zbobo1 .
*loop at IDOC_DATA .
* s_zbobo1-matnr = 'material' .
* s_zbobo1-cputm = sy-UZEIT .
* append s_zbobo1 to t_zbobo1 .
** insert into zbobo1 values zbobo1 .
*endloop .
*
*s_zbobo1-matnr = 'last' .
*s_zbobo1-werks = '0100' .
*s_zbobo1-cputm = sy-uzeit .
*append s_zbobo1 to t_zbobo1 .
*
**insert into zbobo1 values zbobo1 .
*loop at idoc_contrl .
* s_zbobo1-matnr = idoc_contrl-DOCNUM .
* append s_zbobo1 to t_zbobo1 .
*endloop .
*insert zbobo1 from table t_zbobo1 .
*commit work .
loop at idoc_contrl .
clear IDOC_STATUS .
IDOC_STATUS-DOCNUM = idoc_contrl-DOCNUM .
idoc_status-STATUS = '53' .
* MESSAGE S010(UPS) WITH is_apihdr-upsnam
* INTO text.
IDOC_STATUS-MSGTY = 'S'.
IDOC_STATUS-MSGID = 'UPS'.
IDOC_STATUS-MSGNO = '010'.
* wa_status-MSGV1 = sy-msgv1.
append idoc_status .
endloop .
ENDFUNCTION.
該函數的作用，只是將入站的IDOC的狀態設置為處理完成。如果你有興趣，也可以設置些表，將一些信息寫入表中。
2． 將函數與消息類型進行關聯，事務碼WE57
該步驟的作用為向系統顯式的表明，該函數可以處理哪些類型的消息類型
3． 設置入站函數特性。事務碼BD51
老實說，該步驟的作用我也不是很理解，只不過參考文檔上寫了，我就照做，回頭試下，不用的話，會有什么效果。
4． 定義執行代碼 ，事務碼 WE42
終於到了要緊的一步，該步驟的作用為將該函數設置為一個執行代碼，供入站時進行配置
在配置完后，這個地方似乎還可以配置該執行代碼可以兼容的消息類型，不理解這個地方的消息類型與函數配置的地方沖突的話會怎么處理。
到此，執行代碼定義完成。我們接下來定義伙伴信息。
伙伴信息的定義方式與出站類似，只是出站的伙伴信息的消息類型配置在出站列表中，入站配置在入站列表中，如下圖
該合作伙伴可以處理兩種消息類型。具體到內部，如ZBOBO，
我們可以看到該消息類型所對應的執行代碼。
定義完全后，我們使用bd87,在入站錯誤列表中選中一條錯誤信息
然后點擊執行。我們可以發現，該信息被成功處理。
到這里，我們手動創建IDOC，然后發送，接收，並使用自己的函數進行處理就做完了。由於我們是使用同一client進行測試，因此，沒有安全信息問題，如果測試的是在不同的client或者服務器上，在接收方需要使用事務碼BD64進行發布，具體的大家自己看下應該就了解了。
做完測試后，我們會考慮到另外一個問題，就是貌似IDOC其實也沒什么特別的功能，跟遠程call rfc函數區別不大。我個人感覺也是類似，只是IDOC在配置上增加了很多的內容，包括錯誤處理，包括不同的目的地（比如支持文件，http等），還有，就是系統對IDOC有很多封裝好的執行代碼和消息類型，這些東西，如果我們自己寫，就會很花時間，但如果直接調用系統的功能，就很方便了。
我們下面進行一個配置，功能是在采購訂單創建時，自動生成一條IDOC並發出。
整個的執行邏輯是這樣，我們首先需要為采購訂單定義一個Message ，這個MESSAGE與IDOC的消息類型沒有聯系，就是在采購訂單創建時，我們點擊消息按鈕，在里邊的消息
如上圖中的ZNEU .
然后，在消息的執行代碼中，寫入我們發送IDOC的代碼，在訂單保存時，該IDOC就會被創建並發送。(事實邏輯跟我們做自動打印差不多)
配置步驟如下：
1．創建一個消息，路徑為SPRO->Material Management->Purchasing->Message->Output Control->Message Types->Define Message Types For Purchase Order
我們復制一個標准信息類型NEU，定義為ZNEU
我們選擇ZNEU,點擊左邊的Processing Routines，我們可以看到該信息類型針對不同業務類型時的執行程序，我們需要使用的是EDI類型。我們發現，針對EDI類型時，系統會調用程序RSNASTED中的子程序EDI_PROCESSING。這個是系統默認的IDOC的生成程序，如果我們需要自己創建IDOC，則可以編寫自己的程序將其替換，或者使用其本身默認程序。
相同的菜單，選擇Fine-Tuned Control: Purchase Order
將ZNEU加入其中
2.將該消息類型分配給消息確認過程，路徑為
SPRO->Material Management->Purchasing->Message->Output Control->Message Determination Schemas->Define Message Schema for Purchase Order
先選擇Maintain Message Determination Schema: Purchase Order
我們從RMBEF1 拷貝到RMBEF3，在control data中將zneu加入
保存后，在Assign Schema to Purchase Order步驟中，將其分配給采購訂單，如下圖
到這步，我們已經將配置工作完成，
然后，我們到前台，將該消息類型分配給不同的采購訂單類型。
事務碼 MN05
我們將該消息類型分配給采購訂單類型NB，同時，確定該消息類型為EDI（6）,輸出時間為馬上輸出（4）
然后，我們需要將供應商創建為一個合作伙伴(WE20)
設置出站消息類型為ORDERS。
設置完畢后。我們創建一條與該供應商相關的采購訂單，保存前，我們點擊MESSAGE，我們可以看到ZNEU在列表中出現
保存后，使用we02,應該可以看到一條成功的出站信息和一條錯誤的入站信息，入站信息錯誤，是因為我們沒有針對該消息類型進行入站配置。
到這兒，我們可以大致了解到一些使用系統標准IDOC的方法。因為很多標准功能（如采購訂單，銷售訂單等），都提供了消息處理機制。我們需要做的，就是通過該消息處理機制，將我們需要的消息類型配置上去，使系統自動帶出該消息，並在訂單保存時執行該消息對應的代碼。