This blog will give tips & tricks on working with idocs.
Questions that will be answered are:
- How can I actively monitor idocs?
- How can I reprocess idocs in error?
- How to process idocs in collect mode?
- How can I search the business content of idocs?
- How to execute technical consistency check for the idoc settings?
- How can I clean up idocs?
- How can I force a change of idoc status?
Idoc search and listing
Next to WE02 and WE05, you can use transaction WLF_IDOC to list idocs. WLF_IDOC can also scan the idocs for content. Read more on WLF_IDOC in this blog.
WE06 active idoc monitoring
Transaction WE06 can be used to setup active idoc monitoring. If idocs are running into delay for certain status, you can send workflow:
You need to activate the ALARM message workflow: this is a work item of the TS74508518 standard task.
Read the full SAP help for more details.
WE09 search idoc for business content
Transaction WE09 can be used to search idocs for business content:
Short instruction on how to use WE09 is documented in OSS note 1823081 – WE09 – criteria for searching in data records.
A search function is also available in transaction WLF_IDOC.
Set idoc status
Program RC1_IDOC_SET_STATUS can be used to change an idoc status:
This program is meant to run on non-production systems. Take special care and think twice before running this program on a productive system.
Technical consistency check
You can use transaction BDM5 to execute a technical consistency check for your idoc configuration:
Per item a lot of sanity checks are performed:
Processing inbound idocs that are on collect
You can use transaction BD20 to process inbound idocs with partner profile on collect (idocs status 64):
You can also schedule the program RBDAPP01 in batch to process the idocs in status 64 periodically.
When you post too many idocs too fast with immediate processing, the SAP system might get overloaded and will leave the idocs in status 64. In this case best to switch to collect mode and plan the program RBDAPP01 periodically for processing. See more in OSS note 1872637 – Delays posting inbound IDocs (status 64) which have been configured to trigger immediately.
Bug fix OSS note for RBDAPP01: 2795034 – RBDAPP01 – selection of IDocs that have not yet been completely saved (dirty read).
For parallel processing read this note: 2697762 – ALE: Maximum processes for processing.
Idocs remaining on status 64
In weird cases inbound idocs with partner profile set to process immediately remain in status 64.
Potential root causes:
Sending outbound idocs that are on collect
If you have configured outbound idocs to be collected, the idocs remain in status 30 until they are to be sent out. The sending can be done with transaction WE14 or by batch job of program RSEOUT00:
Recent bug note on RSEOUT00: 2747015 – IDoc: Locks in IDoc outbound processing.
Custom idoc processing remains in status 30
If you have custom idocs or custom idoc processing and you call function module MASTER_IDOC_DISTRIBUTE for the outbound distribution, the idocs might get stuck in status 30, even if you set the partner profile to immediate processing. If this is the case, read OSS note 1575852 – Outbound IDocs remain in status 30. This solution provided might seem strange, but it does work:
Implement the following “triple” into your program that creates the idocs:
CALL FUNCTION ‘DB_COMMIT’.
CALL FUNCTION ‘DEQUEUE_ALL’.
COMMIT WORK.
Checking that outbound idocs have passed RFC layer
If there are issues with outbound idocs, most likely it is because they are stuck in the RFC layer. You can check this with transaction SM58.
You can use transaction BD75 to convert the idocs from status 03 to status 12. Status 12 means that they have correctly passed the RFC layer. The program behind BD75 is RBDMOIND, which can also be planned in a batch job:
Reprocessing failed inbound and outbound idocs with technical errors
If outbound idocs fail with technical errors like 02, 25, 26, 29: first correct the technical setup error. When the setup is fixed, you can use transaction BD83 to reprocess the failed idocs (in stead of regenerating them):
If inbound idocs fail with technical errors like 56, 61 , 63: first correct the technical setup error. When the setup is fixed, you can use transaction BD84 to reprocess the failed idocs (in stead of asking the sender to send them again):
Planning these programs in batch job is not a good idea. Fix the root cause, then this reprocessing is not required any more in the future.
Reprocessing edited idocs
If you have edited idocs and want to reprocess them again, use transaction WPIE to start the processing:
Reprocessing inbound idocs in status 51
You can use program RBDMANI2 to reprocess idocs in status 51 (error in functionality):
This program is usually run in background mode as well in productive system. In a productive system don’t run it too frequently, since very try will add a new status 51. Therefore also limit the amount of days of history you want to reprocess automatically. Do use the option to filter on message class and number, to reprocess only selective messages for selective message type. The most common use is to reprocess idocs that could not be processed due to another user locking the data.
This might result into a couple of variants, or even a couple of different batch jobs running at different frequencies for reprocessing different message types.
If the reprocessing takes long time, read OSS note 2524675 – Long processing time when processing IDocs in status 51. This basically tells you to start deleting or archiving idocs.
Idoc clean up
Transaction WE11 can be used to delete idocs. If you want to archive idocs, you can use archiving object IDOC. See OSS note 40088 – Deletion or reorganization of IDocs, or this blog on technical clean up.
