IT Monkey:   Click Here to Help Me Build the Agenda for Upcoming Cireson Webinars!

No Business Services from SCOM in CMDB Portal?

Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
Dynamic data pulls in the "Microsoft.SystemCenter.BusinessService" class, which you would think shows you all the Distributed Applications in SCOM that show up in the console under Business Services.  Right?  Wrong.

I think I can see why--none of them derive from this class.  They are all their own, highly-specific class that derives from System.Service.  Ok, so I can pull in System.Service with Dynamic Data, right?  Wrong.  It is not a choice in the list.  My guess is that it is not available because it is an abstract class.

So how would I pull my business services into a table?  What class would I need to point Dynamic Data at?  I prefer to do this with OData, rather than directly query the ServiceManager DB with SQL.

Best Answer

Answers

  • Geoff_RossGeoff_Ross Cireson Consultant Super IT Monkey ✭✭✭✭✭
    Very interesting one Tom,

    A couple of thoughts for now...

    The dynamic data settings, where you choose which classes has the autocomplete, but you can also type directly any string and hit save, so you could try System.Service and see what it does.

    This also uses a contains comparator so you could also try using whatever prefix all your specific classes start with and this will pull them all in. However, this will mean they each get their own table and therefore oData end point, so you won't be able to use the OOB widgets. This is how all the CAM stuff gets synced with just one row in those settings.

    Option 1, is probably the best method, if it works. Thinking as I type, I'm not sure it will as its looking at SQL tables rather than classes, which is why the abstract classes are missing from the autocomplete. I don't know if it supports views, I will find out and if not ask why not as this would solve your issue and many others.

    As a work around, as you mentioned a SQL table points to the System.Service view would certainly work, but then you need to fudge the JS so you can click them and get to the right page.

    Also, I wonder how you are going to manage a custom form for those, if they each have their own class name...

    I fear, I have provided more problems here than solutions, but all good stuff to discus. I'll come back with same answers when I have them.

    Geoff
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    I tried typing MT_System$Service, but that does not work.  It makes sense though, since there is no MT_System$Service table.  (Abstract classes do not have tables?)

    The DA classes do not all start with the same prefix since some of the DA's are from vendor management packs.  There are enough of them that this would be a chore.  But perhaps more importantly, I do not know how I would pull them all into one view if they were in different tables.

    I know how to fudge the JS to get tables to open whatever I want, but my code is fairly brittle and sometimes gets overridden by refreshes (even if I bind properly, etc.).  I'd love to keep things out-of-box if possible.

    I had some hope with your suggestion of looking for a view, but MTV_ has no matches, even though there are TONS of views that start with MTV_ for the managed types.  So it looks like views are completely ignored.  Also, there is no MTV_System$Service view.  My guess is that there aren't any views if there is no table of the same name (even though it would make sense to have one in cases such as this!)

    Is there any other Out-Of-Box way to get these DA's in, and ideally to use the Business Service form rather than their own?

    Thanks for checking on this!
  • Chris_Chekaluk1Chris_Chekaluk1 Customer Adept IT Monkey ✭✭
    You are correct- abstract classes do not have data & therefore no need for tables- they only exist to create properties & relationship types (maybe type projections also??) against in the SCSM class hierarchy.

    My theory/expectation for the reason DA's are singleton classes (a class that can have one and only one object instance) is because each DA's will always have a unique set of SCOM components being monitored.  Otherwise, if they had the same components, then they would be identical DA's & therefore no need to have multiple DA's or Business Service's.

    This is certainly not ideal... but I have a random idea for you... with a few *ifs*.  Maybe try using the DW's ServiceDim (or ServiceDimVw). 

    Obviously, you'd need to have a DW, need to rely on the stability of the ETL jobs, be tolerant of ETL lag in the portal UI, able to use DWDataMart as a valid Dynamic Data source, & last but not least, you probably would need to create a custom DIM for each DA (I doubt the vendor DA's would think about the SCSM DW).... and get it to 'bind' to the existing one.

    I haven't tried any of the above yet, so don't know if/how well it would work...  I have done a little custom Dim work in the past, just never with a SCOM DA/Biz Svc.
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    I like the thought process, but the table needs to be in the ServiceManager database, it seems.

    I still haven't solved this.  The closest I have come to solving it is to copy all the DA classes into an object in the BusinessService class.  But I've stopped short because having to duplicate everything that I want to see in a table seems like defeat.
  • Chris_Chekaluk1Chris_Chekaluk1 Customer Adept IT Monkey ✭✭
    Well, for what it's worth, I see the ServiceDim targets the abstract System.Service class, so in theory all services- DA or otherwise should be included... (ETL permitting).
  • john_doylejohn_doyle Cireson Support Ninja IT Monkey ✭✭✭✭
    Have you tried entering 'service' into the Dynamic Data settings page? The text on that page claims that it uses a 'BeginsWith' filter, but the code actually uses 'Contains', so you should be able to enter any text which is common to all the classes you wish to add.
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    @john_doyle, yes, but with no expectation that it would actually work (and it didn't).  The root problem here is that business services, unless created in the SCSM console itself, are not derived from any single class in the MT_[class name] tables.  As @Chris_Chekaluk1 very correctly points out, the data lives in singleton class tables.

    Honest question: Are customers expected to add a new single-record class table for every single service, manually, every time one is added?  And if so, how would we ever hope to pull them into a single, coherent list of services with OData?  The SQL Table widgets are an option, but they never worked quite as well as the OData tables (e.g. "everything" is a work item in those tables, date columns can't be filtered, etc.), so that would be a solid step backwards.

    If we could actually specify a warehouse table in the dynamic data settings, like @Chris_Chekaluk1 suggests, that would be a decent solution.  But we can't.  If we could specify an abstract class so that all it's derived classes would be populated into a cache table of that class, it would be a phenomenal solution (albeit one that admins would need to tread carefully with).  But we can't.

    I really started this thread looking for a hack/workaround/quick fix, but I guess this can only be solved by a feature request...?
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    @Geoff_Ross it does work if I open /DynamicData/Edit/TheGuidForMyDA.  As you say, however, it does get complicated from there.  pageForm.type returns the very specific class of the particular DA (rather than a more generic abstract class like system.service).  Same with pageForm.viewModel.ClassName and ...FullClassName.  

    pageForm.viewModel.BaseType returns an empty string, however.  I'm not sure if this breaks any conventions or not, but this seems like a great place to store a common class from which the form inherits, and to also check this property when applying a custom form template.

    Having to load a separate custom form for each DA isn't too bad for the time being, but I still can't pull all my DAs into a single table for users to browse from, without trying something like your suggestion.  That seems like the place where the focus should be first, IMO.

    For now, I will try a variation on your idea.  I think this could work well until something simpler becomes available out of the box.  Thanks for the suggestion!

Sign In or Register to comment.