Newly imagined Alert Management within FRUN, open to integration at both Inbound and Outbound, insightful and responsive user interfaces. Part 4 explores the flexible and powerful Alert Reporting, utility of custom pages.
In the Part 1 of this series, we talked about the purpose of AEM within FRUN. We briefly touched upon the very basics of Scope selector and the Unified Shell that are meant for all applications of FRUN. More related to this series, we then looked the at the Overview Page of AEM and mooted on its objective, its powerful Visual Filters.
In the Part 2 of this series, we then moved on to explore the Open Alert List and Alert Search page. Both these pages presented us with the opportunity to arrive at a list of alerts in two or three different ways. It helped us carry out some of the most common actions that we wanted to perform on multiple alerts at one go.
In the Part 3 of this series, we explored the detail contained in a single alert, especially the visual insight into the trend of alert rating via the Rating bar, details of contributing metrics and so on. We also discussed briefly on the alert resolution via Guided procedures, and various other actions that may be taken to handle the alert, all of which are shown in action logs.
We now embark on exploring another interesting chapter of AEM, which caters to Alert Reporting. We would also look at the powerful use of Custom pages.
Each page of AEM seems to address at least one primary business case, and the “Alert Reporting” page is no exception.
This page offers a feast for the analytical minds. If we are tasked with optimizing the alerting content as well as alert-processing practices prevailing in the organization, an important first step would be to discover various trends, however overt or subtle, in the alerts that occurred in the landscape. Alert reporting is aimed at aiding exactly this aspect of alert management.
The small “info” bar included in this page simply says: “Following are some example Reports from Alerts. Create custom pages, add any number of reports per page, use the “Scope Selector for Alert Reporting” for each.”
This holds the key. This is the tiny icon, albeit looking nearly same as the application’s main “Scope selector”, but positioned on top of each report, justifiably, as it influences each report within the main Scope.
While no amount of detailed writing could replace the fun of getting hands-on here, let us try with the basics, at least.
Upon clicking on this “Scope selector for Alert reporting”, we get a pop up, that upfront hints us that it would take us through some intuitive steps.
Essentially, for each report, we would first choose a Time-window, followed by the KPI we want to see the report in the chosen Dimension(s). We would also be able to put some additional filters and have some basic control over the rendering of the report as well.
Once we get familiar with it, going through these steps could feel an overkill. And that has been taken care of, we would see later, how (“Flattened Steps”).
This step suggests we select some time window for the report.
For many reports a total number of the KPI in some dimension is going to be enough. We could view the data, however, split over some units of time as well, within that time-window, such as Daily, Weekly, or Monthly. In this case, we would switch on the “Split By Time” option and choose a “Resolution”, which is the split-size.
This, in other words, would give us the trend of the KPI over days / weeks / months.
We could leave the Resolution to “Automatic” for AEM to decide the most appropriate split size, from ease-of-viewing aspect. Observe the automatic resolution selected by AEM in the example screenshot above, which was “Weekly”, and compare that with the one below, where it is “Monthly”:
The first one had some 20 odd days in the range, while the second example had over three months in the range.
This step is about What we want to get the report on. Typical examples are number of “All Alerts” / “Confirmed Alerts” / “Open Alerts”.
Some KPI would make sense if the “Split By Time” was OFF, as the case in the example above.
Some other KPI would be available for reporting when the “Split By Time” was ON, and some would be available in either case, as the example below.
The choices we make in one aspect of the report influence the choices available for some of the remaining aspects. It is for this reason the “Scope selector for Alert reporting” took a stepped-approach.
Once we have chosen a time window and a KPI, we could tell AEM, in Which dimensions we want the KPIs to be reported on. For the visually cleaner cases where “Split By Time” is not required, we could get the KPI revealed in Two nested dimensions.
This means, the KPI would be revealed in First Dimension and within that, in a Second Dimension.
Assuming we had selected “Confirmed Alerts” as the KPI, “Split By Time” switched Off, and the Dimensions as shown above, for example. This would answer “How many Alerts were confirmed per Customer Network and within each of those Customer Networks, how many Alerts were confirmed per Managed Object Type?”
The rendered report would look as below:
We could furthermore choose to restrict the reported data by applying a few important filters. As an example, say, we want to see the report of the Confirmed Alerts in the dimensions and for same time-window discussed above, albeit only for alerts of category “Availability”:
The resulting data could reduce substantially:
In this last step, fine tuning the Chart Title, Axes labels, options to include or exclude the Data labels and Legends etc. are self-explanatory.
Interestingly, for many cases rendering the two-dimensional chart as a Hierarchical Bar is also possible, as opposed to the default Stacked Bar.
The Stacked Bar may be readily appealing on screen or colored print-outs, while the Hierarchical Bar could be useful when there are too many dimensions and differentiating by clear labels proves better than differentiating by color.
All other usual rendering possibilities that are available with all charts included in FRUN are also possible here, using the ‘Pencil’ icon.
Once we go through all the steps of this Scope selector for Alert reporting and make our choices, we may change our mind and want to go back to some previous step(s). We could jump back-n-forth in any order, after we understand how each choice could influence the others.
This offers ease of navigation for the experts who do not need to specify the choices in a strict “stepped” approach.
The following screenshot captures the flattened “form” that includes all the steps.
By now, we have got a fair idea on how we could get many of these useful reports rendered by making use of vast possible combinations of various KPIs and dimensions within a selected time-window. It would also be a good idea to consider saving different kinds of reports, revealing different aspects of alert handling by our teams, in multiple custom pages.
Once we got familiar with all the user interfaces included in the default shipment of AEM, including the Overview, Open Alert list, Alert Search and Alert Reporting, we would be able to extract the maximum power and flexibility of the Custom Pages, a hallmark for all applications of FRUN.
These personalization-friendly custom pages are persisted across browser sessions, even system restarts, and avoids a lot of repeated work in the long run.
In this write up, we would not go into the tiny details of how these pages could be built up, and rather assume that the reader has taken a look at this well-explained short video (less than 3.5 minutes), using any of the applications of FRUN, as an example.
This video has covered most of the personalization possibilities generic to all FRUN applications, such as how do we add a custom page, give it a name and icon, save it for the current user or as a “Public page”, customize the layout by splitting the page and / or using different grids and so on.
Once the page is prepared, one of the “Available Views” could be dragged and dropped on each unique section of the page. These “Available Views” are coming from the application under question, AEM in this case.
As we can see in the screenshot, all the views we have seen so far in AEM, including the most flexible “Alert Reporting”, are also available for custom pages.
Why would one pick from these, if these are already available as pre-shipped?
Well, in a custom page, the same view could have Scope, Filter etc. of its own, which could be same as the Global Scope used by the application, or entirely different.
Apart from Charts, the tabular lists could also be meaningfully mixed up.
Following are some example Custom pages, limited only by our imagination!
A page bringing a summary of the current work load, in terms of Open Alerts.
Another page, bringing up the Top alerts, not necessarily all Open, from recent past:
Yet another page could focus on alerts from certain categories only, e.g. Availability and Performance.
Essentially, when we have to think of our priorities in terms of alert handling, there could always be a custom page that answers important questions on a given day, or over many days.
The next one, Part 5, and the last one for now in this series, would be a short glimpse on Notification and generic Outbound Integration mechanisms of AEM.