Set system behaviour when a blocked queue is double clicked in /SAPAPO/CQ

[former_member209769]

When we double click on the error icon for any blocked queue that is displayed in Queue Manager in APO, we are taken to a details screen (in most of the cases) if the queue belongs to APO inbound or outbound.

However, when we click on a queue belonging to R/3 system, then we would normally see a new pop-up with the message "no system logs found for this queue". Or depending on some settings (or configuration) in some cases, we are taken to the login screen of the corresponding R/3 (or ECC) system.

I want to know what settings (or authorizations, if they controls this behaviour) need to be maintained in the system so that a user is NEVER taken to the login screen when he clicks on a queue belonging to R/3 system. Can someone please help me on this issue? We are seeing users getting locked since they are trying to login when they reach this login screen.

[Former Member · Accepted solution]

Pawan,

First check the Authorization profile of the RFC connection USERID in the destination system (in this case, the ERP system(s)). This USERID should have at a minimum the authorization to perform SMQ1/SMQ2, and the ability to manage queues. If you wish to use /SAPAPO/CQ to manage CIF queue errors from APO (the source system), then this USERID (destination system) also should be 'interactive', and not 'system' or 'communication'. If you are using more than one RFC USERID to connect to the destination system, all of the USERIDs should be active and have appropriate authorizations. The logon popup you are getting usually indicates a problem with the RFC USERID in the destination system (password wrong, inactive or locked user, inadequate authority, etc).

In APO you can discover the USERID of the RFC connections in SM59 > ABAP connections > select the RFC connection you have assigned to the CIF application > Logon and security tab > the name of the USERID is there. Then, log onto the destination system, and use SU01 to review the authorizations of this USERID.

Your basis team should be able to help you if you are unsure that this userid's authorization meets your needs.

Best Regards,

DB49

[former_member209769]

This was linked to application case setting for RFC. The relevant RFC user was not active. The issue got resolved when this application specific RFC user was made active. Thanks all.

[Former Member]

Hi Pawan

I am not sure if this issue has been resolved. Please check the user type, role and authorization for each RFC user that are being used. You may get the RFC user name when you double click on on the RFC Destination in TC SM59. The symptoms indicate an inappropriate authorization for either the user (who tries to see the queue details) or the RFC user. You may want to also execute TC SU53 to see whether this is an authorization issue. I believe your Basis and Security team will be able to help you.

Thanks,

Prasun

[brian_lord]

The user ID on the RFC destination is set as a dialog user. You can change this to a system user or another sort of trusted user where login credentials are stored or not needed.