Have you ever run into unexpected behavior when making inbound REST calls to your ServiceNow instance? Perhaps the result of a GET doesn’t contain all of the records you expect it to, or nothing happens when you try to modify a record. In this post, we’ll explore some of the options available for debugging inbound REST API calls and the Business Rules / ACLs that might be impacting those calls.
As highlighted in What’s New for Developers in Istanbul - Integrations, APIs, Authentication, the Istanbul release introduced Outbound Web Services Logging. This feature is a major quality-of-life enhancement for anyone working with integrations, and some potential benefits include: Write fewer gs.debug/log/info/etc. statements in your code and simplify the debugging process Quickly pinpoint the source of an outbound HTTP request Look at the history of requests made by a particular integration Analyze the volume of requests made by a particular integration What gets logged?
As highlighted in my New Integration/API and Authentication Features Blog Post, Istanbul introduces two new inbound OAuth 2.0 flows: Authorization Code Grant Flow Implicit Grant Flow These flows allow you to build apps that interact with ServiceNow APIs without needing to be directly aware of an end user’s username/password. Some possible use cases include: Building a mobile (iOS or Android) app that interacts with task records in a ServiceNow instance Building a web application that interacts with ServiceNow on behalf of your users This blog post is a quick tutorial to:
If you’ve used ServiceNow for a bit then you are probably familiar with using Dot-walking to access data on related records. In case you are new to the concept here is the definition and a link to product documentation. From the product docs: Dot-walking in ServiceNow provides access to fields on related tables from a form, list, or script. If the current table contains a reference to another table, any field on the referenced table can be accessed using dot-walking.