Dave Slusher

6 minute read

The Istanbul release is here and as we do, here is an overview of some of the changes relevant to ServiceNow developer. This will be relatively brief, but in the coming days and weeks expect many posts digging into all of these aspects in detail.

Javascript Debugger

istanbul-debug-notice.png

With Istanbul the JavaScript debugger has returned to the ServiceNow interface, completely rewritten and better than ever! Once again you can debug and step through server-side JavaScript code.

The new version of the Script Debugger allows you to set a breakpoint in any scriptable field. In normal operation this breakpoint will be passed without notice but if there is a Script Debugger window open in the same session as the transaction that would hit the breakpoint, it will pause the server-side code. In the Script Debugger you have the expected controls to stop over, into and out of code, as well as continue. Variables can be inspected, and any that are in scope at that point in execution will be available in the right hand pane. The call stack is in the left hand pane as well as extra details about the transaction being executed.

istanbul-debug-window.png

Because the Script Debugger works at the session level, this allows for multiple developers on the same instance to debug without conflict. If you have the Debugger window open, it will only hit breakpoints for transactions within your session. Even Scripted REST APIs can be debugged in this fashion if using the REST API Explorer (otherwise, transactions are not in your session.)

Even Scripted REST APIs can be debugged in this fashion if using the REST API Explorer. Because of the session limitation, you cannot debug random requests coming in from external sources but ones initiated by your browser session either from the Explorer or by directly loading the URL will trigger the breakpoint.

One thing to be aware of is that there is a timeout associated with this. If you have your main transaction paused for over three minutes, the original transaction will time out and give some form of error message, whatever is appropriate in that context. However, the debugged transaction will continue to stay active as long as you keep it there. If you keep it open an extremely long time you may eventually get into timeouts with database connections and other resources, but you have a longer time than just the front end timeout to work with your debugged session.

Automated Testing Framework

test_steps.gif

Istanbul introduces the Automated Testing Framework into the platform. This initial release of the framework focuses mainly on Form activity. The Istanbul release includes a number of pre-built test cases to serve as examples of how to begin to write test cases. There are built in test steps that allow for certain common activities to be chained together into larger transactions. If you examine the included Tests such as “Basic UI Test” you will see that it is composed of a series of these Test Steps, some of them server-side such as “Impersonate User” and some client-side such as “Set Field Values.” In the final analysis, it bundles together a set of actions that emulate a user session executing a transaction against the web interface.

running_test.png

Inside test steps, there is the ability to script logic. This logic can act against the server-side in the form of queries, manipulate client-side variables and assert against the values and states of variables on either the server or client. When composed together these series of steps become the test.

The tests themselves are executed by a special test runner page within the product. When a test is queued up to run, it will wait for a test runner page to pick up that test and run it. This does take a little coordination because multiple active test runners means that it isn’t really predictable which will get it. In order to do browser compatibility type testing, you do need to run through the tests multiple times with different browsers hosting the runner page.

Tests can be grouped into Test Suites for better organization, and Test Suites can be run in their entirety. In addition, Test Suites can have parents and children. Running a parent Test Suite will run each of the child Test Suites, and any failures will bubble up. A failing test will in turn cause the suite to fail, and each suite that contains that will then be marked as a failure. When a Test is added to a Test Suite, there is an option for the run of that Test in that Test Suite to abort on failure or not. When marked, a failure of that test will abort the entire Test Suite.

test_runner_cropped.jpg

Studio Changes

The Studio has a few user interface changes. Unlike the sweeping changes of previous versions, these are more iterative in nature. A few of the highlights:

  • Initially opening it from the Application Navigator no longer displays the “Welcome to Studio” interceptor followed by opening a new window. It now displays the “Load Application” window after which it opens the Studio in a new tab or opens the existing tab if already open.
  • The source control integration now shows a commit history with a list of files in each commit.
  • The Script Debugger can be launched from the File menu inside Studio.
  • Service Portal records can be created with Studio for Theme, Style Sheet, JS Include and Widget Dependency.

Web Services Logging

api_usage.png

With Istanbul comes new tools to examine the use of integrations, both inbound and outbound. There is now additional logging available for outbound REST and SOAP requests. Once configured, outbound HTTP requests are logged at the level of detail in the configuration. This is true not only of REST requests but also any requests made via GlideHTTPRequest and GlideHTTPClient as well. These logs are available at System Logs > Outbound HTTP Requests.

At a different level of detail, the inbound use of APIs can be examined. This is not a per-transaction log like the outbound requests but an aggregate level of detail that tracks API and resource usage. This can be viewed a number of ways, such as API or resource usage over time, API or resource usage per requestor, etc. This can be a good tool to understand the impact of external integrations with your instance in ways that were not previously simple to visualize.

Conclusion

New release time is always exciting for ServiceNow developers. For some years now, we have had great tools added to the toolkit with each release and Istanbul is no exception. As the days go on, we will drill into each of these topics in more depth in order to spread the word of the power available to the developer. Dig in, and let’s build something great!

For more information on a parallel track, josh.nerius is covering the Istanbul features from that API and Integrations perspective. He has an Istanbul Overview of Integrations, APIs and Authentication features and more posts coming soon!


Comments