I am currently working on a phased project in an Service-now.com instance that will temporarily integrate with an older service-now.com instance until all phases are complete within the new instance.

As I considered my options, I realized that I could use SOAP Web Services to synchronize this data. However, upon careful reading I found a semi-undocumented way to remotely send and retrieve data from another Service-now.com instance in a way very similar to “GlideRecord”.

This Java class is named: RemoteGlideRecord.

Here is a nifty way of querying all of the incidents in the “Demo” instance at Service-now.com using the RemoteGlideRecord class:

A lot of people have been running into a problem where they are using .NET or Java Axis libraries to connect to SOAP Web Services in their Service-now.com instance. Many people neglect to turn off the elementDefaultForm setting in Service-now. The creates problems in some client libraries. You know you probably are suffering from this problem when you send a SOAP request to your Service-now web service and find that you are only getting back a blank response.

I have created a short little video clip that helps you see what you need to do to fix this issue and get your .NET and Java clients speaking to Service-now.

I deleted the errant record, but when I went to examine the table schema in the Table Viewer, I found that the Super Class fields were still not showing up.

After scratching my head for several minutes, I finally went to the Service Now Guru himself and asked him what he thought needed to be done.

He wondered if the information we were seeing in the database schema were simply a cache of old data before the correction that I had made. He proceeded to show me a quick and easy way to flush the database cache. All you have to do is add the following to your base Service-now.com url: “cache.do”. This url will call a script that flushes your database cache.

Sure enough, as soon as I flushed the cache with this nifty trick, I found myself looking at the corrected schema.

Please Note: Flushing the cache can cause system performance degradation until the cache is fully repopulated again.

Let me explain how to use filters and groups with Service-now.com list URL’s.

According to the Service-now wiki on the “Exporting Data” page, you can export a number of records from a service-now table by appending a processor at the end of the URL. For example, if I want to export the records in the incident table as XML, I would format my URL like so:

http://myinstance.service-now.com/incident.do?XML

I could also export it into a CSV file in the following (and similar) way:

http://myinstance.service-now.com/incident.do?CSV

Now, what if I wanted to filter out the results a little bit. For example, what if I only wanted to export the “Active” incidents?

In order to use a filter in your export, you append the following parameter in the URL: “sysparm_query”. For example, if you wanted to export all active incidents into XML, you would use the following URL:

http://myinstance.service-now.com/incident.do?XML&sysparm_query=active=true

Let’s say you also want to only show those incidents where the category field is set to “hardware”. You can add this field to the query by using the “^” character between filter fields. Here is this example below:

http://myinstance.service-now.com/incident.do?XML&sysparm_query=active=true^category=hardware

Now let’s say we want to group those results by priority such that the priority 1 items will all be shown together (and so on for all other priorities). In order to do this, you use the keyword: EQ^GROUPBY just before the field that you wish to group results to. See the example below:

http://myinstance.service-now.com/incident.do?XML&sysparm_query=active=true^category=hardware^EQ^GROUPBYpriority

For an added bonus, you can make all of your exported reference fields show display values instead of ID numbers for their target tables by adding the following parameter to your URL: “displayvalue=true”.

If we wished to do this for our filtered group created in this article, we could simply append the parameter to the url like so:

http://myinstance.service-now.com/incident.do?XML&sysparm_query=active=true^category=hardware^EQ^GROUPBYpriority&displayvalue=true

I recently noticed that when I had large SOAP messages coming through the ECC Queue in my Service-now instance, that it was placing the payload of the message into an attachment record on the sys_attachment table. The attachment was named “payload.txt”.

When this occurs the actual payload field in the ecc queue entry contains an empty xml tag: “<see_attachment/>”

By default, if the SOAP Payload size is over 512KB this attachment method kicks in for the Payload text.

You can adjust the trigger for this by going to your system properties and modifying the following property:

glide.soapprocessor.large_field_patch_max

The field is an integer and it represents the size in Bytes.

By changing the property to be: 2000000, attachments will not be created for ECC Queue payloads if they are under 2MB.

I just completed a new training video around Digested Token Single Sign-on mechanisms and how you set up a service-now.com instance to utilize this method of Single Sign-on.

I will be embedding it into the Service-now.com SSO wiki page later today.

This video is a good primer for anyone looking to learn about Digested Token Authentication regardless of the technology they use.

Sure, Service-now.com is powerful when it comes to the web service, api, and other integration capabilities. Let’s say however, that you just want to create a method by which any HTTP enabled device could create a simple incident in your Service-now.com instance. You don’t want to have to authenticate…you just want to create an incident.

Security concerns – that is beyond this discussion other than to say you are allowing anyone to create a specific incident into your system.

Here is how you can go about enabling your service-now.com instance to allow these types of HTTP -> Incident requests. For this example we will use a “Password Reset” scenario.

Overview of Objective: I want to create an incident for a user that tells service-now.com that we need to reset that user’s password. This will be only through a simple HTTP request (eg. https://myinstance.service-now.com/URLIncident.do?USER=john.andersen).

First off, we are going to create a UI Page that is publicly accessible to the world. We are going to name that UI Page: “URLIncident”. At this point, leave your URLIncident UI Page at it’s default values. Save your UI Page, we’ll come back to it later.

Now we need to make that page a Public Page. In order to do this, you go to the Public Pages module in the “System Definition” application and add one for your URLIncident. (Please note: if your “Public Pages” module is not visible you may have to enable it: See “Activate the Public Pages Module” on the Serivce-now.com wiki.

Of course, a public client-side UI Page cannot talk to our server libraries. However, Service-now.com allows you to write Script Include files that are Client Callable through the GlideAjax library. In this example, we will name the Script Include: “URLIncident” just like our UI Page. Make sure your Script Include is set to be “Client Callable”.

Here is the following script for your Script Include:

This code essentially takes an Ajax parameter (“user_name”) and creates and incident with “user_name” as the caller_id and as the target individual in the short description.

Now we will revisit our UI Page and add a client script to the page so that it will get run when the URL is accessed.

This will be your Client Script for the page:

Now, in order to test your setup, go to a browser that is not logged into your instance. If you had a user with a username of “john.andersen”, and your instance was “myinstance”, you would type the following URL into your browser:

https://myinstance.service-now.com/URLIncident.do?USER=john.andersen

You should be shown a blank page.

Now, in another browser that is logged into your Service-now.com instance, browse to your incident table and you should see a new Password Reset request for john.andersen.

Here is a quick video to demo this in action:

You could Create five Weekly Imports all for a different weekday, but that gets a little cumbersome — especially if you have more than one scheduled data import.

I worked up another way this morning that might be useful. This method will use a Post-Script on a Daily Scheduled Data Import. After it runs the first time it will determine what day of the week it is. If it is a Friday, then it will set the “run_start” field to the following Monday’s date with the same time. This will cause the daily import to wait until Monday to run again. I have a sample script that does this below:

Please use good judgement on this since there was probably a good reason for dis-allowing the extension of system tables.

I finally decided to have my javascript access Java libraries to use a series of Java commands to convert my child node into a string.

For example, in the following XML string I want to extract, as a string, the “vitamins” node:

Here is the function that I came up with:

Now I am able to use XPATH to browse to a child node in an XMLDocument object using getNode(xpath), and then convert that node to a string.