A computerized system is like any system part of a greater whole, and communication with this "outside world" is supported by Idocs. Intermediate documents. A document which is in transfer (or it it in the process of being composed and sent out (outbound Idoc) or it is in the process of being interpreted (inbound Idoc). Idocs is SAP controlled manner of interfacing, and you should realize there is a strong preference over the "manual interface" as the system as a whole has little benefits from numerous stand-alone interface programs. Going from system to system the Outbound Idoc is first composed as a document on the tables of the sending system. It is then sent out as file or stream, to be picked up as an Inbound Idoc in the recieving system. The revieving system assigns a new Idoc number and stores the Idoc document. A stored document can then be processed, resulting in e.g. the creation of a Goods receipt or the change of an Order.
An overview of relevant transactions when doing anything related to Idocs...
A listing of glossary words specific to Idoc processing can help understand how Intermediate Documents work.
Setting up an Idoc "definition of content" is a rather thrilling task, where the difference between creating a brand new Basic Type or creating an Extension should be clear... R/3 has Idocs set up for every business relevant "Document" it can produce. Ergo: where R/3 documents are produced (e.g. a Purchase Order) the electronic version or Idoc version of this document can be produced as well. In effect: when Idoc traffic is set up from a customer system, the traffic is likely to be about a document produced in R/3. So now you have a choice: is the Idoc you want to define (inbound or outbound) based on an existing SAP document or not ?If it is, simply lean on the Basic Type and inbound (and outbound) function module(s) that come with them like:
Who are we talking to ? Who's talking to us ?? Setting up an Idoc is not just about what to put in the message, it's also about where it is sent to and where messages are received from. The partner profile plays a central role in Idoc settings: inbound parameters, outbound parameters and message parameters can be set up on the partner profile.
The following can be set up on the partner profile:
- The message type (what is should do)
- port (where should it go)
- the process code (what should be done with inbound Idocs, or what function module should gather information for the outbound Idoc)
- triggering
- monitoring agent (workflow agent: the person that gets error notifications)
The transaction for partner profiles is WE20.
Some inbound Idoc processing modules can populate their error messages on the application log rather than in status 51 messages... The application log or BAL (Business Application Log) is in effect a cross-component logging facility where processes such as processing an inbound Idoc can place messages. It can also be used for your own custom development ! The end user can browse through the "reported objects" (in our case an Idoc in status 51).
are a clever name for a triggering reason for outbound Idocs. Using a change pointer which is defined by customizing against any Change Document for any Message Type. From concept to implementation..
If you find the need to alter Idoc field values to make an easy match with the recieving system - this can be done as a customizing thing... (extending to ABAP logic if you like). This is about a setup which I´ve not seen on many Idoc implementations, however it´s very powerful and it´s good to know about it´s existance.
With a workflow system in place, linking the Idoc processing into the workflow inbox is a logical next step. Of course something that SAP has prepared for us nicely... By simply supplying a user administrator user ID or a workflow Organizational Unit which leads to a list of agents, the Idoc processing system issues workflow work items if something goes wrong. What is something ?
Two types of communication, often used terms in interfacing country. What are they ? What's the difference ?
Determine where an outbound should go to. For every outbound Idoc the receiver needs to be filled, if it's not filled, the CDM could still fill it for you... The absolute strength behind this concept is that more than one receivers could be set up for an Idoc, effectively creating an Idoc per receiver. Via transaction BD64 - Maintain Customer Distribution Model, settings per partner profile - message type combination can be done, effectively allowing the Idoc that is created without receiver to be send out (with receiver).
How should this be used ? Remarkably simple: use the Change pointer setup to generate your (receiverless) Idocs, or build one yourself, using the MASTER_IDOC_DISTRIBUTE function module, which will return a list of actual Communication Idocs. A communication Idoc is an actual Idoc that can be found on the database (table EDIDC etc.) The master idoc is a fictional Idoc: it is handed to MASTER_IDOC_DISTRIBUTE and the CDM may well create several communication Idocs for it, but a master Idoc is not actually stored. This does imply that an Idoc created without receiver and which does not has CDM settings in place will result in nothing at all (!)
A Badi is available which can stop communication Idocs from being created. Check it out !
Badi IDOC_CREATION_CHECK is available (via transaction SE18). The article on "Customer distribution model" explains briefly how the master Idoc and communication Idocs work. The Badi can be used to suppress the creation of the actual communication Idoc. This can thus be a mechanism to avoid unwanted messages being produced.
The Badi implementation IDOC_CREATION_CHECK implements a method IDOC_CREATION_CHECK to which the Idoc header and Idoc data is passed (mind you at this point in processing the Idoc has not yet been created, thus no Idoc status information is available). Parameter CREATE_IDOC is a flag that indicates whether the Idoc should be created.
Listing Idoc's can be done with the very powerful WE02 - Idoc list WE05, which is exactly the same. Even editing Idocs is possible... The reporting is set up very elegantly and allows drilling down into the actual segment contents. Note the latest status and full status history telling you exactly what happened to the Idoc.
Also note that the reporting transaction allows changing the Idoc. The data segments in the WE02 report are preceded by an Icon. Double click on this Icon brings you to "Display Data Record for Idoc" which shows all filled segment fields and values. from this overview go to: Menu: Data record => Display -> Change, to change to edit mode. When field values are edited here, the Idoc will be changed to status 69: Idoc was Edited (for an inbound Idoc) or 32 for outbound.
The other way of searching for Idocs is by "Business Content", which can be done with transaction WE09 - Idoc search for Business Contents (Database). If you know what field value you are looking for and in which segment (and field) it resodes, WE09 will search through your Idocs. WE10 - Does the same...
Transaction WE19 is your main tool to test both inbound and outbound Idocs, whether set up completely or not. The test tool is effectively an editor with which an Idoc can be set up and then send out or in.
When your Idoc changes have been tested on the development environment, you may come to the conclusion that the Idoc used on development could be very useful on the test system. Use the test tool to create an inbound Idoc file for your inbound Idoc... The nature of Idoc processing is of course to get your data from system to system, however this doesn't mean you can put your Idoc on a memory stick and jab it into the next system. Here's what you can do to get test Idocs across different systems - and you will notice that it's pretty solid in setup - for good reason (security).
Idoc information is held on only 3 tables... An Idoc can hold information which which any other (SAP) document can be created or changed. But the Idoc itself is held on only 3 tables.
- The control record which acts as the Idoc header (one per Idoc) and is held on table
EDIDC. The message type, idoc type, extension, partners (sending and receiving), latest (current) status and creation date & time can be found on the Idoc control record.
Need an Idoc by definition in your program ? Some function modules...The following function modules could come in handy
IDOC_SEGMENT_STRUCTURE_READtakes the release and a segment name and returns the segment structure (fields and field attributes)IDOCTYPES_FOR_MESTYPE_READtakes the message type: Determine IDoc types for logical messages (RFC-compatible)IDOCTYPE_READIdoc type (basic type) infoEXTTYPE_READExtension info
Can an Idoc be deleted from the system without any trace ? It can... but do make sure this is handled with care. Transaction WE11- delete Idocs. Sap has made it quite easy to get rid of Idocs for a certain message type and with a given creation date/time.