SAP IDoc in ABAP
Working with IDocs in ABAP means generating, processing and enhancing the intermediate documents SAP uses for integration. Developers build custom IDoc processing and extend standard IDocs to fit business needs.
Working with IDocs in ABAP means the processing code and its enhancement: inbound, a process code function module posts the IDoc into the application; outbound, a program or event generates one. To carry custom fields you extend the basic type and populate the new segments with user-exits or BAdIs, then monitor and reprocess in WE02 and BD87.
- Watch out: Building custom IDocs when a standard type exists.
IDoc processing in ABAP
Inbound, a function module (the process code) posts an incoming IDoc into the application; outbound, a program or event generates an IDoc from application data and dispatches it. SAP provides many standard IDoc types and processing functions; developers configure, enhance, or (less often) build custom ones.
Key building blocks
- Basic type / extension: the IDoc structure (segments); extensions add custom fields.
- Process code / function module: the logic that posts or creates the IDoc.
- Partner profiles & ports: configure who exchanges which IDocs and how.
- Status handling: reading and setting IDoc statuses.
Monitoring and reprocessing
" reprocess an errored inbound IDoc programmatically
CALL FUNCTION 'IDOC_INPUT_...' ... " or use BD87 interactively
" WE02/WE05: display IDocs & statuses; BD87: reprocessEnhancing standard IDocs
A common task is adding custom fields via an IDoc extension and populating them with user-exits/BAdIs in the outbound/inbound flow. This lets you carry extra data without abandoning the robust standard IDoc framework.
Common pitfalls
- Building custom IDocs when a standard type exists.
- Ignoring status handling, errors invisible.
- Not monitoring (WE02/BD87), failed IDocs pile up.