As a ServiceNow Admin, it is always a challenge to manage homepages and complaints about them. The fact is, any user can put a few ridiculously slow reports and widgets on their homepage and start complaining. Our life will be much easier if we don't need to manage the users shooting in their foot with their homepages.
Finding the users are easy, a quick filter in the Transaction log for "/home.do" transactions will list the user IDs in a matter of seconds. But before we can help, we need to know which homepage these users are using. This piece of work is labor intensive. Simply because the link from a User ID to their current homepage are not that straight forward, the pieces of information are stored in a few different tables, and they are not that well known or popular in the day-to-day operations.
Connecting the dots manually is certainly doable, but it will take a lot of time for each user ID.
Consider the following manual steps:
Step 1: Find the User ID in the user transaction logs (syslog_transaction table)
Step 2: Find the Display name of that user (sys_user table)
Step 3: Find the sys_id of the current homepage of that user (sys_user_preference table)
Step 4: Find the actual homepage from home pages table (sys_portal_page table)
As you can see we have a long way to go before starting the actual troubleshooting of homepages (well described here, good job Nisha!).
IS there an easy way to do this? Well, if not then we probably shouldn't be here and reading this blog.
The solution is rather traditional, we can leverage an out-of-the-box feature "Database Views" to connect the dots for us. Savvy ServiceNow professionals can stop reading now and go developing your own database views.
For those who are not too familiar with this concept. Here are the example steps:
1> Create a database view with a good name, save it. In my case, I choose "user_preference_homepage" as shown below. Fig 1:
2> When the database view is saved, you can start adding tables into the 'View tables' list. You will only need 3 tables as shown in Fig 1. I'll explain why in a minute.
3> For each table, specify the order, prefix and where clause as shown in Fig 1 and save them.
4> Now you can use the 'Try it' link to see what kind of data is available.
5> In the list view, configure the visible columns as shown in Fig 2. We are only interested in a few columns. Fig 2:
6> Now you can click the sys_id column to directly access the homepage of that user. Fig 3:
7> If you haven't turn on the homepage debugger, now it is a good time. In the homepage definition form, use the "View homepage" link to view what's on this homepage. Fig 4:
8> Now you can do a lot of things to make this page better. Again, you probably want to try a few things mentioned in Nisha's blog "Improving the performance of your ServiceNow homepage"
Now let's go back and ask: Why not link the transaction log table as well? The answer is: probably because the syslog_transaction table have table rotation configuration out-of-the-box. So there are more than just one table physically exist in the Database disk. I guess it was not supported by the 'Database view' feature. Anyway, I haven't been able to get it working with syslog_transaction table. Please leave a comment if you do.
As the admin, or admin team, scanning the syslog_transaction table is our daily job. If you get regular complaints from users about slow homepages. You should probably establish a routine check of super slow (20 seconds+) homepage transactions, every day or every few days. If you see someone struggling with really bad homepage response time, you should reach out and help them proactively rather than waiting for the complaints.
Hopefully, This article will help you get to the root cause of those slow homepages faster.
Cheers and happy debugging!
Bill Tang@ServiceNow
2 Comments
