- Added by Kevin O'Donoghue, last edited by Kevin O'Donoghue on Nov 26, 2012
- show comment
Purpose
This wiki will explain how to avoid the situation where outbound idocs remain in status 30.
Overview
You try to send idocs to another system using the "Transfer Idoc immed." option in WE20 but they just hang in status 30 (Idoc ready for dispatch) and are not changed to status 03 (Data passed to port OK).
How to avoid it
If you are using SAP standard, check note 150202 to see if a solution for your application has already been created.
However, if you're using a custom message type or if you are calling MASTER_IDOC_DISTRIBUTE from a Z program, you shouldn't call the FM directly. The problem is probably that locks are remaining on the idoc tables after calling the ALE layer. When calling the ALE/Idoc layer from your custom program you have to run a COMMIT WORK after the call. At this time the communication will be triggered and the idocs have to be dequeued. When you raise the COMMIT WORK, the background processing which sends the IDocs from status 30 to status 03 is started. At this moment the ID is still locked by your program. This lock will be automatically deleted when the program ends, but for this short delay/ bottleneck, it is recommended not to use a single COMMIT WORK but a manual dequeuing before this COMMIT WORK.
There are 2 ways to circumvent this issue:
Solution 1:
Change to "Collect Idocs" in WE20 and schedule RSEOUT00 to process the idocs in the background.
Solution 2:
Implement the following "triple" into your program that creates the idocs:
CALL FUNCTION 'DB_COMMIT'.
CALL FUNCTION 'DEQUEUE_ALL'.
COMMIT WORK.
Please note: Function module DEQUEUE_ALL dequeues all locks. In case you need to delete the lock of your single IDoc only, please use function
module EDI_DOCUMENT_DEQUEUE_LATER. This function module dequeues the IDoc with the imported IDoc number only.