Corrective steps in case of queue

[Mrinal_K_Roy]

Hello,

Can someone please inform the corrective steps in case of queues -- diagnosis and remedies .

Regards,

Mrinal

[aparna_ranganathan · Accepted solution]

Mrinal ,

I believe you are talking about the CIF queues. Here are some of the things that are important

1. Whenever there is an error in the master data / transaction data in ECC , then the corresponding IM will fail. If you are running the IM job in the background , you can check SM37 log and understand that the job has failed.

2. For further analysis you can look at the inbound queues in APO and outbound queues in ECC and understand what exactly the error is . You have to use tcodes SMQ1 and SMQ2 for the same

3. the next step would be to correct the data that is causing the error.

4 . You can then clear the faulty queue entry using /n/sapapo/cq

5. the final step would be to again run the IM and send the data thru.

Thanks

Saradha

[Former Member]

Hi Mrinal,

Most of the points have been cleared in the above posted message, howvever here are some more tips on queue clearance. . .

1) You can use t-code /n/sapapo/cpp, its a t-code for Cif Post Processing. This is the best debugger cum queue monitoring tool.

2) Whenever you go to smq1 or smq2, you can just doble click on the errorneous queue twice, and you would now be able to watch the LUWs linked to the queue. At the Top there is a button named DEBUG LUW, just click on the same and you would be able to find the errorneous LUW. This Process is however a very tidious one and also involves a bit of ABAp knowledge.

Hope this might help you.

Please let me know your inputs on the same.

Regards,

Prasad

[Mrinal_K_Roy]

Hi Saradha / Prasad,

Thanks for yr replies . Can you please also clarify the following queries

1. If the reason for failure of queue can not be determined , then what to do

2 . After finding the reason for failure in a queue , will that particular variant of IM needs be sent or all variants which has also failed (which are behind the failed queue)

3 . Postprocessing is not active in our application , then what is the next best approach

4 . When to check in CFG1

5 . I have found in some cases that there are queues , but plan orders are still being created , what can be the reason for that.

Thanks in advance.

With regards,

Mrinal

[Former Member]

1. If the reason for failure of queue can not be determined , then what to do

You can always find a reason. if a queue fails it will have a log. Either on the application layer (SLG1/CFG1/CFG3) or within the system layer (SM21) or perhaps referenced via a short dump (ST22). Some are easy to figure out, others are more opportunistic.

2 . After finding the reason for failure in a queue , will that particular variant of IM needs be sent or all variants which has also failed (which are behind the failed queue)

a queue error does not always equate to a requirement to activate or generate an integration model. It is best to resolve the failed queue and let the pending qrfc processing take over, but if the time limit is exceeded then select all entries in /sapapo/cq and activate and the order will be preserved.

3 . Postprocessing is not active in our application , then what is the next best approach

single queue processing would work.

4 . When to check in CFG1

You should look in SLG1 and CFG1 as a standard check of what happens in the system. Although some queues will naturally inform you where the issue occurred, it is always best to get a holistic view of the situation before making any determinations of cause and resolution.

5 . I have found in some cases that there are queues , but plan orders are still being created , what can be the reason for that.

It would depend on the messages in those queues. Provide such a message and more assistance is on the way!

[Former Member]

Hi Mrinal,

1) Most of the times, you would surely be able to get through the exact error in a sysfail, however if at all the error is not understood, then what you can do is, for the time being you can run the IM in foreground (CFM1) and keep ignoring the errorneous queues.You can later resolve the issue. Your IM will be unaffected.

2) If an IM has failed because of a particular sysfail, you can just run the same variant. A simple way to overcome this is, you can run a single product_location IM for the errorneous queue.(this is preferable when the no. of Product_location in the syfail are less).

However, if rest of the IMs behind, that are dependent on the prior, then its preferable to run all these IM Variants.

3) if CPP is not active on ur system, then the next best is CFG1 and CQ1 in APO. Many a times SMQ1 and SMQ2 are sufficient.

4) If at all, the error in a sysfail is not understood by smq1/2.

5) The reason might be that these sysfails are not related in a way, that they will directly stop these plan orders from coming into APO. Please let me know the exact scenario so that we can provide a better input on this.

Please let me know your comments on the same.

Regards,

Prasad.