NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER, ACCENTURE.
DIFFICULTY LEVEL: INTERMEDIATE
Assumes having taken the class SSNF and has good intermediate level of knowledge and/or familiarity with Scripting in ServiceNow.
In my just republished article Mini-Lab: Writing Entries Into the System Log Using Ajax and JSON I outline a method for writing log entries from the the Browser-side of ServiceNow to the System Log on the back-end. In this article I will show an alternate method when working with the Client Script.
That article describes a Global UI Script that is loaded whether you use it or not. Not necessarily an optimal method as it adds to the load time and might degrade the user experience of the form. The new method only loads the UI Script on-demand.
So in this example we use everything exactly the same as in my last article with the exception of the Client Script.
1. If you worked through the previous article's example you will need to, first, go out and disable (active unchecked) the syslog Example Client Script.
2. Create a new Client Script:
a. Name: syslog OnDemand
b. Table: Incident
c. UI Type: Desktop
d. Type: onLoad
e. Active: checked
f. Inherited: unchecked
g. Global: unchecked <-- this is important!
h. Description: System Logger OnDemand Example
i. Script:
function onLoad() {
try {
ScriptLoader.getScripts('LoggingUtils.jsdbx', followup);
}
catch (err) {
alert(err);
g_form.addErrorMessage('---> [CS:syslog example] Error with getScripts: ' + err);
}
function followup(result) {
var incidentNumber = g_form.getValue('number');
alert(incidentNumber);
var userName = g_user.userName;
g_form.addInfoMessage('---> [CS:syslog example] Made it to here');
try {
// Test the simple logging function
log.info('---> The form has finished loading and is ready for user input. Incident: ' + incidentNumber,
'CS:syslog example');
// Test the complex logging function
log.info('---> Test {0}: form has finished. userID = {1}, incident = {2}', '1', userName, incidentNumber);
log.error('---> Test {0}: form has finished. userID = {1}, incident = {2}', '2', userName, incidentNumber);
}
catch(err) {
alert(err);
g_form.addErrorMessage('---> [CS:syslog example] Error with followup: ' + err);
}
}
}
Your new Client Script should look like this:
3. Click the Submit button to save your new script.
4. Make no other changes.
Unit Testing
1. Navigate to Incident -> Open. The Open Incident list view will be displayed.
2. Choose an open Incident (click on the incident number to open the form).
3. Navigate to System Logs -> System Log -> All. The System Log will be displayed.
4. Order by Created Date descending.
5. Filter the Message column with: *--->
6. Note the three new entries. Your results should look something like this:
You should see the exact same results as before.
So what are we doing here? We are implementing an on-demand model that only loads the UI Script when we are actually going to use it. The Client Script is not always loaded (thus no Global). The down-side is that this has to be done wherever we use the UI Script; so not quite as pretty as the previous solution. However, this is a best practice if you don't want your rather large UI Script library loaded just-because. Also, this is the ONLY way you can use UI Scripts in a scoped application. For a much more in-depth explanation as to what is happening here see my series of articles:
Mini-Lab: Converting a UI Script Library From Global to Scoped - Part 1
Mini-Lab: Converting a UI Script Library From Global to Scoped - Part 2
Enjoy!
Steven Bell.
If you find this article helps you, don't forget to log in and mark it as "Helpful"!
1 Comment
