It is quite common when developing and troubleshooting integrations that a ServiceNow developer may need some logging around API access. This logging can be required in both directions - in outbound API access of some external service or when providing an API for an external service to integrate inward to your instance. In this blog post, we will examine strategies for outbound logging. Log Levels There are three levels of Outbound Web Service Logging: Basic, Elevated and All.
When the Automated Test Framework (ATF) was first released, I published an introductory post about it . I didn’t intend it to be 20 months and several family releases between parts but such is life in the big city. One of the upsides of a slow release schedule is that there are many advances to talk about when you get to Part 2. The introductory post talked about the basics and authoring a test.
One of the bits of ServiceNow development I have found the most challenging is dealing with Credentials and Aliases, specifically those for OAuth2. More then one session of Live Coding Happy Hour ended in failure specifically because of my inability to grasp a) what was happening at all in the OAuth and Credentials data model and b) where I should be looking for any specific piece of the puzzle. Compound that by the fact that our prime use of this is in our YouTube spoke where we wanted to have something in the scope and the spoke by default but I wasn’t exactly sure what that should be .
Reviewing Skipped Items The London release introduces a new tool for debugging upgrades and we will look at an overlooked but time-saving Jakarta release item as well. As a customer and partner, I have done quite a few ServiceNow upgrades. Helping others in the community with their upgrades has been a long-running theme. There are some newer platform features which I think are worth sharing with the community. There are several reference documents for the full upgrade process here.
If you have followed my work as a developer advocate for ServiceNow at all, you will have noticed that I love automated testing. Even before the original release of the Automated Testing Framework, I presented on testing at Knowledge15. This is really a chunk of the platform close to my heart. This year at Knowledge18, Boris BC
It is ServiceNow new release season! With the London release in Early Access, we will cover some of the features newly available to application developers. In this post, I will discuss one very specific topic - new ways in which Flows can be initiated. When originally released in Kingston, there were two ways to start a flow: on change or insert of a record or via a schedule. That has expanded, increasing the flexibility of Flow logic.
It is that time again in the ServiceNow year, new release Early Access season! The Kingston release has just become available to the Personal Developer Instances. If you are eagerly awaiting the new features, you can now upgrade and take them for a test drive. In another post, josh.nerius covered one of the primary features of interest to developers in this release: Flow Designer and IntegrationHub. I am going to provide a survey of some of the other topics.
I’m always excited about every ServiceNow release, but Kingston brings some game changing stuff. This post is a high level overview of three new Kingston features that aren’t just ridiculously cool, they may just change the way you think about development in ServiceNow: Flow Designer, Action Designer and IntegrationHub. Note: for a deeper dive into Flow Designer, see Getting Started with Flow Designer . That intro sounds like click-bait, but I don’t think I’m exaggerating.
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.
ServiceNow provides a number of ways to export data from the platform. All of these methods are simple to use, but something that isn’t always obvious is how to include the Sys ID value associated with a record in the export. Depending on how you plan to use the exported data, having the Sys ID is important. If you plan to do any kind of reconciliation or bring that data back into the platform in the future, having this value is critical.