SMQ2 inbound queues stuck with name/password error

[Former Member]

We have quite a few inbound queues in ECC that are held up because of login/password errors that randomly occur.  This is usually the executing user is locked, has an invalid password, etc. 

I can reprocess them as they appear by providing valid credentials, and then the rest will continue to run until another name/password error occurs.  Then they all stop again until that failed one is processed with the correct credentials.

What I'd like to do is let the queues get processed that do work, while leaving the failed ones alone.  We've missed this for a while and now there are nearly 2 million queues, so manually reprocessing them and providing valid credentials when they randomly fail is not a practical solution.

[Former Member]

Hello,

You have two options here. You should be able the failed in SM58 as well.

1. SM58 - Execute all entries in one shot. Choose Edit--> Execute LUWs and select appropriate options and execute. It's mass execution option available.

2. SM58 - Check with the owner of that queue or entry and delete them (Log File--> Reorganize)  if they are no longer valid or required to be reprocessed.

Thanks,

Siva Kumar

[Former Member]

The queues are executed by any number of actual dialog users as opposed to utilizing an SM59 fixed user.  The business process goes from ECC --> PI --> ECC.  The inbound from PI is what's failing randomly because some users have been locked, expired, etc.

Scheduling a job to retry the failed queues would simply keep failing until someone either deletes the bad queue (with the faulty user), or fixes the login credentials. 

What I'd rather do is have the other queues continue to process and then let the failed ones accumuilate to be dealt with seperately.

[anjaneya_bhardwaj2]

Hi ,

For that to happen you need to get Rid of the Inbound queue which are in error status and as you know there are 2 millions .I do not how are you going to deal with that .It is not a good practice to delete the logs rather correct them according to best practices .

Why do you need PI in ECC to ECC scenario ? Even if it was I do not see why SAP would have provided a Report to delete the log when they say process the log .If the User are not valid you should not get a request in any case.

Please have a look at below link to proceed further with the solution finding mechanism. http://scn.sap.com/thread/69670 .

http://search.sap.com/ui/scn#query=deleting+the+errored+queue+in+SMQ2&startindex=1&filter=scm_a_site...

http://scn.sap.com/thread/1201227

Sorry I am not able to provide the exact solution for this.

Thanks,

Anjan .

[anjaneya_bhardwaj2]

My Suggestion would be prevention rather than Cure .Keep you SM59 updated and User ID and passowrd should always be the correct on and all those RFC users should be told immediately.Stopping the error from occuring wil save a lot of system load .As scheduling and correcting the IDOC will consume system resources .

Thanks,
Anjan .

[Former Member]

Hi,

Please see the below link

http://scn.sap.com/people/community.user/blog/2005/11/29/xi-how-to-re-process-failed-xi-messages-aut...

You have to schedule a background job to reprocess the failed messages, and for Inbound messages you need use report RSQIWKEX for the background job.

Hope this info will help you.

Regards,

Pradeep