Search for a command to run...
I am a technical architect and ServiceNow enthousiast. Since then I have been obsessed with development and later on application design & architecture. Today I'm using my skills to design solutions for IT companies within the ServiceNow industry whilst in my free time, spent the majority of my time creating applications for all kind of things unrelated to ServiceNow.
No comments yet. Be the first to comment.
SOLID Principles in ServiceNow: Efficient Development Series" - Learn to apply SOLID principles for robust ServiceNow solutions.
The 2nd principle of the SOLID principle is the "Open Closed" principle. The open closed principles instructs us that our code should be open for extension, but closed for modification. By applying this principles we protect our application from brea...
What is the ArchX program? The ServiceNow ArchX program, a 4-week cohort-based program built by ServiceNow for early-career architects. The program aims to teach students how to excell in the world of
Today I successfully passed the ServiceNow Certified Implementation Specialist exam for Customer Service Management. In this article, I will be sharing my personal experience with the preparation, the training material provided by ServiceNow, and my ...
For developers, adopting coding habits is crucial to increasing productivity and enhancing the maintainability of their implementation solutions. This article will cover 5 must-know skills every ServiceNow developer should master. 1️⃣ D.R.Y (Don’t ...
Learn the Best Situations for Scoping and What Needs to Be Scoped
Understanding ServiceNow's Conditional Table Query Range ACLs
When I set up my script includes for an application, I carefully think about the single responsibility to get optimal application design. Single responsibility is one of the five principles of SOLID.
Note however that applying all the SOLID principles is not quite possible within the ServiceNow platform.
Giving every script include it's own specific responsibility will drastically improve your development experience within the platform. At a certain point you will realize that some code becomes very repetitive but is not generic enough to be migrated to another private function.
In this case, consider moving the logic towards another script include.
Take the following example:
| Name | Responsibility |
| OnboardingService | This script include contains all business logic for the onboarding process. |
| OnboardingServiceREST | This script include is processing and interacting with another HR onboarding application using REST. |
Because we contained all REST specific logic within it's own script include, we reduced the risk of breaking anything that is not REST related.
Whenever you identify a functionality that does not belong within the script include, consider creating a new script include for it's purpose.
This doesn't mean you have to create script includes for every individual functionality. Carefully think about the end goal you are trying to achieve. It's very easy to over engineer this and create script includes for every single thing.
I often hear from others that I am creating script includes for no particular reason. I do in fact consider creating many scripts, but I use the following rule to decide if it's worth creating a new script include:
If the logic has a purpose that doesn't belong anywhere else AND that purpose is high likely to be expanded afterwards with similar functions, it means it can be transfered to another script include.
Some more examples I personally apply:
| Script include | Purpose |
| IncidentService | This script include contains all business logic for the process. Whenever anything changes in the business logic, we know we should be able to find this here. |
| IncidentServiceRefQual | Script include containing all functions only being called by reference qualifiers. We separate this from the normal IncidentService because these functions will all expect the same input (being the current record), but also because they all have one thing in common, they all return an encoded query (which is needed for the reference qualifier). |
| IncidentServiceSchedule | Containing all functions that will be called from a scheduled jobs. Although this sounds useless, Scheduled jobs are NOT captured in update sets and changes are NOT tracked. If we would accidently update our scheduled job we would have no way to revert the changes. To overcome this issue, we contain all scripts being called from a scheduled job in it's own Script include. If we ever accidently update our scheduled job, all we need to manually type is 1 line of code, all the actual logic is contained safely in our Schedule layer. |
Maintainability
Separating logic across different script includes ensures that everything remains very maintainable. Whenever a particular part of the application has to be expanded or changed, you know exactly which script include to open.
Prevent bugs
Each script having it's own responsibility will reduce the chance of introducing bugs potentially breaking your application.
Reduce conflicting development
If all code would be present in one script include only, the chance that you will come across a moment where you and someone else require to work on the same script will drastically increase.
Every customer, environment and ideally developer will have it's own way of setting up the scripts. What matters most is that in the end, not only you, but also others should be able to read and maintain your code, and understand what is going on.
I personally use these principles as the foundation of a more expanded thought process, for which I still today on a frequent base see extra use cases popping up, fitting the puzzle pieces together.