ServiceNow Service Portal vs. the World: separation of concerns
A fundamental principle of software development and architecture is the notion of separation of concerns.
The basic idea is to avoid co-locating different concerns within the code. For instance, the application business logic should be separated from presentation logic. This is a fundamental principle in a commonly used MVC (model-view-controller) architectural pattern.
With no doubt, the separation of concerns principle results in a simpler code and better maintainability.
How does it apply to ServiceNow Service Portal? (…or does it ever apply?)
Widgets
A widget is a building block in Service Portal. Everything is built with widgets.
At first glance, a Service Portal widget is a pure implementation of MVC pattern and a principle of separation of concerns. It specifically separates HTML/CSS code, controller/server scripts, and then stores everything in one single widget record.
Having everything in one record can be beneficial when you need to build something simple and very quickly — that is a foundation of Service Portal.
However, the idea of everything in one record is a breaking point.
Once you start building advanced functionality with custom representation views and non-trivial data management, you will see that separation of concerns does not necessary apply in ServiceNow widgets. That is because everything you touch is stored and managed in one single widget record.
Even more, someone could say that Service Portal widgets work against the separation of concern principle.
That is how a rollercoaster ride begins.
Service Portal vs. the World
Having everything in one single widget record often becomes a critical problem for development teams. When developers try to collaborate on the same widget, they are struggling to keep their code in sync and constantly wipe out each other code changes.
The cause of conflict is the way how ServiceNow works + Service Portal development paradigm: building a Service Portal widget is a one-person show, you cannot have multiple people working at the same time on the same ServiceNow record(widget).
It may not be an issue if one person can handle HTML/CSS markup and a sophisticated data management logic. However, it becomes a huge pain point for development teams, who create and maintain advanced web applications.
Service Portal development paradigm, in most of the cases, does not allow effective collaboration on a widget code. Even if you have a presentation layer and a business logic separated (in a code sense), you cannot effectively manage it with multiple developers, because it is still one-single-record and therefore one-man show.
Solution (?)
There might be multiple options on how to address the separation of concerns in Service Portal. The basic idea is to manage front-end (html+client side) and back-end (server code) separately.
This may sound a bit strange (if you have never experienced the “surprise” point from the chart above) but:
Do not write business logic in a widget server code. Use Scripted REST API instead. Replace your server code calls in a client controller with REST API calls using a standard
$httpor custom angular providers.
Managing server-side logic in a custom REST API gives you the ability to utilize heavy and complex business logic in a simple widget.
It also allows building web apps collaboratively — when one person is working on a representation layer (client) and another person is building data interfaces. Even if you are a single person working on a widget, this approach gives you better code management and significantly improves code maintenance in the future.
Summary
Service Portal works incredibly well and may be the best option for simple web apps.
On the other hand, advanced web applications may require some adjustments in the Service Portal development approach to address the principle of separation of concerns. Furthermore, some ServiceNow development trends suggest that in many use-cases it might be beneficial to go beyond standard Service Portal options, and build web applications using modern web development paradigm.
