locked
Create a view - Service Requests and Incidents RRS feed

  • Question

  • Hi all,

    I have a Service Manager 2012 environment that has gone through an in-place upgrade from SCSM 2010.

    In the SCSM 2010 environment, Service Requests were implemented by extending the Incident class with an attribute that would denote whether the work item was an Incident or a Service Request.

    In SCSM 2012 I would like to create a view that would combine the SCSM 2010 "Service Requests" with SCSM 2012 Service Requests.

    Is it possible to create a Type Projection that performs the job of an SQL UNION statement?  If I was doing this in SQL, I'd be writing a query similar to the following:

    Select *
    From ServiceRequestDim
    
    Union Select *
    From IncidentDim
    Where ServiceRequestType = 'Service Request'
    

    (Obviously, some mapping of attributes between the two class types would be needed...and perhaps that's the reason why a type projection of this sort would not be possible...)

    An alternate approach - attack this from the Work Item class.  It's trivial to create a view that contains Service Requests and Incidents - just set your criteria to be: ID begins with 'SR' or ID begins with 'IR'.  Unfortunately, that criteria returns all Incidents, and I only want the Incidents that have the attribute ServiceRequestType = 'Service Request'.  Is it possible to create a Type Projection starting with the Work Item type that employs criteria from child classes?

    Monday, December 15, 2014 2:23 AM

Answers

  • Work Item is an abstract class, and can't be extended for implementation reasons. 

    i think Anders has understated the difficulty of combining these views: this is a bit like saying "show me all the orange things, given this bucket of cats and this bucket of fruit" yes, they are both "orange", but fur is not the same as fruit rind; they're not the same "orange".

    the 2010 Service Request implementation was never intended to be a serious use case (i assume you're talking about the SCSM Service Request demo implementation on codeplex), it was intended to be a demo of what you could do with the form and object interfaces. 

    The solution here should be simple, convince your client that their solution has been replaced by a newer, better version, Resolve Close and then deprecate these requests, and start reporting only the new type requests. these are history, and dirty data, and should be ignored. 

    • Marked as answer by Adrian Salone Tuesday, December 16, 2014 1:14 AM
    Monday, December 15, 2014 2:01 PM

All replies

  • I dont think that is possible (you could write you own view ofc.)

    It is sort of like saying: I would like all the red apples and the yellow oranges, but I will only look in the basket with apples.

    A view in Service Manager consists of multiple parts, and one of them is the ItemsSource in which you are giving a QueryParameter, ex. System.WorkItem. And the adapter doesn't seem to be able to accept more than a single parameter (ie. just a single basket).

    I am sure Aaron or Anton can explain how it actually Works, and tell you if it is actually possible.

    I would start looking for other solutions. Do you really need a view showing this? The service request in it self is not that interesting, but rather the activities it contains.


    http://codebeaver.blogspot.dk/

    Monday, December 15, 2014 9:32 AM
  • Thanks for your reply Anders. This is not a show stopper for me but it would be nice to be able to twist Service Manager in such a way that I can display this info.

    I suppose another solution is to extend the Work Item class with a 'Request Type' attribute, and populate that attribute with the value currently stored within the Incident 'Request Type' attribute.

    That's actually not too bad a solution and if I can't talk the customer out of it, then perhaps that will be a technique to employ.

    Monday, December 15, 2014 12:45 PM
  • Work Item is an abstract class, and can't be extended for implementation reasons. 

    i think Anders has understated the difficulty of combining these views: this is a bit like saying "show me all the orange things, given this bucket of cats and this bucket of fruit" yes, they are both "orange", but fur is not the same as fruit rind; they're not the same "orange".

    the 2010 Service Request implementation was never intended to be a serious use case (i assume you're talking about the SCSM Service Request demo implementation on codeplex), it was intended to be a demo of what you could do with the form and object interfaces. 

    The solution here should be simple, convince your client that their solution has been replaced by a newer, better version, Resolve Close and then deprecate these requests, and start reporting only the new type requests. these are history, and dirty data, and should be ignored. 

    • Marked as answer by Adrian Salone Tuesday, December 16, 2014 1:14 AM
    Monday, December 15, 2014 2:01 PM
  • Ah yes, I keep forgetting that abstract classes cannot be extended. Oh well...

    Thomas, thanks for your reply.  There always comes a point where one should realise that one is pushing Service Manager in directions it was never meant to exist, and I think this is one of those instances.

    Best to not over complicate things.

    Tuesday, December 16, 2014 1:15 AM