Information Technology

IDoc Template
SAP Development Architecture

Effective: Revised: Owner: IT Architect: Prepared By: Document Version:

Information Technology Document Revision History Date Version Author Change Description

143680243.doc

Page 1 of 41

Information Technology

Table Of Contents
Introduction to IDocs.............................................................................................................................................3 Structure of an IDoc..............................................................................................................................................3 GENERAL DEFINITION............................................................................................................................................4 1)CREATING A NEW IDOC...........................................................................................................................................5 OUTBOUND IDOC...................................................................................................................................................14 1)PROGRAMMING IN THE IDOC INTERFACE..............................................................................................................14 2)CONFIGURING THE SYSTEM FOR OUTBOUND IDOCS .............................................................................................17 3)TRANSPORTING THE IDOC TO THE RECEIVING SYSTEM.........................................................................................22 INBOUND IDOC........................................................................................................................................................23 1)PROGRAMMING IN THE IDOC INTERFACE..............................................................................................................23 2)CONFIGURING THE SYSTEM FOR INBOUND IDOCS.................................................................................................24 TESTING IDOCS.......................................................................................................................................................28 MONITORING IDOC................................................................................................................................................29 .......................................................................................................................................................................................33 APPENDIX A..............................................................................................................................................................34 APPENDIX B..............................................................................................................................................................36 APPENDIX C..............................................................................................................................................................37 REFERENCES............................................................................................................................................................39

143680243.doc

Page 2 of 41

Information Technology

Introduction to IDocs
The term IDoc stands for Intermediate document. It is simply a data container (like a text file) used to exchange information between any two processes systems, which can understand the semantics and syntaxstructure and content of the data. An IDoc is created as a result of an outbound ALE or EDI process; an IDoc serves as input to create an application document. For example, an IDoc is created when an order is placed and this IDoc can be used to create a purchase order. Idocs are stored in the database. Every IDoc has a unique number. They can be used for SAP to SAP and SAP to non-SAP communication as long as the participating processes can understand the structure and content of the data. IDoc types are independent of the direction of data exchange. An inbound and an outbound process can use the same IDoc type. Eg. ORDERS01 IDoc is used by the purchasing module to send a purchase order and it is also used by the Sales and Distribution module to accept a sales order. IDocs can be viewed in a text editor since the data is stored in character format. Structure of an IDoc. An IDoc structure consists of several segments. A and segments consists of several data fields. The IDoc structure defines the syntax of the data by specifying a list of permitted segments, the arrangement of the segments, mandatory versus optional segments. Segments define a set of fields and their formats. An IDoc is an instance of an IDoc type and consists of three types of records. One control record. Each IDoc has only one control record. The control record contains all the control information about an IDoc, including o IDoc number, o the sender and recipient information, o information such as message type it represents, o IDoc type, o present status.

The control record structure is the same for all IDoc types. The SAP defined structure is EDIDC and can be viewed using transaction SE11.
One or many data records. An IDoc can have multiple data records, as defined by the IDoc

structure. Segments translate into data records. Data records store the application data, such as purchase order header information and purchase order detail lines. The structure of a data record is defined in EDI_DD40 and the data records are found in EDID4.
One or many status records. Multiple status records are usually attached to an IDoc. Status records are attached to an IDoc throughout the process, as the IDoc achieves goes through different stagesdifferent milestones. A status code, date and time are assigned at every milestonestage. Transaction WE47 will give you a list of status codes and their definitions. Codes 01 through 49 are used for outbound IDocs and 50 onwards for inbound. The status records can are stored in EDIDS table.

Multiple messages per IDoc type. A message represents a specific type of document transmitted between two partners. Orders, order response, customer master are examples of messages. An IDoc type can be used to represent several message types (of course, the messages must be logically related). For example, the orders IDoc type

143680243.doc

Page 3 of 41

Information Technology (ORDERS05) is used for several messages, including orders (ORDERS), order response (ORDRSP), and order change (ORDCHG.).

General Definition
When creating a new IDoc, the following steps needs to be carried out in both the sending (ES1150) and receiving system (GDV200). There are six phases involved in the methodology to create an IDoc for any Outbound Process (With or without MC). 1) Analysis: Analyze the business requirements and compare them with what SAP Provides. 2) Preparation: Identify various parameters used in the process 3) Setup: Configure the EDI components and build the necessary Master Data. 4) Testing: test the setup phase. 5) Execution: Execute the process 6) Verification: Verify the results

Case Scenario:
Lets go through the whole process of creating a new IDoc. We will use a simple example where the system sends out a monthly report for each employees weekly hours. The report is divided in three parts: Header, Details and Summary. Here is an example of a Flat file and actual report Last Name (15) Week Number (1) Total Hours (3) Smith 1 30 2 30 3 4 30 50 140 First Name (15) Social Security (11) Date of Birth (8) Client Site (20) Employee Header (Occurs Once, Required) Work Description Weekly Details (40) (Multiple)

Hours Hourly Rate Worked (3) (3) Total Amount Summary (10) (Occurs once) 123-45-6789 Houston Brewery Network Computers Network Computers DSP Systems

John 40 40 50 60 6900

102668 Beer Testing High level consulting Programming EDI Programming

To accomplish this we will first: create a new IDoc (covers the first three phases above), second: Configure the IDoc (phase three), and last test, execute and verify. Here is also the break up of names that will be assigned to the different components COMPONENT Message Type 143680243.doc NAMING CONVENTION Z<Meaningful name> ACTUAL NAME
ZEMP_MNT_RPT

Page 4 of 41

Information Technology Idoc Type Segment Type Outbound Function Module Z <Message Type> 01 Z <Data structure> Z_IDOC_OUTPUT_<MT>
ZEMP_MNT_RPT01 Z1EMP_HD, Z1WK_DET, Z1CL_DET, Z1SUMRY Z_IDOC_OUTPUT_EMPMTHRPT

1) Creating a New IDoc

The following steps take you through a standard procedure whenever creating a New IDoc. Before going to this, it is important get the right standards. Naming Convention: Names assigned to an IDoc type should be meaningful. It should tell the user what that IDoc does. Maximum length allowed is 30 characters for release 4x. Here is a format for naming custom IDocs. Z <meaningful name> <version number> Custom IDoc type must start with Z and end with two numeric characters. This number denotes the version of the IDoc. In general the version number is incremented by one. Example, for our case we will assgin the name ZEMP_MNT_RPT01. For the next version, this IDoc will be ZEMP_MNT_RPT02. Naming Segments requires the following format Z1 <meaningful name> All custom segments begin with Z1 and all SAP Segments begin with E1 Design Guidelines: Develop an IDoc type for a function, not for a specific application. Example: ORDERS02 is designed for the order process and not specifically for the sales order entry application. Thus, this IDoc is used for several documents such as Purchase order, Sales order, Order response. You should follow a similar strategy when creating a new Basic IDoc type. Use industry standards whenever possible for your data elements. Consult EDI standards for the appropriate length and data types and ISO codes for fields such as measurement units and currencies. Organize the document to contain header, detail and summary information. Do NOT repeat a segment type in an IDoc Definition Use the parent-child relationship when you are going to permit several entries of the same type in one IDoc. Example: The following diagram shows processing one employee at a time. If you want to support multiple entries of employees then the second diagram shows how to set up the parent-child relationship ZEMP_MNT_RPT01 Z1EMP_HD Z1WK_DET Employee monthly report Employee header info Employee Weekly details

Z1CL_DET Client Details Z1SUMRY Monthly report summary

143680243.doc

Page 5 of 41

Information Technology Avoid having too many mandatory segments. Having extra mandatory segments reduces the reusability of the IDoc. Make sure that the segments are less than 1000 bytes. If they are bigger than 1000, try to split them. Combine IDoc segments that are functionally similar into one segment whenever possible. Create segments that can be used by other IDoc.

Formatting Guidelines Data fields in a segment can contain only alphanumeric values.

Data Types
CHAR CLNT CUKY DATS LANG NUMC TIMS

Description
Character String Client Currency Key, refrenced by CURR fields Date Field ( YYYYMMDD) stored as char(8) Language Key Character field with only digits Time Field (HHMMSS), stored as char(6)

Fields should be left aligned. Character fields are automatically left aligned, but number values when assigned to a character field are padded with spaces on the left. These spaces must be removed from the fields programmatically using the condense command. Data is not case sensitive. Negative values are indicated by a minus sign after the value. Therefore 123 is written as 123-. Numbers with fractional values use a period to represent the decimal point. Floating-point numbers also use a period to represent the decimal point. No formatting is used to separate values in the thousands. E.g 29,000.00 29000.00

Now that you have covered the basic requirement for creating a new IDoc, lets move on to the actual process. The following five steps will guide you to successfully creating a New IDoc. However, before moving ahead make sure you have created a Developing Class to store all your objects and save everything as LOCAL. (See Appendix A for creating a new developing class.) 1.1 Data Analysis Analyze the data that needs to be exchanged between two systems. It is suggested that you follow a top-down approach if you are stating at a business-document level and a bottom-up approach at the field level. Break the document (fields functionally related) into segments. Group these fields into segments groups and arrange them in an IDoc type. Identify any parent-child relationship. After this you are now ready to build your basic IDoc type. Analysis of our Case brings out the following: Report is divided into three parts: Header, Details and summary. Right away we know that we will need at least three segments. Header and summary will have only one entry whereas week details has multiple entries. The weekly details can further be divided into two. Week number, hours worked, hourly rate Client site, work description

143680243.doc

Page 6 of 41

Information Technology This is because an employee can work multiple times in the same client site but the reverse is not true. An employee can not work at multiple client sites at one time. Here is an IDoc type representation of the flat file structure.

143680243.doc

Page 7 of 41

Information Technology

ZEMP_MNT_RPT01 Z1EMP_HD (M, 1,1) Z1WK_DET (O, 1,99999) Z1CL_DET (O, 1, 1) Z1SUMRY (O, 1, 1)
M-Mandatory O-Optional Minimum Maximum

LANME FNAME (10) (10)

SSN (11)

DOB (8)

Z1EMP_HD Z1WK_DET Z1CL_DET Z1SUMRY

WEEKNO TOTHRS HRLYRT (1) (3) (3) CLSITE (20) TOTHOURS (3) WORKDESC (40) TOTAMNT (10)

IDoc Type

Segments

There will be four segments that we will have to create. The header is made Mandatory because a Monthly report will not make sense without the employees basic information and also allows the reusability of the IDoc if only the Employee information needs to be sent out. The arrangement of the segments shows that there is a parent-child relationship between Z1WK_DET and Z1CL_DET. This signifies that the child segment cannot exist without the parent and is commonly used for text segments. Only Z1WK_DET is assigned to a maximum of 99999 range. This shows that this data record will occur multiple times. And Z1CL_DET is assigned once because it is dependent of the weekly detail.

1.2 Create Data Elements In the previous step we analyzed our scenario and defined what needs to be created. In order to create segments we first need to make sure that all the required data elements exist. If SAP data elements do not match then we will need to create new ones. Only in rare situation a new elements needs to be created. Example: The Future Price field (ZKPRS) in the E1MBEWM segment uses data type CHAR 12 instead of ZKPRS. This is because ZKPRS is CURR (Currency) which is not allowed in a segment definition . (See 1.3 Create Segment for the formatting guidelines for segment) . 1. Go to transaction SE11. Enter the name for your data element, select the radio button for data type and click the command button for create.

143680243.doc

Page 8 of 41

Information Technology

2. Select the radio button for data element.

3. Enter a short text, either a domain or built in type and length. In the Field label give lengths and descriptions for your data type. Save.

143680243.doc

Page 9 of 41

Information Technology

1.3 Create Segment We are now ready to create the segments as all the required Data Elements are already created. But first check if there are any existing that we can use. In our case we will have to create four new segments. Follow these steps to successfully create a new segment. (Please consult the guidelines above before attempting to create a new segment). Technically, a segment is implemented in three physically separate pieces. Segment Type Segment Definition See above for naming convention Segment Documentation Steps to create a new segment

143680243.doc

Page 10 of 41

Information Technology

1.

Go to transaction WE31 (segment editor used to create or change a segment). Enter the name for your Segment Type (version independent) and click on the create button.

2.

Enter the Short text and the field with the appropriate Data Elements. Click on save and the system will automatically generate the Segment Definition (version dependent). It generally starts with Z2 and end with the version number.

3.

We will create the following four segments as above. Z1EMP_HD Z1WK_DET Z1CL_DET Z1SUMRY

1.4 Create Basic IDoc Type Once all the necessary segments are created, you are ready to create the IDoc type. Follow these steps to create a Basic IDoc Type

143680243.doc

Page 11 of 41

Information Technology 1. Execute the transaction WE30. Enter a meaningful name for the IDoc type. (Consult the guide above). Click on create and a window will pop up to enter the description. Select the Create new option, enter the description and hit enter.

2. On the next screen: highlight the IDoc type and click on the create icon. This will allow you to enter the segment type and definite its attributes. Choose the appropriate values and press Enter. The system will transfer the segment type to the IDoc Editor. To add the next segment, highlight the last segment added and click on either same level or parent/child relationship depending on your design.

143680243.doc

Page 12 of 41

Information Technology 3. Once all the segments have been added, cick on save. This is what the screen looks like once all the segments have been defined.

1.5 Release the Segment Type and Basic IDoc Type Once you are satisfied with your IDoc structure and Segment, you can release them formally to signify their completion. In order to release your IDoc Type, you will first have to release the individual segments and then the IDoc Type. Here are the steps for releasing Segments. 1. Go to transaction WE31. Enter the segment type you want to release. 2. Choose from the menu bar EDIT Set Release.

3. Once this is done the gray check box is now checked. Repeat this for all the segments.

143680243.doc

Page 13 of 41

Information Technology Similarly, release an IDoc type. 1. Go to transaction WE30. Enter the IDoc type you want to release. 2. Choose from the menu bar EDIT Set Release.

3. The system will prompt you to confirm the release of the IDoc type. Confirm this and now you will not be able to make any changes to the IDoc Type. NOTE: You can cancel the release and modify the IDoc or the segment provided that you are still in the originally SAP System where these were created. To cancel the release, go to the menu bar EDIT Cancel Release.

Outbound IDoc
There are two paths to create an Outbound IDoc 1. Using Message Control (MC): Message Control is basically used to generate and manage various outputs from an application. It also controls their timing and medium of exchange. In other word it is a Function module controlling the circumstances under which a document will be sent. Example: which document has to be sent of which type is the document when does the document have to be dispatched which means of output is to be used Advantage of using MC is that it allows you to encapsulate business rules without having to write ABAP/4 Programs. MC is commonly used in the SD and MM Modules. To Learn more about Message Controls see chapter 8 of ALE,EDI, & IDoc Technologies for SAP by Arvind Nagpal. 2. Direct Outbound Processing: Here, the outbound processing path must be selected for R/3 components which are not linked to the Message Control module. You can develop custom programs to select the IDoc data and pass it directly to the ALE/EDI layer.

1) Programming in the IDoc Interface

IDoc generation logic is carried out depending upon the use of a message control or not. For message control component, the IDoc generation logic must be placed in a function module. And for Direct processing you create a custom stand-alone report program. Message control is mostly used in the SD and MM module while FI, PP and HR do not use Message Control. Thus, to trigger the Outbound process for message control you need to create an interface for Function Module and without Message Control you will create a stand alone program. Prior to creating a FM, You must already have created a Developing Class and Function Group. This is required at the time of creating the FM, as this allocates the path for saving purposes.

143680243.doc

Page 14 of 41

Information Technology 1.1 Interface and Program Flow for Function Module. Interface: IMPORTING Parameters: The following parameters are passed to the FM by the message Control Components: CONTROL_RECORD_IN. This parameter is prefilled with information that is already known to the calling program. E.G: Sender system, receiving partner, IDoc type. OBJECT. This parameter is the NAST entry that contains the key of the document to be extracted. EXPORTING Parameters: the FM returns the following parameter to the calling program. CONTROL_RECORD_OUT: This parameter has all the information filled out like the message type, IDoc Type, direction and receiver. TABLES Parameters: Has the data records filled by the FM. Data records are filled according to the sequence defined in the IDoc type. EXCEPTIONS: conveys any problems Program Flow: 1. Generally, you will declare the IDoc type, Message Type and segments in the Data Declaration part. Also need to declare the object key from the NAST entry. 2. Select the data you require from the DB tables. 3. Build the Control records: IDoc type, message type, partner type and number, and direction for the IDoc transmission 4. Build the Data Records. Populate the internal table. Example: We are going to use FM Z_IDOC_OUTPUT_EMPMTHRPT 1. Go to transaction SE37. Enter the FM name above and click on Create. 2. Define the interface as above. Write the program logic as follows. This program is broken down in the following parts: Definitions: Define the segment name, IDoc Types and message type. Data Declaration: Declare a local internal table for Data records. e.g. fs_int_edidd like edidd Declare Local fields for all the segments. e.g. fs_emphd_data like Z1EMP_HD Declare Local variables for the calculated fields. e.g. total_hrs_mnth type I. The database tables used. e.g. zzempdet and zzempwkdet An internal table to hold all the weekly details application data. e.g. it_wkdet like sempwkdet occurs 0 with header line

Program Logic:

143680243.doc

Page 15 of 41

Information Technology Determine the objectkey from NAST entry and select data from the database using this as the criteria. Build the control record. Here you will define the following fields: Control_record_out-direct =1 (defines the direction of the Idoc. 1=outbound, 2=inbound) Control_record_out-mestype = <the message type defined above> Control_record_out-idoctp = < the IDoc type defined above > Control_record_out-rcvprt = LS Control_record_out-rcvprn = GDVCLNT200 Build data record. Here for every segment, you first fill the segment, then fill the administrative section of the Local internal table for data record and last append this into the main internal table defined in the FM interface. Repeat this for all the segments. Here is an example of one * fill the employee header information FS_EMPHD_DATA-LNAME = ZZEMPDET-LNAME. FS_EMPHD_DATA-FNAME = ZZEMPDET-FNAME. FS_EMPHD_DATA-SSN = ZZEMPDET-SSN. FS_EMPHD_DATA-DOB = ZZEMPDET-DOB. *fill the administrative section of the data record FS_INT_EDIDD-SEGNAM = C_HEADER_SEGMENT. FS_INT_EDIDD-SDATA = FS_EMPHD_DATA. *append the employee header data record to the IDoc data APPEND FS_INT_EDIDD TO INT_EDIDD. Once this is done. Save and check you work. If you are satisfied, then activate the FM by using the activate icon. 1.2 A stand-alone program to Generate IDocs. 1. Go to transaction SE38. Enter a name (See the Global ABAP Naming standards) for your program and click on the create button. Program name is this example is ZZRAEMPMTHRPT 2. Give your program a short description and make it an Executable Program and assign it in the Development class you have created for the IDoc. 3. The program logic usually contains the following: Provide a selection screen to allow a user to specify the various objects for which IDocs are to be generated. e.g:
*object key (Social Security Number) PARAMETERS: P_SSN LIKE ZZEMPDET-SSN.

Determine the key of the application document from the object specified above. Select application data from the database using the object key identified above. Populate control record information. Populate an internal table of type EDIDD with data records for the various segments. Call the ALE service layer (MASTER_IDOC_DISTRIBUTE) to create the IDocs in the database. Commit work. 4. Once this is done. Save and check you work. If you are satisfied, then activate the Program by using the activate icon.

143680243.doc

Page 16 of 41

Information Technology

2) Configuring the system for Outbound IDocs

After creating IDoc Type and the necessary programs, you need to configure the system to make these components known to the ALE/EDI interface layer. This settings are required only if you have created or changed Idocs or programs. 2.1 Steps for configuring an IDoc using Message Control. 1) Create a new Message Type i. Go to transaction WE81. Click on the Display/Change Icon ( ).

ii. Click on . iii. Enter name for the message type and give it a short description. Make sure the name is same as the one defined in your FM. Also see the naming convention above. Click save. 2) Link the IDoc type to the Message Type i. Go to transaction WE82. Click on the Display/Change Icon. ii. Click on New Entries. iii. Enter data and click save.

3) Create a new process code: Another name for a specific process, for example function module or workflow. IDocs are read or written in this process. i. Go to transaction WE41. Click on the Display/Change Icon. ii. Click on New Entries. iii. Enter data and click save.

143680243.doc

Page 17 of 41

Information Technology

For Steps 4 to 7, To create any of these please refer to the Celestica Global ALE Configuration Guide.
4) Check the Logical System. Go to the IMG Basis ALE Sending and Receiving System Logical System Define Logical system. Check to see if the logical system that you want to send your IDoc to is defined here. In our case it is GDV200

5) Check the RFC Destination. Go to transaction SM59 and see if a remote connection has been defined for the receiving system. Test the connection to see if you are able to connect remotely.

143680243.doc

Page 18 of 41

Information Technology 6) Check for port. A port defines the medium in which the data is exchanged between the two systems. At least one port must exist for each external system. To give you a better idea, here is how IDocs are sent to two subsystems via three ports.

To check the port definition for the receiving system, go to transaction WE21. In our case it is A0000005.

7) Create or change a partner profile A partner profile is created for every partner system that sends or receives IDoc. Partner Profile has four major components that need to be defined. Partner information Agent Outbound parameters Inbound parameters Here is a graphical presentation of dependencies and important fields of partner profiles.

143680243.doc

Page 19 of 41

Information Technology Usually on an existing Partner Profile, only the message type need to be defined in the outbound or the inbound parameters. The partner information and agents dont change unless you are creating a new Profile. For our example we are going to send the IDoc to the GDV system. Here are the steps for adding a message type to an existing partner profile. i. Go to transaction WE20 and get the profile for logical system GDV200.

ii. Click on the Icon for creating new outbound parameter . iii. On the following screen enter the Partner Function: specify the relationship (Logical System in our case) Message Type: ZEMP_MNT_RPT

Outbound option tag: Receiver Port: A000000003 (Xtricity) (need to define port if doesnt exist) Output mode : select transfer IDoc Immediately & Do not start subsystem IDoc Type: Basic Type: ZEMP_MNT_RPT01 Post Processing: Permitted Agent tag: Type: US (User) Agent: PPATEL (your SAP user ID) Lang: EN (English) iv. Click save.

143680243.doc

Page 20 of 41

Information Technology Congratulations! You have now completed the entire process of creating and configuring a new outbound IDoc. 2.2 Steps for configuring an IDoc using stand alone program. Configuring the IDoc in this process is the same as above except for Step 3. Instead of creating a Process code, we have to add the message to the Customer Distribution table. So follow all the same step as above except for creating process code and do this following step after. 1. Distribution model describes the ALE message flow between logical systems. It could be relationship between BAPIs or Message Types or a BAPI & Message Type. Follow these step to maintain relationships: i. Go to transaction BD64. ii. Look for a model view that corresponds to your requirement. If not then click on the create model view button. Enter a short description and technical name.

iii. Then click on Add message type. And the following window will pop up. Make the appropriate entries and click on save. Sender is the sending system (ES1150), and receiver is the receiving system (GDV200). Save the model.

143680243.doc

Page 21 of 41

Information Technology

iv. Go to Environment on the pull down menus and click on Generate partner profile. Enter the name of the model and click on execute.

(Note: The 2 snapshots above were taken during the execution of a different model, hence the values of model, message type and logical system are different)

3) Transporting the IDoc to the receiving system.

Now you have to transport all the new objects you have created in this system to the receiving system. You also have to do the configuration for the port, RFC Destination, and the Partner Profile. Follow the step as above for all this. Remember you may not have to do any configuration if it is already existing, as this is usually a one time process. The only thing different is the Partner Profile configuration. Here you will add your Message type in the inbound parameters.

143680243.doc

Page 22 of 41

Information Technology

Inbound IDoc
Inbound programs are also called Posting programs. They are designed to read IDoc data and post application documents. To create a new Inbound IDoc you will first need to follow the steps in the general definition above. (if you have created a new outbound IDoc in the sending system, the transport will take care of this step). There are two scenarios when programming for inbound Basic and Advanced. Each scenario is described in more details below.

1) Programming in the IDoc Interface

1.1 Basic Scenario: This is direct inbound processing via the ALE layer. It involves the following steps: 1. Creating a New Function Module Create a new Function module using the transaction SE37. The naming Convention to follow is same as outbound. Z_IDOC_INPUT_<Message Type> e.g.: Z_IDOC_INPUT_EMPMNTRPT. Interface for most of the Inbound FM is preset by SAP and is the same for any of the two scenario Import parameters
INPUT_METHOD MASS_PROCESSING BDWFAP_PAR-INPUTMETHD BDWFAP_PAR-MASS_PROC BDWFAP_PAR-RESULT BDWFAP_PAR-APPL_VAR BDWFAP_PAR-UPDATETASK BDWFAP_PAR-CALLTRANS

Describes how the function module is to be processed (example: in the background) Mass inbound processing? (flag) Set to 99999 if a workflow event is to be triggered for error handling Variable freely available from application for workflow Asynchronous update? (flag is not set in example) Transaction called? (flag is not set in example) IDoc control record IDoc data records IDoc status records for ALE IDoc assigned to workflow method parameters If several IDocs are to be processed in a certain sequence: this structure contains the necessary information

Export parameters
WORKFLOW_RESULT APPLICATION_VARIABLE IN_UPDATE_TASK CALL_TRANSACTION_DONE

Table
IDOC_CONTRL IDOC_DATA IDOC_STATUS RETURN_VARIABLES SERIALIZATION_INFO EDIDC EDIDD BDIDOCSTAT BDWFRETVAR BDI_SER

The function module should carry out the following steps: Check that the IDoc contains the correct message type (field Idoc_Contrl-Mestyp). If it does not, raise the exception Wrong_Function_Called with an appropriate message. Page 23 of 41

143680243.doc

Information Technology o When implementing an inbound function module for master data that can be "reduced" by customers, dont check the message type; check the basic IDoc type instead (field Idoc_Contrl-Idoctp) Initialize/refresh any global variables and/or tables.

Initialize/refresh any global variables and/or tables. The inbound function module can be called a number of times by the same process, so the global variables will not be empty the second time around. Convert the character data in table Idoc_Data to internal format in internal tables. See the example coding below to see how to do this. Special attention must be paid to fields containing: o o o o o o Units of measure (ISO code in IDoc) Currency codes (ISO code in IDoc) Country codes (ISO code in IDoc) Shipping instructions (ISO code in IDoc) Monetary amounts (conversion factor needed) Dates and times (see below)

Fields containing dates and times can lead to errors during inbound processing when the field in the IDoc is empty (i.e. blank): In ABAP, moving a blank character field into a date field leaves the date field blank, rather than initial (all zeros) i.e. the date field ends up containing an invalid value. Errors will occur in subsequent processing whenever the field is checked for an initial value "if DateField is initial..." To avoid this, clear the date field if the IDoc field is empty, as shown in the example code. Remember: the function module should not do a Commit Work. If you have the choice, dont update the database using Call Function "xxx" In Update Task - it is unnecessary for ALE inbound processing, and only increases database load. 1.2 Advanced Scenario Advanced scenario is basically an addition to the basic scenario that handles mass processing (multiple IDocs at the same time), serialization checks (sequence of the IDoc posted), advanced workflow programming (for raising application specific events) and enabling an existing transaction for ALE (when the same IDoc cant be posted twice even in the worse case scenario).

2) Configuring the system for Inbound IDocs

1. Maintaining the Attributes of a Function Module This step is to set the characteristics of the function module. Whether it is outbound or inbound. Go to transaction BD51. Click on New Entries and make an entry for your FM as individual input. Save.

143680243.doc

Page 24 of 41

Information Technology

2. Assigning a Function Module You can specify that the new function module may process the new basic type with a certain message. In addition, you assign an application object from the Business Object Repository (BOR) (such as employee) to the function module, which can transfer the application data from the IDoc to the application object. This step is the ALE registration for the function module. Go to transaction WE57 and click on New Entries. On the new window enter the following data.

143680243.doc

Page 25 of 41

Information Technology 3. Assigning a Process Code This enables the function module to be identified from the partner profiles defined in the IDoc Interface when an IDoc of the new message type is received. To do this, go to transaction WE42 (Inbound Process Code) and click on New Entries. Enter a process code and description and choose the Processing with ALE and Processing by function module options and save your entries. On the new window that pops up upon saving, enter your Function Module. This step is important for you to link your process code with your Function Module. Make entries and save.

Go back, via the back icon , to maintain the inbound process codes and choose the logical message navigation. In change mode choose New Entries.

Enter the message type (logical message) and the process code and save your entries. As a result, the value help (F4) in the partner profiles can display the possible process codes from the logical message, that is to say, the business view.

143680243.doc

Page 26 of 41

Information Technology 4. Defining a Partner (Direct Inbound Processing) In inbound processing, define the new process code for inbound processing and exception handling for the basic type. Here you will enter the message type in the inbound process in the Logical System that you are receiving the IDoc from. To do this go to WE20 and click on the Create inbound parameter Icon in the Inbound Parameter.

Make the entries as below and save.

This completes your entire process of configuring the Inbound IDoc. The next step is to test your IDoc.

143680243.doc

Page 27 of 41

Information Technology

Testing IDocs
The final step is to test your IDoc. 1. Go to transaction SE38 and execute your program in the sending system, ES1 client 150. 2. Enter the SSN number for the employee whose report you want to send, the message type and the targeted logical system. (These parameters are what you designed in your program. Some information like the message type and logical system can be hard coded.)

3. At the end of the program you will get the IDoc number corresponding to your request. 4. Now go to transaction SE16 in the receiving system. Check the contents of the tables and see if they have been updated.

143680243.doc

Page 28 of 41

Information Technology

Monitoring IDoc
Now that you have tested your IDoc, the next step is to monitor it. You can easily and effectively monitor inbound and outbound processing of IDocs using special reports and graphic displays.

Features
The following tools are available for passive monitoring: 1) IDoc Display This report generates a list of individual IDocs or, if you have restricted your selection to one IDoc using the available selection criteria, the report displays the relevant IDoc (for example, if you select only one IDoc number as a selection criterion). In addition to the selection criteria, which are also available in the other statistics programs (message, partner), you can select the following, more technical parameters: IDoc type (basic type or basic type with extension) Test option from the partner profiles (is the IDoc created and sent for test purposes only?) Current status Port (recipient and sender) EDI reference numbers (interchange file, message, EDI archive file card EDI selection). The individual IDoc is displayed as a tree structure. The initial node is the IDoc number. The control record, data and status records are displayed as subnodes. You can expand nodes and display individual records. To see your IDocs Now go to transaction WE02. And execute to get a list of all the IDoc processed. You will come to the following screen.

Double click on your IDoc. Example: 00000000000122003. You will now come to the following screen.

143680243.doc

Page 29 of 41

Information Technology The IDoc is divided into three parts: I. Control Records: The control record displays, for example, the "letter header" (sender and recipient), direction and IDoc type. Value in control record is stored in EDIDC table II. Data Record: In the case of the data records, the segment name , segment number and short text are displayed. Value in the data record is stored in EDID2/3/4 table (number signifies the release 3C, 3, 4 respectively. III. Status Record: displays the individual status values (status) with a short text. 53 is the status number that tells us that the IDoc has been posted successfully. Expanding these numbers will give you more details. This is quite helpful when an error has occurred during the IDoc processing. Example: Below, status number 60 shows : EDI: Syntax error in IDoc (segment cannot be identified) .

Double click on the message and you will get the following screen with more details.

Values in the status record are stored in EDIDS table.

143680243.doc

Page 30 of 41

Information Technology 2) IDoc List This report returns lists, if necessary in graphical format. The selection criteria are The time (IDoc creation or last status change) The message The partners or also the separate identification for the partner Technical parameters: IDoc number, IDoc type, current status, direction. The lists are displayed according to message type and status. You can display statistics for the time distribution of the IDocs with a specific status as a graphic. The time axis can be homogeneous (that is, the time progression is uniform) or IDoc-oriented (that is, only time intervals in which IDocs were created are selected). IDocs with an error status can be easily displayed via the status bar. Errors are shown in the IDoc list with the use of warning colors. The error message is displayed immediately as a short text and, if necessary, you can also call the long text to receive further information for troubleshooting. (The warning colors are assigned specific status groups in the standard system. All statuses in a specific status group have the same color. ) To get IDoc list go to transaction WE05.

143680243.doc

Page 31 of 41

Information Technology 3) IDoc Statistics The IDocs are sorted and represented graphically according to predefined status groups. The IDocs are grouped together according to their processing status for statistical purposes. The status groups shown in the table below are used here. Only those IDocs, which have undergone a status change within a defined period, are selected. Statistics status groups Outbound Generated Ready for dispatch Being transmitted (transferred to external (sub)system) Transmission successful (in target system) Completed in target system Error in IDoc interface Error in external system With deletion indicator To see the IDoc statistics, go to transaction WE07. Inbound Generated transferred to application transferred to dialog completed in application error in IDoc interface error in application with deletion indicator

143680243.doc

Page 32 of 41

Information Technology 4) IDoc Search There are two ways to search for your IDoc, in the Database or in the archive. Archiving IDocs is discussed in more details in the next section. Searching in the Database is done from Transaction WE09.

143680243.doc

Page 33 of 41

Information Technology

Appendix A
Creating a new development class.
1. Go to transaction SE80.

2. Choose Development Class from the drop down list. 3. Enter a name for the Development Class. (see Celestica ABAP naming Standards, V1). e.g ZIDOC_EG 4. Click on the Display Icon . 5. You will get a message as follows

6. Click on yes and make appropriate entries and save as local.

143680243.doc

Page 34 of 41

Information Technology

7. Then next step is to create a Function Group in this Development class. Now highlight the new Development class in the Left Window and right click on it. You will get menu options as below.

8.

Choose create function group.

9. Make appropriate entries on the new window that pops up and save.

143680243.doc

Page 35 of 41

Information Technology

APPENDIX B

IMPORTANT TABLES

EDIDC EDIDS EDID2/3/4 EDIMSG EDISDEF EDISEG EDISEGMENT RFCDES

Control Records Status Records Data Records (version 3c/3/4) Message Type and Assignment to IDoc IDoc Development: IDoc Segment definition IDoc Segment with assignment to Segment type IDoc Segments RFC Destinations.

143680243.doc

Page 36 of 41

Information Technology

APPENDIX C
IMPORTANT TRANSACTION CODES
Main Menus WEDI BALE SALE NACE IDoc Definition SE11 WE31 WE30 BD53 WE60 WE61 IDoc Monitoring WE02 WE05 WE07 Main menu for EDI-related activities Main menu for ALE-related activities. Main menu for ALE configuration. Main menu for Message Control configuration Data Dictionary Segment Editor IDoc editor to create and extend IDoc type Reduce IDoc for master data IDoc documentation (IDoc structure and segment definition) IDoc Documentation (control record, data record, and status records) IDoc Display IDoc Lists IDoc Statistics

Configuration (Basic Infrastructure for ALE & EDI) WE20 Maintain partner profile manually BD82 Generate partner profiles automatically WE21 Port Definition SM59 RFC Destination BD64 Maintain customer model BD71 Distribute customer model Testing WE19 WE12 WE16 WE17 Reprocessing IDocs BD88 BD87 Test tool for IDocs Convert an outbound to inbound IDoc. Process an incoming IDoc file Process an incoming status file Process outbound IDocs Process inbound IDocs

Configuration of New IDoc Components WE81 Create new message type WE82 Link IDoc type and message type WE41 Create outbound process code WE42 Create inbound process code WE57 Allocate inbound function module to message 143680243.doc Page 37 of 41

Information Technology type Define settings for inbound function module Assign input methods for a process code (inbound)

BD51 BD67

143680243.doc

Page 38 of 41

Information Technology

REFERENCES

1. ALE,EDI, & IDoc Technologies for SAP by Arvind Nagpal 2. SAP Online Documentation Release 4.6C (CD) by SAP

143680243.doc

Page 39 of 41