Scripting Best Practices

Mark Miller
A free video tutorial from Mark Miller
ServiceNow Guru
4.4 instructor rating • 5 courses • 38,903 students

Lecture description

In this video, we'll discuss the many different best practices to scripting in ServiceNow. 

Learn more from the full course

The Complete ServiceNow Developer Course

Learn how to develop on the ServiceNow platform!

08:41:44 of on-demand video • Updated October 2019

  • Develop on and customize for the ServiceNow platform
  • The ServiceNow APIs
  • When & where to script in ServiceNow
English [Auto] Hello and welcome to Section 9 becoming a scripting master and this section will go over some important topics that will make you a better service developer. So to start with we'll go over some best practices some general scripting best practices as well as server side and client side best practices. Then we'll take a look at debugging and service. Now then I'll show you how you can validate javascript faster than doing it inside of service now. Also show you some additional javascript tools that might help you. And then we'll take a look at a debugging demo where I'll jump in the service now and will actually debug some scripts. Then we'll cover version control and side of service now and I'll go over some important tips and what to do when you're stuck and need some help. We'll end this section with a demo on version control. All right. So General scripting best practices it's best practice to always add a short description to scripts when available. So for example if a business rule has a short description or description field it's always best practice to explain what you're doing within your script. Since you probably won't be the only service developer for a specific instance especially if the company has the instance over many decades and you move on to another career path it will always help the next person looking at this script to read a simple short description that explains what you're doing in a script while we're on this topic I'll actually skip down to the third bullet to comment your code. This kind of goes hand in hand with the short description. If you have a long and complex script it always helps not only the next person but even you when you come back to maintain it. To comment your code. So if you're initializing variables or if you're calling a specific function or looping through an array it always helps to comment the code and explain what you're doing within your code. You can check out the link in this source here that actually goes to a service. Now wiki page and talks about commenting your code and some of the best practices behind that. All right let's jump up to the second bullet use conditions statements if condition field is available depending on the scripting location. So in order to improve performance it's always best practice to use condition statements if available. So for example on business rules when you specify I want this business rule to run when a record is updated and then using the condition builder you can specify if the state is New if active is true etc. etc.. This will improve the performance. That way if a record doesn't match the conditions the script never gets evaluated. You don't have to spend time actually processing a script. That's irrelevant. In addition to the actual condition builder sometimes scripts have condition fields as well. An example of this would be a business rule. So just above the script field there is a condition field where you can apply similar logic to what a condition builder actually builds. So in this example we have current that get value priority equates to 2. So we're saying run this script. If the current priority is equal to 2. All right. So follow a convention especially for debugging. So if you follow certain coding conventions that might be a little different from the norm that's OK but just make sure you're consistent with it. So when the next person is maintaining the code they don't have to flip flop back and forth between certain conventions. And it can also help when you wrap your code in functions to prevent polluting the global namespace. So what does this mean. Well in this example here this business rule we have all of our code wrapped within an on before function. So it turns out all service now will automatically invoke the on before function. If this condition gets evaluated to true all of our variables that we define in this script are going to be local to this on before function. Now it's not as important in this example within a business rule because they already have their own scope but say in client scripts when you have a long client script with many functions since the client side scope can maintain hundreds of variables. A lot of the times it's important to wrap your code in functions to prevent polluting the global namespace we don't fully understand this take a look at the source link here that will actually link to the service. Now wiki where it explains how to wrap your code in functions. All right so it's best practice not to use hardcoded values. So a lot of the times you might need the value of a specific record so naturally your first instinct might be to copy the society of that record and use that in some type of glide recordset get method etc.. Well it turns out it's actually best practice to instead use a system property which will hold that value and then reference that system property in the script. That way for maintainability you can refer to the system property record instead of locating that in a script and updating the actual script. This can be beneficial when you're referencing the same record many places in different scripts. So it's an additional layer of abstraction where we just reference that one system property and we can make a change. There again there's a link here that will explain how to do so. All right. Next is really for any programming language and that's to use descriptive variables and function names. So instead of doing something like var a equals one bar b equals two it really helps for code readability. When you give descriptive and contextual names to variables so that variable represents a specific counter then do bar counter or var the name of this specific counter equals one instead of just simply a because again you might not be the only one maintaining this code. Generally I prefer longer descriptive names instead of shorter oftentimes abbreviated words just for readability. So for example if the function name was get next value instead of doing something like get an x DHL I would write out the words get next value as the name. So this third bullet is probably one of the more important ones. And this will definitely bite you in the butt sooner or later. So varify a value exists for using it for example and the SO for example and the second image here on the right online 222 we see exclamation commonly referred to as Bang which just takes the opposite of the value returned G.R. dot and text dot mil so we can see here that they're testing that the value actually exists before using it. Again I recommend checking out the link to read a little bit more about this. All right and finally the last one for general scripting is to let the database do the work. When we're doing a glad record query it's best practice to apply any type of filters to the glad record instead of trying to create that logic within scripts. So for example if you only wanted records that had a value in a certain field then you could do that with an allied record. So as long as this field contains something semi the results instead of doing that logic with the actual script right now a bit on server side best practices. So always use glide aggregate over glide record when dealing with aggregates like counts the image below. We can see that they're using glide aggregate to grab the count of this specific query. While you could do this using glad records get row count. It's actually much more efficient to use the glide aggregate. It actually creates a different as well query as opposed to running the script to generate that get row count variable. All right so if you're deleting some type of record or a set of records and something like a background script it's best practice to first log those records to the screen or to the console before deleting them. So say you wrote a nifty script that will automatically delete a certain number of records. Well to verify that your javascript and that your logic is correct. I highly highly highly recommend first logging those records and verifying that those records are actually what you want to delete before running that delete record method. All right. The next one you're glad record secure where appropriate so oftentimes this comes down to a script include where if we're calling a script include from an outside source maybe like a client script we want to use glide records secure to verify the ACLU on a specific record. All right. And finally use script includes over global business rules. This convention offers better performance. So the global business rule doesn't have to load you just store that code in a script include which gets invoked when called. All right now let's go through some client side best practices. So the first is probably one of the most important ones when dealing with client side because service now is software as a service and everything is stored in the cloud. Performance is always an important topic. So it's important to make as few calls as absolutely possible when dealing with things on the client side. If for whatever reason you need to fetch many values after the initial pages loaded and we try using something like the scratchpad or calling one script include being glad Ajax that grabs all of those values instead of making individual calls. Number two do not make synchronous calls. This is bad web application practice so for example using glide record on the client side or the format get reference without a callback. These are synchronous calls. So you're essentially locking up the browser until this values returned. Instead make asynchronous calls. So something like Get reference with a callback or using leide Ajax to call a script include which is holding your glad record. All right so you're glad Ajax when passing data between server side and client side and specifically we want to use Jason when passing data from server side to client side especially if you're passing sets of records. So if you're just returning one value then you don't necessarily have to encode it into Jaison. But if you're turning a set of records maybe a set of incidents that'll save you a lot of time to encode them as Jason de-bug using cancelled out log. If you're debugging client side code try logging into the browser's console to find out what's going on. Avoid direct dominate relation. So if you're within a client script avoid using Jey query or even vanilla javascript to manipulate that down. Instead use the form API to do this this becomes a huge pain point when companies want to leverage the new service portal and some client scripts within the service portal you can actually manipulate the window or document object. This is why it's always best practice to use service now is supported API is over something like J-20. And finally use UI policies over client scripts when available. So if you're ever doing logic to show or hide a few old make it feel mandatory or set a field to read only use a UI policy over scripting that logic and a client script you IPOs can be much more efficient than loading and running many client scripts. All right and finally here are some best practice resources. So in addition to the links I've added and the previous slides here are some additional best practice resources so Service now has a number of best practice pages for coding specifically client scripts business rules commenting best practices update set best practices etc.. Also third party sites like Service now gooroo oftentimes naturally include best practices and a lot of their documentation best practices may seem like a boring topic but I promise you if you follow these it will save you a lot of time in the long run.