It's all well and good when you know various URL tricks to navigate around the UI, like Getting your ServiceNow URLs right, Examples of navigating by URL, Navigate by portal URL, and more ), but do you really know what's happening behind the scenes when you request a resource from ServiceNow? Nooo. No, no, no. I'm not talking about the Client/Server Model. What I'm talking about is when you make a request like https://instancename.servicenow.com/incident_list.do, do you really know what that process is for the Instance to bring back a list of records on the Incident table? Or even why the list is not displaying at all when it should (yes, we have received these Incidents)?
It is important to understand what questions are being answered when calling a list of records as to avoid a disaster like hindering your users from getting the information they need. You wouldn't want to prevent your employees from utilizing the platform's system and data because you created a UI page called incident. Would you? I didn't think so. Let's discuss how this process works so that your company continues to function efficiently.
How an Instance knows what to display
There is, indeed, a process. Similar to how Access Control Rules work, the platform is trying to answer a few questions. As soon as there is an answer, the platform stops asking the other questions and renders the respective output for what it just found. Here's the questions in their respective sequence:
- Is it a Processor?
- Is it a UI Page?
- Is it a File-based Jelly form template?
- Is it a table?
- Is it a table with a suffix?
Is it a Processor?
Processors are endpoints that would allow you to run arbitrary Javascript code (server-side) and can make calls to Java classes. For example, if you watch the HTTP requests in the browser console, you're probably seeing quite a few angular.do transactions and wondering where they go. Go ahead and navigate to the System Definition > Processor module (or, if you live by efficiency, head to the sys_processor table), then filter the list with [Path] [is] [angular]. Done? Or are you waiting for me to give the answer?
You will see a record with the name AngularProcessor. In that record, you will see that the Type is java and the Class name is com.glide.ui.ng.AngularProcessor. This particular processor will execute some Java code found in the specified class name, which in this case is com.glide.ui.ng.AngularProcessor. We are interacting with processors almost every day and probably don't even realise it.
Want another example? Sure. Attachments! Yup. Have you ever noticed that when you're looking at records in the sys_attachment table, you click on a record but the file is downloaded instead of being taken to the record? If you don't believe me, head over to the sys_attachment table and filter it with [Path] [is] [sys_attachment]. See? Told you. The reason why you didn't get to the record is that the processor question is right at the top of the list of questions.
Is it a UI Page?
If the platform cannot answer "yes" to the processor question it heads to the next one "Is it a UI Page?" That's right... UI Pages. Let's take an example of viewing a Catalog Item or Record Producer. Looking at the URL you will see com.glideapp.servicecatalog_cat_item_view.do. Kinda looks like it may be a processor, right? Go ahead and look for it in the sys_processor table like before (without the .do). Didn't find it? That's okay. Let's have a look in the sys_ui_page table, but this time searching on the Name column: [Name] [is] [com.glideapp.servicecatalog_cat_item_view]. You should now have a record in the list, where you can now inspect the Jelly code of how Catalog Items/Record Producers are rendered. Have a look around and you will probably find some other familiar UI Pages or create your own.
 | You could try to create a UI Page with the name of sys_attachment, but the processor will still take precedence. |
UPDATE:
Not sure when this was introduced, but there is another way to call up a UI Page. There is another field on the table called Endpoint, which would contain the scope and the name to call the UI Page.
For example let's say there is a UI Page in the HR scope called checklist_dialog, the endpoint would be sn_hr_core_checklist_dialog.do.
Keep an eye out for this in case you are having issues within a scoped app.
Is it a file-based Jelly form template?
Next up, is Jelly code which is stored as XML files on the Application Server. Jelly pretty much behaves like UI Pages, but you cannot reach the actual code and touch it. For example, whenever you navigate to Reports > View / Run, the URL for the Reports homepage will look like report_home.do. Go ahead a look for this in the sys_processor and sys_ui_page tables. No? This will be stored in a folder on the Application Server as report_home.xml. Sorry, people, but:
(I'm so sorry. I couldn't resist.)
 | You could try to create a UI Page with the name of report_home, but that will override the File-based template call... and that would be bad! Just sayin' "don't do it". |
Is it a table?
Let's take that first example I started with: incident_list.do. You can run through the first set of questions and verify that:
- It's not a Processor
- It's not a UI Page
- It's not a File-based Jelly form template
Cool. Now, we know that the first part of this URL snippet starts with Incident, which is a table right? Yes. However, this will not pass the "Is it a table?" check. Why? Because the platform will be looking for "incident_list" in sys_db_object, the table for tables, and we know there is no table called "incident_list" in an OOB Instance.
If, on the other hand, I provided the URL with incident.do, the platform will respond with a "yes" and display a record for this table. So, I will be presented with an existing Incident if there is a sys_id parameter that's not -1. If the sys_id parameter is not there, or has a -1 value, you will be presented with a blank form to create a record.
While I'm here, I should also point out that there is another place that the platform looks, which is the Database Views [sys_db_view] table. For example, taking the OOB database view called incident_metric, I will get a "Yes, this is a table" from the platform.
Is it a table with a suffix?
Finally, I can get a "yes" from the platform with the incident_list.do URL AND get the list of Incidents!
If the platform got here for incident_list, the questions list would look like:
- "incident_list" is not a Processor
- "incident_list" is not a UI Page
- "incident_list" is not a file-based Jelly form template
- "incident_list" is not a Table
To answer "Is it a table with a suffix?" the platform looks for any suffix at the end of the string. As an example, we have "_list", then there's "_search" (used when creating a Search Screen module) and a couple of others. Any text before this suffix will be taken and searched for using the logic in Question 4 (Is it a table?).
---
To recap, the platform will look at the following to answer those questions:
- sys_processor (using the path field)
- sys_ui_page (using the name field)
- File system (using the file name followed by .xml)
- sys_db_object, sys_db_view (using the name field)
- sys_db_object, sys_db_view (using the path field plus suffix0
Taking the example of the "incident_list" URL, we will get a response like:
- Is it a Processor? X
- Is it a UI Page? X
- Is it a File-based Jelly form template? X
- Is it a table? X
- Is it a table with a suffix? ✔
If you've got something in the URL that fails all these questions, in the end you will get the usual "Page not found" message:
(Hello again)
There you have it. Some developers/consultants have created things further up in the list with the same name and end up in a situation where you can no longer access something further down, like a table. This is referred to as overriding and a typical scenario is to create a UI Page to override the File system check or they fail to check if something already exists with that name.
 | If you're not careful, you could create a situation where users cannot get to the functionality/data that they need (like creating a UI Page called incident ). |
However, if you have a situation where you're trying to find where that name.do belongs, you will have some places to look. For those who want to have a further in depth look at the logic, a while back, I put together a script that you can run in Scripts - Background (sys.scripts.do) for Customer Support to troubleshoot related issues (see attachment below). A quick note: I could not find a GlideScriptable function call for the file system check, so that bit is missing (there is a way to do it using undocumented Package calls, but that goes against my personal rule and I am purposely not sharing that to minimize risk).
So, in the famous words of Porky Pig:
5 Comments
