On-The-Fly Event Creation in ServiceNow

Recently I was doing some troubleshooting for an onChange script and trying to figure out why it (or rather it’s event) wasn’t firing. In my digging I came across the code that is responsible for registering events and then kicks off the corresponding scripts. I can’t think of a lot of great scenarios off the top of my head, but perhaps when one field changes, you want the system to then start monitoring for 2 other fields to change (maybe user has to do something in a sequence?); just throwing ideas against the wall but you get the idea; keep it in your virtual toolbox ;).

First we throw our script into a function (should look familiar) only difference to the usual is that we are giving it a name (instead of just “onChange”). In this case we’re naming it “onChange_incident_script” but the name can be whatever you want. Next, we will instantiate a GlideEventHandler object. This object will raise our event and call the script when it fires, it expects 3 parameters: The name of the event handler, the script to run, and the field (in the format of table.field) to monitor:

function onChange_incident_script(control, oldValue, newValue, isLoading, isTemplate) {
    if (isLoading || newValue == '') {
        return;
    }
    jslog('JM: Running Script from on-the-fly event. Original Value was: ' + oldValue);
    //Your code here...
}
var thisHandler = new GlideEventHandler('onChange_incident_impact_change', onChange_incident_script, 'incident.impact');
g_event_handlers.push(thisHandler);

With that said, some of you may be thinking, well why can’t we just use jQuery and do the same thing? Yes, for the most part, however you wouldn’t get the nifty “control, oldValue, newValue, isLoading, and isTemplate” variable data to play with. Just for those curious minds out there, here’s how we could do the close to the same thing in jQuery (minus the extra SN objects):

//we need to use double backslashes to escape the periods in the selector
jQuery('#element\\.incident\\.impact').on('change', function() {
    jslog('JM: Running Script from on-the-fly event. Original Value was: ' + oldValue);
    //Your code here...
});

How to Get the DisplayValue of a Reference on the “Client Side” in ServiceNow

I was working with a client recently and had the need to get the Display Value of a Reference field that was on the form. I didn’t want to have to make an AJAX call just to pull this value (on the server side you would use the “getDisplayValue()” function), and that’s when it hit me. The client already has this value, why not use it? Initially I was thinking about DOM/jQuery which was not going to be ideal. As I dug further I uncovered a little known method to pull the Display Value from a reference field. Drum roll please!

g_form.getDisplayBox('field_name').value

Hopefully this saves someone some time in the future.

How to send REST data using the “PATCH” Method from ServiceNow

REST Example

 

When beginning an integration it is important to identify which capabilities are supported on both endpoints. In my case I was trying to integrate two systems which supported REST but not all HTTP Methods were supported by ServiceNow. ServiceNow supports the following Outbound REST Methods:

GET – Pull records

POST – Create records

PUT – Update records

DELETE – Delete records

Unfortunately for me in this case the remote system’s provided API only supported GET/POST/PATCH as a means to pull/create/update (PATCH usually used to partially update) records on the remote system and unfortunately sending REST data using the “PATCH” method is not currently supported in ServiceNow*. So what if you want to integrate with a 3rd party API that only works with PATCH to update data?

The answer, hope that the 3rd party provides an override method (most Microsoft products) that can be used with “POST” or “PUT”, both of which ARE supported in Outbound REST ServiceNow. In this scenario the 3rd party application has written special logic to handle incoming REST messages that are using one method (POST/PUT), but are checking for Request Headers to determine if the incoming data should be handled in another fashion (in our case PATCH).

The key to making this work (apart from confirming the 3rd party supports this) is in the HTTP Header of your REST Message you will need to set the Request Headers either in your REST Message or via code (depending on how you are implementing your REST functionality). Then setup the method to use POST or PUT so that ServiceNow knows how to send the REST message.

Below is an example of both ways in which we use the POST method to override in these examples; in this example the Request Headers needed were for ContentType and Override:

  • X-HTTP-Method-Override = “PATCH”
  • Content-Type  = “application/json-patch+json”

Here’s our example setting it up via a REST Message definition:

REST PATCH Method3

Or setting it up entirely in code:

var r = new sn_ws.RESTMessageV2();
r.setRequestHeader("Accept","application/json");
r.setRequestHeader('Content-Type','application/json-patch+json');
r.setRequestHeader('X-HTTP-Method-Override','PATCH');
r.setHttpMethod('post');
var url = 'https://integration.url.com';
r.setEndpoint(url);

*Note that PATCH is supported inbound to ServiceNow using REST, but does not support outbound PATCH (even though the REST API Explorer tool will generate non-working outbound PATCH code for you…) as of this post (in Helsinki).

Service Catalog Best Practices in ServiceNow

Crossfuze Service Catalog Example

The goal of this article is to document “Good Practices” that worked well for me through my years of working with numerous clients in creating or enhancing their Service Catalogs. I have divided my list between things that the Business/Project Management should be considering, as well as what the Developers should be doing.

Project Management Best Practices

  1. Strategy
    • Determine your Goals. For most companies this means determining what items will demonstrate the most value to the Business in the quickest fashion
    • Adopt the Agile (iteration based) model. No need to get every feature for every item out on the first pass/iteration. Slow and steady (stability) wins this race.
    • In keeping with the previous point, identify 5 or so Services/Items that are critical to the success of the project/initiative and work on tackling these first; do not try and tackle every service before go-live (or within 1 iteration).
    • Get Buy-in from the C-Level, key stakeholders in the Business, and your primary users (people who will use these items frequently)
    • Always try to keep it simple (think about the Amazon ordering approach) and go with Out Of Box when possible. Yes a Catalog guru can many times make the near-impossible possible, but this usually means it’s complex and will result in manageability issues later.
    • Identify Key Performance Indicators (KPIs) early. If these are not built in (SLAs, Metrics, Surveys, etc.) at the beginning then the information is lost until the appropriate tracking measures are put in place
  2.  Design
    • Design it right the first time, many users will not come back a second time to order if it’s too complicated
    • Keep it simple, ask only questions (via variables) that need to be asked. Don’t just copy a form/item from the old system that was created 10 years ago
    • Make sure the right people are in the room (e.g. Business Analysts, Fulfiller SMEs, etc.) when defining what should be in an item. The key here is to make sure that the items will contain the essential information needed to deliver the requested service
    • Navigation: Consider how users will “find” your items. The two common options are Search (user searches for keywords of an item), or Category “rummaging” (user clicks through multiple category, subcategory sets to find the item). Of the two Search is usually the best choice
    • Don’t ask questions that are already available to you via other places in the system (CMDB, User/group records, etc.)

Developer/Technical Best Practices

  1. Naming
    • Think about the End User experience first when naming your catalog items
    • Descriptions: These aren’t optional. Use Terminology that users know; do not use a bunch of IT jargon that only the cool nerds in the corner use to describe things
  2.  Workflows
    • Avoid combining workflows for multiple items (unless it’s a generic item): sooner or later you will need to break out different paths for different items which becomes a mess if its all the same workflow. Instead, once you have your base workflow, copy/rename it for all the items that will use it; that way you can modify each of them later as the requirements change
    • Double check your code in workflow scripts: if you find an error later after a lot of orders come in, there is no way to force these orders to use a “new/fixed” workflow and thus they may all need to be cancelled and re-ordered (note that the Crossfuze Catalog Turnkey provides an easy method to re-order an item) depending on the type/size of the defect
    • Be careful when using the “Join” utility/activity: this allows the workflow to wait for multiple/simultaneous activities to complete before continuing. If there are “conditional” tasks that never execute (using IF condition activities) then the workflow Join will keep the workflow in a “stuck” state. Explaining this will take a full article which I will be creating soon.
  3.  Variables
    • Name your variables based on a Standard (e.g. same name as the Question with all lowercase and underscores, no special characters except underscores)
    • Keep them short and to the point, nothing worse than having to script on a field thats a sentence (e.g. g_form.getValue(‘what_is_the_best_phone_number_to_call’))
    • Put the important/required fields at the top of the form whenever possible
    • If a question you are asking is somewhat vague, err on the side of user experience; add a tooltip, help tag, or help text
    • Order your Variables by factors of “10”, (10,20,30…), this allows you to put new variables “in-between” in the future without needing to re-order all of the variables
    • Group commonly used variables (such as a header or footer section that has common fields like First Name, Last Name, Requested For, or comments) into Variable Sets for re-use
    • For Reference fields use the ref_auto_completer Attribute in order to define the searchable/visible fields to auto complete:  (ref_auto_completer_AJAXTableCompleter,ref_ac_columns=…)
    • Avoid “Checkbox” variables whenever possible, they are not currently supported by the g_form API therefore you can’t easily manipulate/validate them
    • Avoid “List Collector” (Slushbucket) variables except when absolutely necessary (complex use cases), as these are also not supported by the g_form API and are therefore very hard to programmatically customize. Note: If you still need to use it, here are ways to workaround this limitation using the ServiceNow Guru article found HERE.
    • Avoid “Nesting” containers to give the illusion of 3 or more variables per line. While this can be done safely with 2 columns (OOB), nesting the containers to get 3 or more gets tricky and can cause some weird displaying of variables on mobile devices.
  4. Catalog UI Policies
    • Prefer these over Catalog Client Scripts when it comes to showing/hiding or making variables mandatory as they are more efficient unless your writing scripts in them
    • Make an effort not to have a lot of UI Policy Actions that apply when the condition is EMPTY (running on load), the more fields the system has to go through to Hide, etc. the longer the form takes to load
    • Within Catalog UI Policy Scripts or Client Scripts use the “.setDisplay(‘variable’, false)” rather than “.setVisible(‘variable’, false); this will allow you to reclaim the space that otherwise would be a blank gap in the form
    • When possible, avoid adding the same variable to multiple UI Policies (especially if the conditions could both be true at the same time). If the need does arise, then go ahead and do it but make sure that the Policies have a different “Order” (Lowest order evaluated first)
  5. Catalog Client Scripts (CCS)
    • Validation: ServiceNow provides very little validation of values. So make sure to validate your fields (if its a date, make sure they cant choose yesterday – unless desired, if its a phone number or social security number than validate it contains the right number of characters, etc.)
    • Auto-Populate: If you can automatically populate variables based on information you already know about the user, then do it; it makes everyone’s life easier and keeps your users coming back
    • Auto-Clear: When populating variables based on other variable answers (e.g. populating first/last name based on selected user in reference), make sure to auto-clear these fields if the original field is cleared (especially a good practice when some of these variables may be hidden and still contain “old” data)
    • Use Callbacks: When using AJAX or GlideRecord lookups within CCSs, make sure to use callbacks otherwise the page will “hang” (only exception is onSubmit CCSs as these should wait for a result)
  6. Consider Reporting requirements
    • Reporting on requested items is not pretty. Even once a “Database View” has been created, the best you will get is a new line for every variable/value. One workaround to this behavior is adjust your workflow/scripts accordingly (putting all vars/values into the RITM description at the end)
  7. Order Guides / Wizards
    • Use as a Last Resort; they are difficult to work with and cause a lot of confusion in that they are merely a way to “bundle” separate items and only group by the “Request” which the user doesn’t understand/know about
    • If you do need to go this route then consider the End User and Fulfiller experience, they will be seeing/approving/fulfilling each item as if it was its own, that means that you may have 5 separate workflows running that are spitting out 5 separate emails and approvals and tasks.
  8.  Macros
    • Use Macros (yes that is a variable type) when necessary in order to get good looking HTML loaded (for disclaimers, notes, etc.) in your item
    • Keep them generic, sometimes this means loading data from a lookup table, by setting it up like this you never have to touch the macro once its setup to pull from that table, and it can then be re-used for different items
  9. Generic Catalog Items
    • Don’t be afraid to use them (especially at the beginning of your catalog rollout). These can route to the Service Desk for further triage and give your users the appearance that there are many more items in your catalog (merely create one, then copy it and change the name and descriptions) which can help their overall perception of the catalog and ServiceNow as a whole

One thing to note, as I realize this is a lot of things to remember; keep in mind that at Crossfuze we have developed a Service Catalog turnkey that does a number of these things for you OOB, please contact us if you are interested in learning more.

 

Have I missed anything? Please respond in the comments below to let me know things that are in your list of good practices.

ServiceNow Brings Real-time Simultaneous Updates in UI16 for Geneva (and some Interesting Results)

Realtime Update Icon

I was recently working with a colleague at Crossfuze (BIG shout out to Eric LeMonnier who found the solution for this) on a weird issue in Geneva. His onChange Client Scripts were triggering even though he wasn’t updating those fields. Upon closer examination it was because another user had modified the same record he was on for a field that his onChange Client Script was looking at (this is what triggers the blue icon seen above). This happens because ServiceNow has added a capability to handle multiple-users updating the same record at the same time, and as a result the fields will change dynamically as other users are updating the form. While this is a very nice feature, and handles the simultaneous update issue that used to occur, there may be some use cases where this is not a desired result. One of the downsides to this behavior is that ServiceNow does not upate “.modifiedFields” (g_form.modifiedFields) and thus it does not appear possible to find out if another user has changed a field using any of the g_form API “published” methods. In order to work around this, we found that it is possible to detect the change using an internal method “_internalChange”. Here is what an onChange script would look like, it will return true or false if it’s an internal or client update and if there hasn’t been a real-time update then it will return “undefined”:

function onChange(control, oldValue, newValue, isLoading, isTemplate) {
if (isLoading || newValue == '' || g_form._internalChange)
return;
}

Please Note: This script should only be used in a limited fashion as it does use a non-published/internal method of g_form, called “_internalChange”. While this does work currently (Geneva Patch 4), it is possible that ServiceNow could change this method later (perhaps publishing it and calling it “.internalChange”) and this script would need to be updated in any areas it has been used.

Please let me know your thoughts and comments. Happy Coding!

ServiceNow Blogs Cheat Sheet

 In my years as a ServiceNow Administrator, Developer, and Implementer there have been a few blogs that have repeatedly been a great source of information. The list below contains the blogs that I most frequently have found useful:
  1. http://www.servicenowguru.com – (Mark Stanger – my Mentor at Crossfuze Solutions) – My favorite technical resource of ALL things ServiceNow, if you’ve been struggling or had a problem with it, there is probably a post about how to fix it here!
  2. http://www.john-james-andersen.com/category/blog/service-now – (John James Anderson) – good blog on Integrations (REST, etc.)
  3. http://snaug.com – (Sal Costa) – Good source of Jelly, CMS related info
  4. http://www.servicenowelite.com/blog – (Mike Kaufman) – Good source of everyday usage tips
  5. http://www.snc-blog.com – (Logicalis SMC) – Good source of everyday usage tips
  6. http://serviceportal.io – (Nathan Firth) – Good source of ServicePortal, CMS, Angular tips
  7. http://www.cavucode.com/blog?tag=GenevaGems – (John Roberts) – Good info on Geneva (GenevaGems) and Fuji (FujiForty) enhancements
  8. http://sncommander.com – (Joel Maxwell) – Good general source of ServiceNow tips
  9. http://www.goranlundqvist.com -(Goran Lundqvist) – Good solutions to  specific use cases (now posts on SN blog too)
  10. http://servicenowtips.tumblr.com – Good ServiceNow nuggets, but hasn’t been updated in a while.
  11. https://community.servicenow.com – (ServiceNow) – Good Q&A on various issues
  12. https://community.servicenow.com/community/blogs/blog – (ServiceNow) Good posts about ideas/solutions for various issues
  13. https://hi.service-now.com/kb_view.do?sysparm_article=KB0552847 – (ServiceNow) Good CMS Resources – (Thank you to Robert Chrystie)
Good ServiceNow Related Books:

Mastering ServiceNow Administration –  (Martin Wood) – Good book for Administrators at all levels. Takes the reader through creating a Hotel App which is a great way to cover all the various usages of the covered functionality.

Mastering ServiceNow Administration Second Edition – (Martin Wood) – Follow up to first version (above). Due out in October.

The Principles of Object-Oriented JavaScript – (Nicholas C. Zakas) – Great book for learning about how Objects work in JavaScript. From a ServiceNow perspective, think about how to apply these principles in your Script Includes.
As I’m sure there are some I’m missing, please respond in the comments to other great ServiceNow blogs/books you have found useful.

How To Get Parameters/Values From a URL in ServiceNow

URL Parameters

There are a variety of methods available to retrieve the value of Parameters that are being passed in from a URL in ServiceNow. For those of you who are new to this concept, ServiceNow and most all other modern websites/platforms utilize this method to get data from one page to another. As a ServiceNow admin/developer, you will most likely use this functionality to auto-populate form data or possibly as a means of determining “state” based on previous form selections. A common use case is for turning Calls or Incidents into Requests. In this scenario you could pass the Caller as the “Requested for”, and the short description, into a “Describe your need” variable on a Catch all generic catalog item.

Over the years I have found myself repeatedly using the below techniques to grab these parameters so I wanted to make sure there was a single document that everyone could use for a quick reference.

Now on to the good stuff, an example URL parameter that I’m sure you are familiar with is “sys_id”:
http://instance.service-now.com/incident.do?sys_id=2ca8f612914d4140b1782bd13ae71f72

In this case, the parameter is “sys_id” and the value we are after is “2ca8f612914d4140b1782bd13ae71f72”.

To retrieve this from a Client Script (Client side), my mentor here at Crossfuze Solutions (Mark Stanger), has written a cool little function that allows this (click to see the full article):

var myparm = getParmVal('sys_myparm');
function getParmVal(name){
var url = document.URL.parseQuery();
if(url[name]){
return decodeURI(url[name]);
}
else{
return;
}
}

Next, if you are wanting to do the same thing in a CMS/UI Page (Server Side) then you will need to do this in Jelly.

The main way to do this is to utilize the RP object’s method called “getParameterValue”:

RP.getParameterValue('paramName')
RP.getWindowProperties().get('paramName')"

Also, while we’re discussing the RP object, a few other cool methods are as follows:

  • RP.getReferringURL() – returns to URL that got you to this page.
  • RP.isMobile() – returns true if the page is in mobile mode (browsing using a Blackberry, etc.)
  • RP.getParameters() – returns all the parameters passed on the URL (to loop through)

In terms of Jelly, I have had difficulty in the past pulling parameters using the RP methods above especially in UI Macros. Here is how I worked around it just call jelly.”the_name_of_the_param”:

<g:evaluate>
   //This works on any param name including params that dont start with "sysparm" 
   var catItemId = jelly.sysparm_id;
   //Or This works if param contains "sysparm"
   var catItemId = '$[sysparm_id]';
</g:evaluate>

To get Parameters for Business Rules/UI Actions (Server side) you can use the “getEncodedQuery”, and “getGlideURI” methods as follows:

current.getEncodedQuery().indexOf('sys_id=-1') != -1  //is a new record

gs.action.getGlideURI().toString().indexOf('parameter_looking_for_here') == value_to_check

 

ServiceNow has now started getting heavy in the AngularJS space. As such I thought I would include how to get a parameter in Angular (above client side methods still work too). This is usually done using RouteParams:

$routeProvider.when('/view1/:param1/:param2', {
    templateUrl: 'partials/partial1.html',    
    controller: 'MyCtrl1'
});

Then in your controller you would inject $routeParams to use them:

.controller('MyCtrl1', ['$scope','$routeParams', function($scope, $routeParams) {
  var param1 = $routeParams.param1;
  var param1 = $routeParams.param2;
  ...
}]);

 

Fun Tidbit:

As if all of these other methods weren’t enough, there is an additional method that I recently came across in a StackOverflow post that shows a fully customizable approach (in case you were looking to do something unique with URL parsing). There are a number of example solutions on the question, but the post by Haim Evgi had one of the best looking approaches (uses a Regular Expression to parse the URL) so I thought I would convert this into a Script Include for use on the Server side:

ParamsUtil.getValueFromURL = function(param_name,full_url){
   param_name = param_name.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]");
   var regexS = "[\\?&amp;]"+param_name+"=([^&amp;#]*)";
   var regex = new RegExp( regexS );  
   var results = regex.exec( full_url );
   if( results == null ){
      return "";
   }
   else {
      return results[1];
   }
};

Example Usage:

var params_list = ['sys_id','sysparm_query'];
for (i=0; i &lt; params_list.length; i++){
var parameter = params_list[i];
var url = 'https://dev10592.service-now.com/incident_list.do?sys_id=f6cb98490f221a001709c09ce1050ee1&amp;sysparm_query=active%3Dtrue%5Eassigned_toISEMPTY%5Ecaller_id%3D7e85d1bc0f755a401709c09ce1050e97'; 

gs.print(ParamsUtil.getValueFromURL(parameter, url));

Output:Example Output

Referenced Articles:

http://www.servicenowguru.com/scripting/client-scripts-scripting/parse-url-parameters-client-script/

http://wiki.servicenow.com/index.php?title=Extensions_to_Jelly_Syntax

http://stackoverflow.com/a/979997

 

How to Debug an Object in ServiceNow?

The following tools we will discuss today should give you some great options when it comes to debugging objects in ServiceNow.

The first option we need to discuss is the “Xplore” (version 3.5 currently) utility by James Neale. If you are not using this Developer tool then you should get this must-have utility immediately. If you ever wondered what was in a GlideRecord (or most any other object), or wished the “Background Scripts” tool had a better interface then this should be your go-to utility. There are a number of additional capabilities that this tool offers but this is my favorite.

Of course there are other ways to pull info on objects, but the interface on this utility is extremely intuitive and makes dissecting objects on the server side very easy. You can find this utility on ServiceNow’s Share site, or on GitHub.

Xplore (big)

One other tip that I discovered is that once’s its installed its possible to utilize its “xplore” function to parse objects to the log as well (handy when trying to debug objects on the fly and dump to the system logs):

var xplore = new snd_xplore(object);
gs.print(xplore);

xplore Command

Note that the “xplore” function name is subject to change as they release newer versions.

So now that we’ve covered Xplore, on to other tools that should be in your toolbox for object exploration. These are needed if you are not going to use the Xplore utililty and need to troubleshoot realtime communication and logging the output from within your own scripts. Here are the other one’s I’ve used:

Other Server Side Tools
There is a cool Script Include that is included OOB in ServiceNow called “JSUtil”. If you haven’t used/seen it previously, take the time to check it out; there are some great functions including one called describeObject that can be used to parse basic objects:

JSUtil.describeObject(object)

describeObject

Note that the JSUtil is not available/callable from within scoped applications.

Another option is to try outputting your (JSON compliant) object using the built-in JSON Script Include. This tool is great for “stringifying” data to make it readable on the server side:

gs.log(global.JSON().encode(object))

 

Ok, so you’re covered on the Server side of things, but what about the Client? 

Below are some Client Side Tools that allow you to debug objects in on the client/browser:

JSON().stringify(object)

If you are not using objects as properties in your object you may be able to use the JSON methods: JSON.stringify() on the client side, or JSON.encode() on the Server side. But again, that won’t work if the object uses functions or other properties which aren’t serializable to JSON.

One final Method is to use a simple loop; note that this ignores the Prototype inherited properties by using the “hasOwnProperty” check:

for (var key in obj) { if (Object.prototype.hasOwnProperty.call(obj, key)) { var val = obj[key]; // use val }}

A final tool you can use if you are in a browser like Chrome is DevTools. You can easily utilize “console.log(objectName)” in the Console (to open this just right click on a blank area of the page and choose “inspect) browser to then click through an object. Below is a screenshot showing how this can be done, I have used the “g_form” object as an example, and then started clicking through its keys/properties:

Debugging an Object - g_form

One thing to note, if you are doing this within the “Full Frame set” (includes the navigation bar), then you will need to select the “gsft_main(tableName.do), frame before you can start debugging. Alternatively just open your form in a new window that doesn’t have the navigation/top panel (control click on the link):

Console Debug iFrame

If you are not using Chrome (I’m sorry :)), you can always use something like the Firefox (Firebug) to do the same thing.

Have I missed any other common tools/methods? Please let me know!

How to Parse JSON Data?

I was working with a client recently who was just starting their journey into the world of Web Services using REST. This is a very powerful technology which allows two systems to exchange data using HTTP [POST (Create), GET (Read), PUT (Update/Replace), PATCH (Update/Modify), DELETE (Delete)] with JSON (JavaScript Object Notation) to exchange data. To work with this JSON data, ServiceNow gives a few methods. The confusing part to most new admins is that there are separate methods depending on if the parsing is done on the Server side, or Client side. Here are the methods to use for both:

Client Side:

JSON.stringify(yourJSONObject) //Encode your object into a string
JSON.parse(yourJSONString) //Decode your JSON String into an Object

Server Side:

new global.JSON().encode(yourJSONObject); //Encode your object into a String
new global.JSON().decode(yourJSONString); //Decode your JSON String into an Object

One nice thing about using REST in ServiceNow is that they provide a number of APIs (Table API, Aggregate, Import Set, Performance Analytics) based upon what type of integration is needed.

An additional nice feature that came in the Fuji release was the “REST API Explorer” which allows you to easily test the different REST methods with different data.

A similar tool that can be used externally to test can be found at http://hurl.it

Here are some more links to help you along your REST journey:
http://wiki.servicenow.com/index.php?title=Getting_Started_with_REST#gsc.tab=0
http://wiki.servicenow.com/index.php?title=REST_API
http://wiki.servicenow.com/index.php?title=Outbound_REST_Web_Service#gsc.tab=0
http://wiki.servicenow.com/index.php?title=Table_API#gsc.tab=0
http://wiki.servicenow.com/index.php?title=REST_API_Explorer#gsc.tab=0
http://wiki.servicenow.com/index.php?title=Scripting_Outbound_REST#gsc.tab=0

Workflow Scratchpad Tip

When working with the Workflow scratchpad object it is important to note a couple of things:

  1. Data can be placed on the Scratchpad for later use using the format of workflow.scratchpad.insert_new_var_name_here
  2. You can create variables on the Scratchpad that are any type (e.g. String, Array, Object, etc). This allows for great flexibility, in my previous post, I demonstrate that you can put an array of objects as a scratchpad variable. By utilizing this method, you have an extensible method to retrieve as much data from the workflow as you would ever need.
  3. The Scratchpad can be retrieved from external sources such as Business Rules and Script Includes by first grabbing the Workflow’s contexts (script below shows this method):
var req_item_id = 'id you are looking up';
var item = new GlideRecord('sc_req_item');
item.get(req_item_id);
workflow.getContexts(item)
if (context.next()){
var scratchpad_var = context.scratchpad.your_var_name_here;
//do something with the scratchpad data here
}

Note, that you can also place data on the Scratchpad using a “Display” Business Rule, and then retrieve on the client side with a Client Script (“onLoad”).

 

For More information please see the following ServiceNow Wiki articles:

http://wiki.servicenow.com/index.php?title=Using_the_Workflow_Scratchpad#gsc.tab=0

http://wiki.servicenow.com/index.php?title=Accessing_the_Workflow_Scratchpad_from_Business_Rules#gsc.tab=0