IDocs are SAP’s file format to exchange data with a foreign system. IDocs are an ASCII file format to exchange data between computers; the format is chosen arbitrarily . IDocs are similar to segmented files; they are not a description language like ANSI X.12, EDIFACT or XML.
The IDoc contents are processed by function modules, which can be assigned in customizing. IDocs are structured ASCII files (or a virtual equivalent). They are the file format used by SAP R/3 to exchange data with foreign systems. IDocs are simple ASCII data streams. When they are stored to a disk file, the IDocs are simple flat files with lines of text, where the lines are structured into data fields. The typical structured file has records, each record starting with a leading string that identifies the record type. Their specification is stored in the data dictionary.
IDocs is the acronym for Interchange Document. This indicates a set of (electronic) information which builds a logical entity. An IDoc is e.g. all the data of a single customer in your customer master data file, or the IDoc is all the data of a single invoice.
IDoc data is usually exchanged between systems and partners that are completely independent. Therefore, the data should be transmitted in a format that can easily be corrected by the computer operators. It is therefore mandatory to post the data in a human readable form.
Nowadays, this means that data is coded in ASCII format, including numbers which are sent as a string of figures 0 to 9. Such data can easily be read with any text editor on any computer, be it a PC, Macintosh, UNIX System, S/390 or any internet browser.
The information which is exchanged by IDocs is called a message and the IDoc is the physical representation of such a message. The name “messages” for the information sent via IDocs is used in the same ways as other EDI standards.
International standards like the ODETTE or VDA formats are designed in the same way as IDocs are. Other EDI standards like XML, ANSI X.12 or EDIFACT/UN are based on a data description language. They differ principally from the IDocs concept, because they use a programming language syntax (e.g. like Postscript or HTML) to embed the DATA.
The IDoc process is a straight forward communication scenario. A communication is requested, then data is retrieved, wrapped and sent to the destination in a predefined format and envelope.
An R/3 application creates data and updates the database appropriately. An application can be a transaction, a stand-alone ABAP Report or any tool that can update a database within R/3. If the application thinks that data needs to be distributed to a foreign system, it triggers the IDoc mechanism, usually by leaving a descriptive message record in the message table NAST.
The application then either directly calls the IDoc engine or a collector job eventually picks up all due IDoc messages and determines what to do with them. If the engine believes that data is ready to be sent to a partner system, then it determines the function module which can collect and wrap the required IDoc data into an IDoc.
In IDoc customising, you specify the name of the function module to use. This can either be one which is predefined by R/3 standard or a user-written one. When the IDoc is created it is stored in an R/3 table and from there it is sent to the foreign system. If the foreign system requires a special conversion, e.g. to XML, EDIFACT or X.12 then this job needs to be done by an external converter, like the Seeburger ELKE system. These converters are not part of R/3.
If you have to decide on a converter solution, we strongly recommend using a plain PC based solution. Conversion usually requires a lot of fine tuning which stands and falls with the quality of the provided tools.
The first record in an IDoc is a control record describing the content of the data All but the first record are data records with the same formal record structure Every record is tagged with the segment type and followed by the segment data. The interpretation of the segment is done by the IDoc application Both sent and received IDocs are logged in R/3 tables for further reference and archiving purposes.
RELATED POSTS
IDOC'S INBOUND PROCESS
IDOC'S BASIC TOOLS 2
IDOC'S BASIC TOOLS
The IDoc contents are processed by function modules, which can be assigned in customizing. IDocs are structured ASCII files (or a virtual equivalent). They are the file format used by SAP R/3 to exchange data with foreign systems. IDocs are simple ASCII data streams. When they are stored to a disk file, the IDocs are simple flat files with lines of text, where the lines are structured into data fields. The typical structured file has records, each record starting with a leading string that identifies the record type. Their specification is stored in the data dictionary.
IDocs is the acronym for Interchange Document. This indicates a set of (electronic) information which builds a logical entity. An IDoc is e.g. all the data of a single customer in your customer master data file, or the IDoc is all the data of a single invoice.
IDoc data is usually exchanged between systems and partners that are completely independent. Therefore, the data should be transmitted in a format that can easily be corrected by the computer operators. It is therefore mandatory to post the data in a human readable form.
Nowadays, this means that data is coded in ASCII format, including numbers which are sent as a string of figures 0 to 9. Such data can easily be read with any text editor on any computer, be it a PC, Macintosh, UNIX System, S/390 or any internet browser.
The information which is exchanged by IDocs is called a message and the IDoc is the physical representation of such a message. The name “messages” for the information sent via IDocs is used in the same ways as other EDI standards.
International standards like the ODETTE or VDA formats are designed in the same way as IDocs are. Other EDI standards like XML, ANSI X.12 or EDIFACT/UN are based on a data description language. They differ principally from the IDocs concept, because they use a programming language syntax (e.g. like Postscript or HTML) to embed the DATA.
The IDoc process is a straight forward communication scenario. A communication is requested, then data is retrieved, wrapped and sent to the destination in a predefined format and envelope.
An R/3 application creates data and updates the database appropriately. An application can be a transaction, a stand-alone ABAP Report or any tool that can update a database within R/3. If the application thinks that data needs to be distributed to a foreign system, it triggers the IDoc mechanism, usually by leaving a descriptive message record in the message table NAST.
The application then either directly calls the IDoc engine or a collector job eventually picks up all due IDoc messages and determines what to do with them. If the engine believes that data is ready to be sent to a partner system, then it determines the function module which can collect and wrap the required IDoc data into an IDoc.
In IDoc customising, you specify the name of the function module to use. This can either be one which is predefined by R/3 standard or a user-written one. When the IDoc is created it is stored in an R/3 table and from there it is sent to the foreign system. If the foreign system requires a special conversion, e.g. to XML, EDIFACT or X.12 then this job needs to be done by an external converter, like the Seeburger ELKE system. These converters are not part of R/3.
If you have to decide on a converter solution, we strongly recommend using a plain PC based solution. Conversion usually requires a lot of fine tuning which stands and falls with the quality of the provided tools.
The first record in an IDoc is a control record describing the content of the data All but the first record are data records with the same formal record structure Every record is tagged with the segment type and followed by the segment data. The interpretation of the segment is done by the IDoc application Both sent and received IDocs are logged in R/3 tables for further reference and archiving purposes.
RELATED POSTS
IDOC'S INBOUND PROCESS
IDOC'S BASIC TOOLS 2
IDOC'S BASIC TOOLS
No comments :
Post a Comment