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.