nbound Idoc Status 64

[Former Member]

Hi experts,

Im facing diffuculty to find out why some IDocs are in status 64 on the system. If it is re-processed individually, it will be successful. But as a bulk, the status will be in 64. I checked the settings too. It is in "trigger Idoc immediately" status only. When these Idocs are recieved , the initial status is 64. Then it is taking time to change the status to 53 , one by one.....which is a gradual process. can you please help me out.

[former_member186390]

The Idocs can get stuck to status 64 for long time due to some dumps during the inbound processing. Just try to process the idoc in foreground to find out where in the code its actually going for dump.

Please let me know if this issue is due dump, The i will help further.

Edited by: Amit Kumar Singh on Oct 26, 2010 11:15 AM

[JL23]

64 is just the status of a non-processed IDOC.

In other words this IDOC was not included in the selection of the program that processes the IDOCs

[Former Member]

There may be system buffer issues at the time of Initial IDoc postings.

You can schedule a batch job using the BD87 tcode program with suitable parameters like message type and IDoc type, IDoc status etc to avoid re-processing all other IDocs.

This will avoid the all the IDocs sitting in queue for long time with this status.

Thanks

Lakshmi

[Former Member]

Hello,

There can be various reasons for the issue you're having. When the status turns to 64, the input is given to the calling FM. Please check the following:

1. Trigger immediately - You have confirmed this

2. Process code - What type of processing is this? e.g. Calling a workflow? Using a FM (Direct input FM or call transaction)?

Based on the type of processing triggers go out and processing programs take their time to post. For e.g. if you have a call transaction custom FM defined for your type of inbound processing. Then to post the IDOC in SAP, the transaction called might take its own usual time. Because the processing is batch mode, there will be priorities assigned by BASIS for each types of processing. That might affect your processing too. Lastly, there could be lock entries etc which might be slowing things down for your inbound processing. Your load of IDOC processing will also matter a lot. I have seen thousands of IDOC's being processed by some clients at a certain time of the day. There could be clashes for resources in the application layer. If you're using a SAP standard FM for inbound processing, check if any exits are causing the delays (like hard database queries etc).

When you process interactively, you're just processing one IDOC. But when a huge load of IDOC's come inbound into the port, system allocates resources to process them as they come in. So lot of things happen which you have to look at carefully and take out of consideration. If you provide more information, someone will be able to share better information.

[Former Member]

Hi,

Thanks a lot for your input.

I checked the process code , this is done via FM and processing with ALE service. Is there any way to know the priorities assigned by BASIS for each types of processing?

[Former Member]

Hi Geethu,

I also faced the same issue few days back.

To solve it, process the inbound function module in foreground by putting a break point inside it or creating a test IDoc in we19 and process it in we19 in foreground mode. I am sure that there will definitely be a user exit where code is not optimized and hence it is taking long time to process the status 64 IDocs.

Apart from that since processing is getting hanged up for a long time, you can check t.code sm50 where you can see the list of work processes which are taking more time. By doing some analysis you can find the cause of the problem.

Please come up with your qureies if any.

Cheers

VJ

[Former Member]

Hi VJ,

What I see when checking in we02 is, initially all the idocs were in 64 status. Later on, each Idoc's status is being changed to status 53. And it is taking time for processing each one. Now i am checking on SM50 also. Thanks a lot for the input.

[Former Member]

If this is the case, then definitely likewise I said earlier, there must be one exit where code is hanging up and once it's execution gets finished, IDocs are getting posted successfully. To analyze it more, you can debug the incoming IDoc in WE19 and debug the inbound IDoc FM. Apart from that as soon as you are debugging the FM, analyze the SM50 transaction as well.

Cheers

VJ

[johndeconinck]

Hi VJ,

If system instances are full, the system creates job for inbound Idocs. Check first SM58 if you have some RFC calls pending. If not, you can check the job registry log for the jobs created for the inbound Idocs. You can find the job number/name with WE02 and than with SM37 check the registry log for the job. Often the problem is authorization for the user that launches the inbound Idoc (defined in SM59 and if not, the user that launched the transaction).

Please award if useful.

Kind regards,

John.

[Former Member]

Thank you