|
Those readers who have known ServiceNow a little longer and are more in the role of a system administrator may still be familiar with the "System Diagnostics" homepage.
I always liked that overview, as it provides a lot of interesting information, especially about the health status of all individual nodes (aka application servers) of an ServiceNow instance.
And since we all know that homepages starting with the Utah release are no longer supported, I wanted to convert this particular homepage into a dashboard and save it to an update set for further usage in my coming projects. |
|
But I would not have thought that I would experience three surprises in this adventure and that the way to the finished update set could be so rocky. And in order to avoid that the reader of this article has to go through the same effort, I have attached the finished update set here. With it, the "System Diagnostics" homepage can continue to be used as a dashboard in new ServiceNow releases.
Surprise No 1: The System Diagnostics Home doesn't exist anymore
The first challenge was to find a way of displaying any homepages in my Tokyo PDI, as the respective module (Self-Service -> Homepage) have been removed. And just opening the URL /home.do is not helpful as in most of the cases any redirection is configured, for example via system property glide.login.home.
Fortunately, I still have a customer instance on a San Diego release, so it was no problem to open the well-known "System Administration" homepage and select the "System Diagnostics" homepage there.
Now I had a URL I could use:
/home.do?sysparm_userpref_homepage=3e8f33360a6a803f001e6ab4bdfe584c
But in my Tokyo PDI that page doesn't exist anymore! Why the heck? The strange thing is that there is still a documentation for this homepage and at the bottom of that page my question is being answered:
Beginning in the San Diego release, the System Diagnostics homepage is deprecated. After upgrading to San Diego, you can't edit the System Diagnostics homepage. You can create a dashboard version of the System Diagnostics homepage. By default, new instances do not have a System Diagnostics homepage and you cannot create homepages.
Surprise No 2: A homepage converted to a dashboard is nothing more than a wrapper around the old portal-based technology
The easiest way to convert a homepage into a dashboard is clicking on the gear icon in the upper right corner and then to select "Create Dashboard Version":
Next, a dialog opens where you can choose between creating a new dashboard or adding it to an existing one. In the second case, the homepage is added as a tab to the already existing dashboard.
After clicking on "Create" the dashboard version of the homepage opens in the edit mode. Only in that mode you can hover over the upper right corner of a widget to find widget-related options.
Clicking on the pencil icon opens the editor for the underlying widget content. So let's see what we have there:
Wow, a good old UI page with lots of much loved Jelly code was presented. 🤔
Now my curiosity was raised, and I wanted to know what parts make up this dashboard. For this purpose, you can invoke the "Launch Dependency Assessment" option in the context menu
In the next screen you will be presented with a canvas on which the selected dashboard is visualized with its components and their hierarchical relationships among each other.
The first thing you'll notice is that there is a block for a tab right below the dashboard block, even though there is no tab on the dashboard.
When hovering over the building blocks you basically are offered with an info and a context menu item but not for the content widgets. So the impression that these are legacy components is thus reinforced.
And what you may also notice is that there are no blocks which represent the dashboard layout like the underlying grid structure. Therefore, the question is: Where are the records stored that make up a dashboard? To answer that question, we could start right at the top and open the dashboard record via clicking on "Edit" within the context menu, but that way the corresponding record would be opened in an additional layer which is somewhat unusual:
Another way to reach that dashboard record is going back to the dashboard view and selecting "Dashboard Properties" within the dashboard's context menu:
That opened record at table pa_dashboards (Wasn't there an unwritten law that technical table names are given in the singular form? 😲) looks really simple, and the most interesting part is the related list with all defined tabs (table pa_tabs)
But wait. The dashboard tab record has a "Homepage" field! And when clicking on this, you are redirected to the already known sys_portal_page record of the "System Diagnostics" homepage. That reference in the pa_tabs table is the reason why now a button "Open Dashboard Version" appears on the homepage view:
Now let's go further down the hierarchie and open the "System Diagnostics - New Tab" record:
Apart from the name, the only field present there is a reference to another sys_portal_page record. It is not the original "System Diagnostics" homepage, but a copy, and it contains a related list with the misleading name "Portal" with records of table sys_portal. These records represent properties for the legacy widgets (but not the widgets itself, as we will see later) of a homepage:
Each sys_portal record in turn has a reference list with so-called "Portal Preferences" which store the widget properties like the title or the Sys ID for the UI Page that renders the content.
So that means at the end, ServiceNow did not convert the homepage and all of its components to a new technology, but just wrapped a homepage copy with a pa_dashboards and a pa_tabs record.
So far, so good. And where is the layout information of a dashboard stored? After a while of fruitless searching around, I took a closer look at the pa_tabs record and discovered a reference field "Canvas page" there, which OOTB was not shown in the form view and was therefore added by me to the form layout.
Unfortunately, the label of this field is a bit misleading, because the referenced table sys_grid_canvas is called "Grid Canvas", which is exactly the candidate I was looking for:
After opening that "Grid Canvas" record the related list "Grid Canvas Panes" unveils the grid structure with coordinates and sizes of the related widgets.
And with the "Portal widget" column, the circle closes as these references point to the previously mentioned sys_portal records.
But wait! A homepage also has a layout with a defined grid. So where is that information stored? On instances where creating and modifying of homepages is not disabled yet via the system property com.glideapp.home.deprecate_homepages you have a "Change Layout" button in the upper right corner of a homepage:
For homepages it was only possible to select a predefined layout which was built by a referenced UI Macro. The text below the layout preview was pulled from the description field of that referenced UI Macro.
Based on all the knowledge gained, the following table diagram can now be drawn:
Surprise No 3: You cannot unload the complete dashboard into an update set
After the structures of a dashboard have been brought to light, I just wanted to transfer the whole dashboard into an update set, so I can import it on other instances.
At first, you have to create a new empty update set and make it the current update set. Then open the dashboard record by selecting "Dashboard Properties" within the dashboard's context menu. In the form view of the dashboard record, you can find the option "Unload Dashboard" within the context menu:
After invoking that function, the update set contains the following artifacts:
If you compare this with the diagram above, you will quickly notice that the contents of the dashboard are missing (red boxes), because only the layout structures were exported (green boxes):
What did I wrong? I started searching around and came across two documentation pages which describe how to unload a sys_portal_page record and a sys_grid_canvas record, but it didn't work.
Since the additional effort to manually add the missing artifacts to the update set was manageable, I decided to go this way for now. First, I opened the sys_portal_page record and added all records from the related list "Portal" with the list action "Add to Update Set":
Then I expanded each of the four records in the related list, selected all the Portal Preferences records and added them to the update set via list action "Add to Update Set":
And last all UI Pages which render the content had to be added. For this collect all Sys IDs from the "Portal Preferences" records:
Then I used these four Sys IDs in the list view of table sys_ui_page to look up the respective UI Page records and to add them to the Update Set too:
Now the updated set seemed to contain everything that is required for displaying the "System Diagnostics" in another instance. But after importing, all widgets remained empty:
It seemed that any important artifact is still missing. I had again a look on the "Portal Preferences" record and noticed a reference to any kind of "Renderer":
With the help of the /sysid command from the SNUtils browser extension built by @Arnoud Kooi the missing record immediately could be identified: It is located within the table sys_widgets and is also used for rendering the widget contents in the "System Diagnostics" dashboard:
This also means that the diagram needs to be extended by the sys_widgets table:
After adding the missing widget to the update set and importing it again into the target instance, finally the dashboard worked as expected and as you can see PDIs only have one application node:
The finalized update set can be found in the files section at the bottom of this page.
Addendum
I recently came across thte article How can I see statistics (xmlstats.do & stats.do) for all my nodes? written by @Mwatkins which provides some background information on where the data of the "Cluster Node Status" widget comes from and how to enrich the output with other useful metrics.
@Maik Skoddow great investigation.
Only as a side note: All Diagnostic Pages can be added directly to a new dashboard because they are available under widgets.
