SAPs presence in the IT world is justified by a central premise: It turns a companys many individual systems into one, big

supersystem. More than a linking together of applications, SAPs implementation causes a redirection of the flow of information through a company and its partner companies that enhances the potential of its business functions. This flow of information is enabled by a core element in SAP technology: the Intermediate Document, or IDoc. Technically, the IDoc is an example of Electronic Data Interchange (EDI). Unlike conventional EDI, IDocs are not based on a descriptive language. The IDoc concept borrows the best features of EDI and combines them with the best features of conventional transaction file formats. The result is a lean data transport mechanism that is the engine of SAP data flow, tying together applications, databases, companies, and networks. Here is a look at the makeup of IDocs within the application architecture. Form and content: IDoc terminology As is often the case with proprietary technologies, SAP assigns specific, object-oriented meanings to familiar terms. When referring to IDocs, the term document refers to a set of data comprising a functional group of records with a business identity. (For example, all the data in a purchase order, or all the profile information of a supplier in a supplier master record.) A message refers to the contents of a specific implementation of an IDoc; its a logical reference. This differs from a reference to the IDoc itself, which specifies the messages physical representation. Think of it this way: If youre watching a parade pass by, the mayor waving to the crowd from his limousine is the message, and the mayors limousine (which is specific to the mayor) is the IDoc. Youre building a logical object, and the IDoc is both its container and the vehicle that moves it. The IDoc control record Each IDoc has a single control record, always the first record in the set. The structure of this record describes the content of the data records that will follow and provides administrative information, such as the IDocs functional category (Message Type/IDoc Type), as well as its origin (Sender) and destination (Receiver) as in conventional EDI (see Figure A). Figure A
IDOC number 1234567890 Sender R3NYC Receiver R3LA Port FILE Message type INVOICES IDoc type INVOICE01

Layout of an IDoc control record This cover slip format informs the receiving system of the IDocs purpose, and the receiving system uses it to determine the correct processing algorithm for handling the arriving IDoc. Data records The data records following the control record are structured alike, including two sections: asegment information section and a data section. In the first part of a data record, the segment information section describes the structure of the

data that follows, for the benefit of the IDoc processor. There is a segment name (like an EDI segment identifier) that corresponds to a data dictionary structure to which the IDoc processor has access. The remaining information is useful for foreign systems, such as a partner companys Oracle system, which has no such data dictionary. The second part of the record is the data itself, a storage area of 1,000 characters. Status records If youve ever ordered a package from a faraway location and tracked its progress using the Internet-based tracking utilities now provided by most major parcel carriers, youre familiar with the list of stops and transfer points through which a package passes on its way to you. This collection of records is exactly what youll see in an IDoc that has begun its work. Following the data records in an IDoc, status records accumulate as an IDoc makes its way from one point in a process to another. Typically, an IDoc will acquire several of these records as its does its job. They are simple records, consisting of a status code (there are more than 70 codes, covering a broad range of conditions and errors), a date/time stamp, and some additional status information fields for system audit purposes. In addition, as errors occur in the processing of an IDoc, status records (see Figure B) are used to record these errors and the date/time of their occurrence. Figure B
(Display Status Record) IDoc number Direction Status information 38 IDoc archived (additional descriptive text) Log time Date Time Portion of IDoc status display 6-30-02 14:35:21 0000000000123456 1 Outbound

IDoc Base IDocs, as data formatting tools, enable the easy sharing of data between databases and applications within a company as well as being an efficient data courier between companies. Typically in SAP, a database of IDoc definitions exists, to which any application may have access. This IDoc Base gives all the applications and processes in your company domain the capacity to send, receive, and process a document in a contextually appropriate way, without doing anything to the data. For example, a purchase order IDoc can filter through every process it touches, passing from system to system, accumulating status records to track its progress.

Every department using the data can use it appropriately without any cumbersome intermediate processes, because each department draws its key to interpreting the IDoc from the same source. Multiple messages One cumbersome feature of conventional EDI is the embedding of more than one functional record type in a document. The unwieldy X-12 888 Item Maintenance transaction set is an example: It purports to handle so many different configurations of product master data that it is horrifically difficult to integrate into an existing system. IDocs, on the other hand, handle multiple messages with ease. Given the centralized IDoc interpretation that SAP provides to all its parts, its no problem to define an IDoc that will contain more than one message, that is, more than one data record type. A customer master IDoc, for example, may contain customer profile information records for a customer with many locations. But it may also contain location-specific pricing information records for that customer in the same document. This is an incredibly efficient way of bundling related records, particularly when passing large amounts of complex information from system to system (see Figure C). Figure C
CONTROL RECORD DATA RECORD - CUST PROFILE LOC #1 DATA RECORD - CUST PROFILE LOC #2 DATA RECORD - CUST PROFILE LOC #3 DATA RECORD - CUST DISCOUNT STRUCTURE LOC #1 DATA RECORD - CUST DISCOUNT STRUCTURE LOC #2 DATA RECORD - CUST DISCOUNT STRUCTURE LOC #3 STATUS RECORD STATUS RECORD STATUS RECORD

Records in a multiple-message IDoc Final thought There is no mastering SAP without mastering its workhorse, the IDoc. ERP environments utilizing SAP and similar platforms are made necessary in the first place by the increasing demands of ever more integrated business relationships. IDoc technology addresses this trend with a simple but powerful design philosophy: Data is no longer something to be stored; its something to be moved.

IDOC Useful notes:

1, In main business scenario of using IDOC: Company A(R/3)(IDOC)EDI Subsystem(Message)EDI subsystem(IDOC)Company B(R/3) In this scenario: Both companies have R/3 system and must configure their IDoc interface accordingly. The IDoc are to be translated into another EDI standard form. 2, IDoc stand for intermediate document. It is intermediate in two respects: Message-orientedData is also stored in application, only in other formats(the application documents). AsynchronousData can be stored in IDocs before an application document is created. 3, Examples of systems or applications which use IDocs: ALE: Application link enabling. EDI: Electronic data interchange. Business connector: Sending business documents using the Internet. 4, Outbound processing of IDoc includes: Posting the application document Generating the corresponding outbound IDoc Finding the partner and port Transfer of the IDoc to the external system via the port 5, IDoc settings including: Partner profiles Port definition Documentation tools EDI subsystem? Archive IDoc? 6, Detail Outbound processing of IDoc setting:(sending) Company A defines the system which will receive IDocs and technical parameters via the port definiton. Company A defines company B as a partner for message type ORDERS in the partner profiles and enters the port which has already been defined. Outbound IDocs created in the R/3 system should be archived by company A and then deleted. The documentation tools inform the EDI subsystem which IDOC type are to be recognized. 7, Inbound processing includes: Receiving IDoc data from an external system via an inboud port Creating the inbound IDoc Find the correct processing type via the partner profils. Creating the application documentat 8, Detail Inbound processing of IDoc setting:(receiving) Company B must configure the IDoc interface for inbound processing: The documentation tools inform the EDI subsystem which IDoc types are to be recognized. The port name must be maintained in the port definition beform IDocs can be accepted by the R/3 system. In the partner profiles, Company B enters company A as a partner for inbound processing and the message type ORDERS. In addition, agents reponsible for error processing are entered here, specifically for partners and messages. Like company A, comapny B wishes to archive and subsequently delete inbound IDocs which have been generated. 9, IDoc record types include: Control record.

Data records which store the application data in segment and describe the hierachy of these segments. Status records which determine the defined processing steps of the IDoc. As a result, the number of status records for an IDoc increases as processsing contines . 10, IDocs which are transmitted between two different system are always smaller then the IDocs in the R/3 system because they do not contain status records. 11, Control record:(IDoc ID, Partner, IDoc type and logical message, External structure) Data records: (Control part, Applicaton data) Status records:(Idoc ID, status information) 12, During direct outboud processing, the ALE services are always called, including: Filter the IDoc: Data not required for the communication is removed from the IDocs. Change the(segment) version: if the recipient only recognizes an earlier version of the IDoc type, the version can be changed here. This menas that less data is transported, as later versions of Idoc type can only contain more data than former vea less. Determind the Idoc recipient using a maintained distribution model, in case the application itself did not specify the recipient. Duplicate the Idoc, if required, for distribution models. NOTE: IDOCS cannot be duplicated during inbound processing. 13, Inboud processing using workflow: The external system sends Idocs to the R/3 system. The R/3 system is address via the port name SAP for example SAPC11 for an R/3 system called C11. If the Idoc Interface recognizes the external system, the inbound Idocs are accepted and checked that is, a syntxt check is performed and the system checks whether the sender is entered as a partner. The Idoc is sent to the application via SAP business workflow according to the settings in the partner profile. If required, the Idoc can be processed by the ALE services before being saved in the database as an inbound Idoc. 14, Idocs can only be deleted from the system when they have been archived. The phrase intermediate document dose not refer to the life expectancy of an IDoc. 15, Idoc types are only defined by their segments. Idocs, however, can be distinguished by the Idoc type and their contents. 16, In outbound processing, Idocs are always generated by the Idoc Interface or by the application. however, in inbound processing, Idocs are always generated by the Idoc interface. 17, Documentation tools include: Record types, Idoc types, segments. Output formats. 18, Idoc types are distinguished by their segments, that is the structure or raster laid upon the data part of the data record. These segments exist in both internal and external form: Internally as a release-independent structure(SAP names being with E1), containing all the defined segment fields. Externally as a release-dependent structure(SAP names begin with E2),containing only the segment fields defined for the specified release in the partner profile. 19, As a result, when running the documentation tools, you have to enter tow parameters: The version of the external record types(as enterd in the port definition) The releas of the external segment(as entered in the partner profiles) 20, We start the documentation tools from the initial node of the Idoc interface from the documentation menu. The parser has its own menu entry, both for record types and Idoc types.

21, The output formats can be read by external systems, so that no-R/3 systems can quickly recognize the Idoc structure. 22, Data for technical linking is determined in the port definition for the Idoc interface. so that a port can be used, settings outside of the idoc interface must be made. 23, The logical destination and the host destination are determined in the port definition. The RFC destination is created with the transaction sm59 and contains the logon data(name, password). The host destination indicates an entry in the R/3 interanl table TXCOM. 24, The Idoc partner profile is divided into four areas: General partner profile. Outbound partner profile(general). Additional parameters for outbound processing under message control(MC). Inbound partner profile. 25, About Partner profile of outbound processing: In conclusion, the MC record determines the Idoc type, port and function module, hence the entire outbound processing. There are other dependent fields such as permitted agents for notifications. 26, About partner profile of Inboud processing: Summary, the Idoc type determines the inbound processing for the Idoc. There are other dependent fields such as recipients of notifications. 27, Only one process code exists for outbound processing when message control(MC) is used(because the direct way simply sends an Idoc to the Idoc interface). This process code always identifies a function module. NOTE: process codes are client-specific. 28, Partner profiles specify which messages are sent to which users, using which method and how they are processed. partner must be entered in the partner profile before Idocs can be sent successfully. 29, The port is part of the outbound partner profile.Technical communication parameters are entered in the port definition. Inboud ports do not require such parameterstheir technical parameters are defined by the external sending system. 30, Process codes are also part of the partner profiles. They are used for processing data. 31, Outbound processing using message control: Message control generates message from application documents. The possible messages are defined as condition records in customizing. From the possibile message, MC search for those which match the current application data. This message determination can result in several message being found, or possibly none. If supported by the application, this message is proposed for editing in the transaction which started MC. When creating a purchase order, this means that the message proposal can be edited before the purchase order is posted. In any case, the message is generated and processed: for example, if the order is to be printed, the processing progamm sends the message to the printer. If the message is to be sent as an IDOC, a special processing program is called from the Idoc interface. The new message is represented by a new entry in the MC table.Part of this record is the processing staus, which can have the following values: 0=not yet processed, 1=successfully processed, 2=processed with error. 32, About transfer Idoc. Idocs are transferred individually from program RSNASTED when using output modes 1 and 2 (field outmod in the control record).

Idocs are not transferred directly when using output modes 3 and 4(field outmod in the control record). Instead, they are collected by the program RSEOUT00(bathc mode) and sent as a group. 33,Message defined in customizing are examined in a certain sequence to determine whether or not they apply to the current application data.This sequence is defined by the condition components and their hierarchy. 34, Idoc-specific message processing takes place via program RSNASTED. 35, About test Idoc information: Caution: eldin the caser of an original inbound Idoc, the status file is deleted after being read successfully. The test can therefore be carried out only once for each file. Status records must refer to outbound Idocs in the system, otherwise an error occurs in status processing. 36, About some useful Tcode of Idoc: Data exchange with the file system: WE14(outbound), WE16(inbound), WE17(status confirmation) Processing MC record: WE15 Data transfer from the Idoc interface to additional inbound processing: WE19 Data transfer to any port: WE14 Initial node of the Idoc interface: WE12 37, Special test programs require MC records, files or existing Idocs from the database. If necessary, automatic outbound mode from the partner profile and the dispatch time in the MC condition record. 38, The test tool allows general tests for inbound processing, outbound processing and status confirmation via systat01. 39, A process chain: summary. Special EDI parameters must be entered in the application master data. These include partner informatiion and transmission medium 6 in the condition record for outbond processing using message contro(MC). Outbound processing using message control is always applied for purchase orders from the mm module. 40, Statistics and monitoring Idoc. The Idoc data flow can be monitored via four passive programs and one active program in the Idoc interface. (Active monitoring programRSEIDOCM) Active monitoring is a function which can be individually configured for error handling or general exception handling. The level of detail in the passive monitoring programs goes as far as displaying the individual idocs.The leastdetailed monitoring tool is the status group display under Idoc statistics. 41, Idoc inbound processing can include a workflow which is triggered by a process code. This workflow is defined by the user. An application document is created automatically from the idoc. The application document is then sent to a user for review. The Idoc is edited and modified if necessary before the application document is created.In this case, the Idoc is edited and not the application document. The Idoc or application document is forwarded to other users or new(outbound) Idocs are sent, using the inbound Idoc as a basis. 42, Workflow auto-customizing(transaction SWU3)include all tasks relating to the Idoc interface as general tasks, that is , all R/3 users are possible agents. If you want to restrict this number, you can do this using an organizational structure. 43, Workflow and Idocs: summary Normal Idoc processing via workflow is only possible for inbound processing of certain Idoc types.

Exception handling always takes place via workflow. It is called in ountbound processing in the same way as in inbound processing. Errors can be casued by incorrect application data or incorrect Idoc syntax. In these cases, error handling is different. Through the organizational structure, workflow allows users in a defined task area to be notified, not individual users whose responsibilities may change. Workflow allows incorrect Idocs to be forwarded as work items in a controlled manner from an intergrated inbox and even to be repaired in some cases. 44, The most important task of the EDI subsystem is converting to or from the required EDI standard; this task is carried out by the translator as a subfunction of the EDI subsystem. The individual criteria, for example selecting and assigning fields, are mapping components(usually customer-specific). 45, As a result, an EDI subsystem must send certain fields with their values for Idoc inbound processing: Partner, message(their fields each) and test flag(1 field) must correspond to the entries in the partner profile. This also means that the partner function value, for example, must be left empty if the corresponding field in the partner profile is also empty. Directin=2(inbound), structure=EDI_DC40(external control record structure in release 4.0). An R/3 system(release 3.x)would expect a different structure. Sender port and recipient port. 46, Using an EDI Subsystem: summary The EDI subsystem is used mainly for converting the Idoc format into an EDI standard(and vice versa). The EDI subsystem is an interface to external systems and has its own responsibilities. Format definitions can be defined in the EDI subsystem in a form which can be read by other system. 47, Archiving: summary All archiving programs are addressed via the central archiving transaction SARA. The archiving object is Idoc. Idocs can only be deleted if they have been archived. The archiving run must be complete. Idocs can only be archived if they have been assigned a status which can be archived. The statuses suitable for archiving can be configured in the Idoc interface. 48, Summary of IDOC. *The Idoc interface allows the exchange of business data between SAP applications and external systems. The formats used for transmitting data(Idoc types)are documented. *Idocs are exchanged with external systems on a partner-specific and message-specific basis. Idoc data flow is therefore defined via the partner profiles and port definitions. *In outbound processing, Idocs can be collected in a group or sent to the external system immediately. *In Inbound processing, Idocs can be processed via workflow. *Exception handling for incorrect Idocs always takes places via workflow. *Monitoring programs and statistics programs are available for the Idoc data flow.Active monitoring can be used to automatically notify the agent responsible. *Idocs which have been processed completely can be archived. *If the Idoc types in the standard system do not meet your requirements, you can add upwardly compatible extensions or define your own Idoc types. Studying IDOC More 1, The message can be sent from the application to the IDoc interface along two paths: *The indirect path using messge control: a series of conditions are checked to find the message. *The direct path from the application to the receiving system along different paths. Port selection also depends on the receiving system and the hardware used for the installation.

2, In all exception situations where the sender is defined in the partner profile, the permitted agents are read from the profiles. Agents can be organization units(for example , department,job) and not just sap user. 3, Communicate R/3 with external system with Idoc. There will use two sap standard programs rfcexec and startrfc, they are applied to outbound and inbound respectively.