This one comes up pretty often – a customer creates a new incident view and uses the Incident (advanced) combination class (aka “type projection) as the target for the view. Then the performance of the view is really slow. This blog post will explain why and what you can do to improve the performance of views.
If you need a refresher on type projections please see this blog post:
If you use the Incident (Advanced) type projection for your view you are able to query by all these relationships (below) and you can use them as columns in a view (so long as the relationship type max cardinality is 1 and the object you want is only one “hop” away from the incident).
So – that has pretty much anything you could ever want to query about or display related to an incident. Perfect right? No!! While it is very flexible it also means that the UI is going to pull back all that related object data
even if it is not going to be displayed in the view!
Action logs, related configuration items, billable time, etc. are not things that you can’t even display in the view. This is why views targeted at Incident (Advanced) are slow – because they are bringing back all this data.
If you want a fast view you need to use a type projection that includes
only those components you need to query by and to display in the view
. These are the type projections that we provide out of the box in SCSM 2010:
Incident (advanced) is intended to be used for the incident form only. You really don’t want to use this for a view.
Incident (portal) is intended for use by the portal and only gets a limited set of data. This is the list of components (or relationships) that the portal type projection has:
This is still too many for most purposes in a view.
Incident (typical) is a good choice for views because it includes the affected user and the assigned to user component which are commonly used in view criteria or view columns.
There is only one problem with using the Incident (typical) type projection. It is in an unsealed MP for some reason so you can only use it if the view you are going to create is also going to be stored in the same MP (Service Manager Incident Management Configuration Library) as the type projection. If you create your view anywhere under the out of the box Incident Management node then your view will be in that same MP and it will be fine.
If you try to use the Incident (typical) type projection in a view in a different unsealed MP you’ll get an error message like this:
If you create your view someplace else in the tree you’ll need to create your own folder in your own MP. At that point you can only use type projections which are in some other
MP (or in the same MP as your folders/views).
You can do that yourself by opening the XML and creating a type projection that looks like this:
Just to make things a little easier I’ve created an MP (attached) that you can just import that has a bunch of different type projections you can use.
: Use the most “narrow” type projection that you can to get the data that you need to display and that let’s you specify the criteria you need. Using just the incident class itself and not even using a type projection has the best performance.
If you import the .mp file attached there will be a lot more options to choose from:
I also included the .xml file in case you want to add some of your own or modify the ones that I provided.