The Curious case of no response from Search in Agent Inbox

This document is based on my personal experience and

you are most welcome to comment and provide feedback about the scenario and solution.

We were getting complains that the agent inbox search takes a lot of time to show the results and sometimes it times out without showing any results.

Here’s the approach for root cause analysis and the solution that we did.

I believe the Step 1 of the following analysis applies to all the reporting framework and the standard queries which are provided by SAP.

Step 1: To start analysing all the slow search response issues , first is to put an external breakpoint in the method

                    CL_CRM_REPORT_ACC_DYNAMIC -> DATABASE_ACCESS

This method exactly tells the select query which hits the database tables to get the list of guids. We can get to know the joins , number of rows and the where clauses used for the database hit from here. Based on the system in your case there could be a problem due an non-indexed column , a z table or too much data.

I noticed that the number of rows was being set as 5199 in our case , even when the max hits was set to 200.

On debugging I noticed that the system adds 5000 rows to the guid list and the search is getting fired using a combination of system status and the user status.

The following method does this

               CL_CRM_QUERYAUI_RUN_BTIL -> READ_BUSINESS_TRANSACTIONS

Root Cause of Problem: I noticed that the issued lied partly in our customizing , partly in SAP standard customizing and partly in the above logic. The logic in the above method was not supporting the customizing done for implementation.It was adding 5000 rows to the count of guids and after fetching so many guids the transactions were being read and further filtering was being done.

Background of customizing in the system: We had maintained status profiles for the Z transactions and some of the user statuses were not mapped to a system status (that was a business requirement and hence like that).

We had also maintained customizing in the following view to make sure the user status maintained by us are used while searching the inbox status.

SAP standard provides customizing in the view CRMC_IC_AUI_MAP_STA where user status can be mapped to the various status shown in the agent Inbox , there is a flag to mark which all status are allowed to be fetched for the “Not Completed” status in the agent inbox.

Contents of the view CRMC_IC_AUI_MAP_STA

So , now we knew the problem was because the system was getting hit with combinations of system status and user status when search was done for “Not completed” status in the agent inbox. When there was a combination , the logic would add 5000 to the guid list and hence slow down or time out the end result.

One proposal to resolve the problem was the badi implementation for CRM_IC_INBOX_BADI to forcefully set the max hits to 200. This was not a solution for us as the filtering was happening later on and the actual results would have been lesser than 200.

Solution : We had already enhanced the inbox search view for customer specific fields and other enhancements. We had already provided a Z class in place of the standard class CL_CRM_AUI_QUERY_SERVICE to cater to additional customer specific requirements. For resolving the issue , the method MAP_PARAM_1O was updated in the Z class by us to remove the system status from the lt_status_tab for our specific transaction types.

Hope this analysis and solution helps someone. Please feel free to comment.

Regards, Parveen Kumar