While working with a client recently, I ran into an issue where the Edit Request Offering form in Service Manager would lock the console. The console would increasingly consume memory on the Management Server without stop, and the only way to recover was to kill the console process in Task Manager. This would only happen on certain Request Offerings (ROs) and it was to the point where one could not even open the RO to make modifications.
After a good deal of troubleshooting, we were able to pinpoint the issue. Service Manager keeps track of the relationship between the RO and every Work Item ever opened by that RO. So when you open the RO form, it will go and populate the history tab to reflect all of these opened WIs.
Depending on your grooming settings for Change Logs (Default is 365 days) and how often a RO is used, the form could try to load tens of thousands of history records. That's a big history tab!
Now that we know what the issue is, how do we get this fixed? There are a couple of options. One could modify the Change Log grooming to be much more aggressive so that the number of history records that need to load in the RO form are manageable, but this really isn't a great solution since that would change the grooming on every object in the CMDB.
The second option is to configure some custom Change Log grooming that just purges the history logs of Request Offerings. To take it a step further, we may not want to purge the history records of a RO that relate to property changes, but just the history records that relate a Work Item to a Request Offering.
So, to setup this custom Change Log grooming, simply follow the below steps:
1. A few months back, I published a blog series on how to setup custom Change Log grooming (found here
). The first step is getting this setup in your environment.
2. Modify the given query to include the following variable declarations. Notice that the second variable is set to 0. This is where you can set, in minutes, the retention period. By setting the value to 0, no records will be preserved.
3. Add the following line of code to the query in the appropriate spot as indicated (after the non-highlighted section).
4. Add the following code block to the query in the appropriate spot as indicated (after the non-highlighted section). What this code block is doing is finding those history log records where the change is a relationship change (add or remove) and the Request Offering object is the target of the relationship (e.g. System.WorkItemRelatesToRequestOffering)
And that's all there is to it. Using this approach to grooming the change logs associated to Request Offerings will ensure that even if a request is used heavily, the form will never get to a point where it cannot be opened. I hope this helps.
Until the Whole World Hears,