Introduction to IDoc
IDoc is an intermediate document that is used in SAP applications to transfer data from SAP to SAP and SAP to external systems. The transferring of data from SAP to SAP is done through Application Link Enabling (ALE) system whereas transferring data from SAP to an external system will be done through Electronic Data Interchange (EDI).
Inbound IDoc – When an IDoc comes into the SAP system
Outbound IDoc – When an IDoc goes out of a system.
Why is IDoc better than other interfaces?
- IDoc type is capable of storing only the data required for the particular transaction, which increases efficiency and decreases resource demand.
- The native IDoc adapter is more stable than the RFC adapter.
- The IDoc adapter works only asynchronously so there is no need for an immediate response from the external system.
Business Usecase
Flow Of IDoc:
Case 1: Outbound Flow:
IDoc is triggered in SAP through message control which follows certain conditions like message type, and condition types for output. Triggered IDoc is sent to the EDI sub-system. The EDI converts received data from IDoc into XML or equivalent format and then sends the data to the partner system via the internet.
Case 2: Inbound Flow:
Once, the EDI converts partner data, SAP will support EDI through IDoc and it is created in the SAP system. After successful processing of this IDoc, the Application Document is posted in SAP.
Features of IDoc:
Partner
A partner is a business partner with whom information must be exchanged using IDoc.
Partner Profile:
Partner profiles are a requirement for data exchange. You define who can exchange messages with the SAP ERP system using a specified port. SAP Transaction code to create/view the Partner profile is WE20.
Port
Port is the communication channel through which IDocs are sent/received. It describes the technical link between sending and receiving system. SAP Transaction code for port create/view is WE21.
IDoc Type
SAP Transaction code for create/view the IDoc types is WE30.
IDoc Basic Type
It defines the structure of an IDoc. Each basic type describes the standard Idoc segments format of the default field and its size.
IDoc Extension
The basic type contains all the standard fields that are necessary for carrying out business transactions. Sometimes these fields are not sufficient for a specific end-to-end business scenario. So, in this case, we can add new segments with a completely new structure to the standard IDoc as an extension called IDoc Extension.
IDoc Segments
IDoc segments contain actual data that is sent to or received from a partner. IDoc segment has fields that contain the data necessary for posting the documents. SAP Transaction code for Segment creation/view is WE31.
Message Type
IDoc processing involves the transmission and reception of documents in the form of a message, each of which represents a document in SAP Transaction code WE81. SAP Transaction code for linking the Message type to the processing code is WE60.
Process Code
Process code contains the details of the function modules that are used for IDoc processing.
Initial Configuration To Trigger An Outbound IDoc:
Using ALE change pointer mechanism:
The ALE-IDoc framework, particularly its Change Pointers functionality can be used to transport master data across multiple systems. SAP serves as the primary system for managing master data, including Customer, Vendor and Material masters, in the majority of organizational system landscapes. We can move master data from the primary SAP system to other systems in the landscape and other connected systems by using the Change Pointers mechanism.
Using Output Determination:
- Create a New Output Type
- Configure General Data and Access Sequence of Output Type
- Maintain Default Values Transmission Medium
- Configure Processing Routine
- Set Partner Functions
- Configure Output Procedure
- Maintain Conditions for Output Control.
Using ABAP Programs:
Custom ABAP programs are sometimes used to create IDocs. To generate outbound IDocs from ABAP programs, we need to find the outbound IDoc which triggers the IDoc function module, message type and basic type. Go to the SAP transaction code WE57 to find FM and use it in an ABAP program to generate outbound IDocs.
Steps To Create Extended IDOC:
- Creating a custom segment in WE31,
- Create IDoc Type in WE30,
- Basic IDoc type: Using some SAP existing IDoc type.
- Extension IDoc type: Additional segments to an existing IDoc type.
- Create a message type in WE81,
- Attach message type to the IDoc type in WE82,
- Create a function module in SE37,
- Assign the output type to the IDoc type in WE57,
- Create a custom process code in WE42,
- Attach the function module in process code in WE42,
- Attach the function module to the process code in BD67,
- Execute IDoc for testing in WE19.
Debugging Inbound and Outbound IDoc:
- Copy the IDoc status and message number pasted in SAP transaction code SE91 with the message class and message number.
- This shows the message and used list of the message. put breakpoints on those messages.
- Go to SAP transaction WE20, Note the partner profile of that IDoc and specific function type and also the message type and process code.
- Find the relevant function module name for processing and search the call function globally and mention the breakpoint inside the call function.
- Go to SAP transaction code BD87, Enter the IDoc number and execute. We will find the drop-down contains the IDoc error message.
- Select that and click on the process, will redirect to debug mode.
Problems and Challenges
Document Locking
IDoc can fail sometimes, because of the locking issues. For example, PO can be opened in change mode in which the IDoc processing job is trying to update the confirmation for PO.
Solution:
Check the SAP transaction code SM12 for locks and try to reprocess the IDoc once the locks are removed.
Parallel Processing
If multiple programs are trying to process one IDoc then the processing program can fail due to a locking issue.
Solution:
Try to find the programs which process the IDocs. Exclude the IDoc from one of the programs. Ensure that this IDoc is processed after exclusion.
Increased In Number of Inbound and Outbound IDocs
The high volume of inbound and outbound IDocs can cause errors in sending and receiving data transfers. In this case, IDoc shows status as 30 or 64 or stuck in the transactional RFC queue. SAP transaction code for transactional RFC is SM58.
Solution:
The high volume of inbound and outbound IDocs is solved by processing IDoc in batches. This can be done by selecting ‘Trigger by background program’ for inbound and ‘Collected IDocs’ for outbound in the SAP transaction code WE20. We can schedule the batch job to run at regular intervals to process the collected IDocs.
Duplicate IDocs
IDocs that are duplicates may also fail.
Solution:
Check whether the IDoc is trying to post what is already posted and communicate the same to concerned partners or users.
Mandatory Segments Missing
If mandatory segments are missing the IDoc will fail with a syntax error.
Solution:
Check with the EDI team about the reason for the syntax error. For outbound IDoc, if the segment is missing then, try to maintain the necessary data and the application by comparing successful IDocs. For inbound IDoc ask the partner to send the correct data.
Conclusion
“It all begins with systematic demand of excessive and ends with technical upgradation beyond its SPECIFIC excessive.”
Intermediate document (IDoc) with its unique functionalities overshades the existing upgraded features with the standard APIs and resourced transfer of multi-formulated data from SAP to SAP and external system to SAP world.