No Business Services from SCOM in CMDB Portal?
Tom_Hendricks
Customer Super IT Monkey ✭✭✭✭✭
in CMDB Portal
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.
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.
0
Best Answer
-
Geoff_Ross
Cireson Consultant O.G.
@Tom_Hendricks
All I can think of is a Platform_Cache Extension that pulls all the data from all the classes that derive from System.Service and pops it into a single Platform entity set (class) which would give it its own SQL table and oData endpoint.
This could be doable, and I'll look into that. You won't be the only person with this issue.
However, out of interest, do you have the same issue, when you try and view the form for one of these DAs? Because how can you have a custom form (which is done by classname) for each one?
Geoff5
Answers
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
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!
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.
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.
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...?
All I can think of is a Platform_Cache Extension that pulls all the data from all the classes that derive from System.Service and pops it into a single Platform entity set (class) which would give it its own SQL table and oData endpoint.
This could be doable, and I'll look into that. You won't be the only person with this issue.
However, out of interest, do you have the same issue, when you try and view the form for one of these DAs? Because how can you have a custom form (which is done by classname) for each one?
Geoff
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!
Please vote for this - https://community.cireson.com/discussion/5056/improve-cmdb-and-platform-cache#latest