We have implemented UIM 8.31 and we plan to give performance visibility to our customers of their network devices. We want to create a report template (or dashboard) which contains ONLY a group of interfaces for the user that logs in to UMP.
Let's suppose that the report should show something similar to this:
The thing is that we want to create ONLY a report template, and not one for each customer. So I thought about using, if possible, a system variable associated to the user account. Let's think of an account called CA which can have many users (user1, user2, and so on). But all of those users are part of CA, and any of them should see the same report. That is, the should see a report containing all the devices (and interfaces) that belong to CA.
On the other hand, we have another customer (Facebook lets say), and the users want to see the exact same report, but for their devices and interfaces.
Is it possible to use a variable like $accountName in order to associate the user logged in and the data shown in the report in the filters?
I've seen that there are User Tags (1 and 2) which can be used in the filters when you create a Performance Report as well as in the List Report, but those are defined at the Robot level. We need to create dynamic groups associated to customers, and reports that are associated to $accountName.
This task winds up being somewhere between trivial simple and prohibitively hard depending on quirks you might have.
To begin with, all your data is filtered by the origins that are associated with the user logging in. So if you have one page with a list portlet on it, that list will automatically display only the data the user has authority to view. This might be all you need.
One step more complex, in the dashboard designer, there are global variables that are made available that enumerate the list of allowed origins in a couple different ways - mainly though to be used in the where clause of a SQL query.
If you are stuck though in a situation where origin doesn't filter fine enough, you might be able to generate the necessary filter using the SQL table widget and SQL you provide that maybe joins with another table you create that defines your access restrictions.
It is possible to reverse engineer how the reports, lists, and dashboards are constructed and it;s possible to code something (even crudely in an Excel field formula for instance) to automate the generation of the user specific parts of the UI.
There's also an SDK for formally automating the creation of UIs but I've never gotten that to work - last time I tried, when the script ran and loaded the DLL that encapsulates the dashboard generation calls, it crashed my nas. Not fun to discover that....
If you have few enough users, it might be faster just to create custom pages for each one. At least with the dashboards, there is the concept of a variable/parameter so you can define the parameter once and then use it wherever supported and necessary.
Maybe that's enough to get you started?
We're talking about the same dashboard for more than 2000 customers, most of which only have 1 to 4 devices. So, the use of origins does not seem to apply, as we would need to have one hub per customer. The most useful thing, I think, is to have some attribute similar to the security strings that exist in Spectrum.
The only I found viable is to create a report with filters applied, where "source" contains the name of the customer, export the report as xml, replace the string corresponding to the customer's name and importing the newely created xmls to the UMP somehow (not possible by webservices).
However, I think this should be far easier to do. I mean, ACLs already filter the groups and devices a user can see. Why is it not possible to do the same with the content of portlets?
You could use the qos_processor probe ( qos_processor IM Configuration - CA Unified Infrastructure Management Probes - CA Technologies Documentation ) to set the origin to the appropriate customer. This way you'll be able to separate the customer data without needing a hub per customer.
I didn't dig in enough yet to the qos_processor, but changing the origin would disallow any user that does not have their account associated to that origin to see the devices associated to that origin, right? I mean, what about the platform admins? Would they (us in this caso) still have access to see and manage every device?
I didn't say anything, as I just realized that you associate an account to one or multiple origins. So the qos_processor may be the solution. I will research a bit more and make some tests.
Is it possible to use origins to filter elements in the dashboard designer? How are parameters used? I asked a question recently about it. The specified item was not found.