这份文档主要是自己学习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的方法。因为很多标准功能（如采购订单，销售订单等），都提供了消息处理机制。我们需要做的，就是通过该消息处理机制，将我们需要的消息类型配置上去，使系统自动带出该消息，并在订单保存时执行该消息对应的代码。