ServiceNow Advanced Scripting:...

Ruth Evans 1 posts since 03-Aug-2017

ServiceNow Advanced Scripting: Maintainable and scalable development 06-Oct-2017 03:28
Development in ServiceNow may seem somewhat simple;
Javascript is accessible
The ServiceNow Framework is straightforward and (arguably) forgiving
The API is clear and comprehensive (Server API, Client API)

But when it comes to important pieces of code, their maintainability and efficiency become an important subject,
and some parameters may interfere such as;
Initial business need level of detail
Integrator experience with coding good practices and technical architecture
Multiple modifications of business needs

I wanted to show with a concrete use case an example of integration, done fast Firstly, and done correctly in the
second time (at least the best way possible to anticipate changes and facilitate maintainability).

The initial statement

Lets say your customer writes a story along those lines:As a Service Desk operator, I want the impact of an
incident to be set automatically from the Business Criticality of the Business Service. I want it to be dynamic,
immediately as I select the impacted Business Service.

The fast & easy (in theory) method

You may be tempted to do it the fastest way possible
since the functional need described here seems
simple. If you take it literally you can do the following
client script and it will meet the requirements stated
in the story;
Build a mapping between criticality and impact because these are not the same values.
Retrieve the criticality of the Business Servicenow online training and set the impact to the mapped
value.

Now, during the first testing phase your customer may come back to you saying the integration works well when
updating the incident from the form, but not when the Business Service is updated from the list.Also, it doesnt
work when an incident is created/updated by web services (for example through REST from a vendor managing

1
ServiceNow Advanced Scripting:...

the network incidents).You may want to fix this as fast as possible by creating the same script as a business
rule when Business Service changes and is not null.

"Fast method" analysis

What are the issues with those two scripts?
First, the most visible and immediate impact; the Client Script is using a get reference which is a
synchronous call to the server and retrieves the whole Business Service record while we are using only
its Business Criticality. The synchronous call may cause latency and bad user experience, and it is not
optimal in term of data transactions between the server and the client.
Then, a more long term impact; you duplicated a script, even if one is client side and the other is
server side the core functionality is the same. The impacts may be:

1. Inconsistency; Your scripts may act differently and your rule would not work the same through client
interface and web service / automatic update.
2. Troubleshooting issue; your scripts may be bugged and you would have to check both.
3. Maintainability issue; You may need to update the rule (the requirement may change, a new impact
value may be added for example), then you would have to do it two times.

The "good" method

Every time a story is expressed, you need to ask yourself and to the customer; is it a business requirement
or a comfort feature? Your customer may express it as a comfort feature, or you may interpret it as it if the
expression is not detailed, like in our previous example, but you really should clarify this with the customer.If it
is only for comfort and requires client side customizations, validate with the customer the pros & cons. It may
impact performances and global user experiences, or not. Then no problem, you can go ahead and build your
client script.If it is actually a business requirement with the added value of dynamically applying it, the following
should be applied to ensure best maintainability and scalability.

The API
First, you have to build your core business. To do so, you need to define what is the core of your business need.
In this example, we could say I need to set the impact from the Service criticality.The proper way to do it is to
centralize your business intelligence in a unique script include for a given group of developments; for example, a
script include per process is a simple way to clearly separate your code. This is your "API" for this process.

The Business Rule

Your business rule here is actually the application of
your function to the business, in the right conditions.
The conditions in the When to run tab are the same as before
You call the function from your API instead of doing your business intelligence here

You can add an info message, which is just UX comfort; you notify the user of what happened and how.

2
ServiceNow Advanced Scripting:...

The UX added value

The dynamic/client side part should be taken as an added value. The Business (server side) is what matters,
and so, the Client side should only use the API without impacting it nor risking any discrepancy.The CLIENT/
API InterfaceThis piece of script is just an interface between the client and the API, its only aim is to provide
a way to access the API through the client. This script include is client callable, and its functions will call the
matching function from the server API. You can give it the same name as they are defined locally within their
class.You may also add here some specific code if you need to handle the result in a different way because it
is client side, but globally it should do the same thing. This Script include is your interface between the API and
the client side processing, use it to retrieve and adapt the API results.The Client script: Dynamic execution of
the businessThe client script will be able to call this client callable script include to get the same behavior as
the server.This time, your client script:
Doesnt use a GlideReference since only the Business Service value is needed as a parameter for the
function, and you get your result from an asynchronous ajax call.
Uses an already defined function within your API (through your client interface)

You just have to exploit the result of your business

function within this client script, as the business rule
did (the only difference being how you handle the
answer since its retrieved through AJAX XML).
Conclusion
Now if your customer tests the functionality, it will
work the same for:
Standard user interface and list edit
Web services
Import / Automatic update

If you need to update the rule (for example, a new level impact 4 is added and you have to update your
mapping accordingly) you will only have to change it one time, in your API.
If the customer changes his mind and want to deactivate the client side (e.g for better performances), you just
have to deactivate the client script.
Tags: online, course, online training, online courses