TUESDAY, FEBRUARY 07, 2012

Category: Imports

Execute Scheduled Jobs From Script

Monday, 29 November, 2010 09:06 Written by Mark Stanger
14 Comments

Scheduled jobs are an extremely useful way to automate processes in Service-now.com and lift some of the administrative burden of the tool off of the shoulders of your Service-now administrators. It’s very easy to create a scheduled job or a scheduled import. Typically there’s no scripting or advanced configuration involved at all. Just set it up with a schedule and let it run! There are some situations where you might need to execute a scheduled job outside of its normal schedule. You can always open up the scheduled job entry and click the ‘Execute Now’ button, but there are also probably times where you’d really like to automate the process based on some trigger in a workflow or state change in some ticket or CI.

This article shows you how you can use script to execute an already-scheduled job on-demand. To do this, you simply mimic the behavior of the ‘Execute Now’ button by querying for the scheduled job you want to execute and firing off the job. Here’s the script…

Learn more ...

The Simple Power of XML Export/Import

Thursday, 04 November, 2010 10:57 Written by Mark Stanger
0 Comments

Service-now.com makes extensive use of the XML format for storing and transporting system updates and changes. Update sets, System Import Sets, and certain export methods all make use of XML files in one way or another. One feature that a lot of people don’t know about until somebody shows them is the ability to export and import XML files in a Service-now instance. A manual XML import/export can be extremely helpful in the right circumstances and is something that every Service-now consultant or administrator should have in their tool belt. In this post, I’ll explain how simple it is to transport system changes from one Service-now instance to another with a few clicks.

Learn more ...

Deactivating Users From LDAP

Wednesday, 01 September, 2010 14:30 Written by Mark Stanger
2 Comments

O

ne of the most common LDAP integration requirements is to disable users in Service-now when they become disabled in the LDAP source.

It is probably worth mentioning that you always want to deactivate user records (and most other records too) in Service-now instead of deleting them. Once a user record has been created in Service-now it should always remain in Service-now because that record could be linked to hundreds of other records (tasks, CIs, etc.). Deleting the record kills the relationship to those other records. Deactivating the record keeps that relationship in place.

Because the exact steps to set up this behavior vary depending on your LDAP setup and processes, this configuration isn’t something that can be predefined in Service-now. Typically a Service-now consultant assists with this setup and specific requirements are determined on a client-by-client basis. It has been my experience that there are two common approaches that can be used to disable Service-now users from LDAP. This article explains these approaches and how you can implement the needed functionality.

Learn more ...

The Best LDAP Integration Tip You’ve Never Heard Of

Wednesday, 30 June, 2010 10:49 Written by Mark Stanger
0 Comments

O

ne of the basic (but often forgotten) guidelines that should be followed whenever you consider importing any data into your Service-now instance is to only import the information that is actually necessary within the tool. Just because you CAN import the data into Service-now doesn’t necessarily mean that the data SHOULD be imported or that it has any value. Even if somebody thinks the data has value within Service-now, you should also consider if that value outweighs the work and trouble of importing and maintaining that data going forward. This is particularly true for CMDB and old ticket data but is also true of user data imported from LDAP. One thing that a lot of people don’t realize is that you can end up with ‘garbage’ data from LDAP but that it is also very simple to configure your system to prevent this from happening.

Learn more ...

Defining the ‘Run as’ User for a Scheduled Import

Friday, 05 February, 2010 07:43 Written by Mark Stanger
1 Comment

Recently I had a client ask me why all of their imported records showed up as being updated and created by the person who initially created the import. The problem, they said, was that the imported records were being created and updated on a scheduled basis by the system so it really wasn’t a particular person who was creating the records. While I agreed that it was a problem, I wasn’t sure at the time why it was happening or what the solution was. Now I know!

Learn more ...

Latest Comments

  • Mark Stanger: This linkage all happens for you if you use the task survey plugin. You can look on the wiki for more...
  • Vineeth: I want a way in which if a survey is filled in by the user the response are stored in the survey response...
  • Mark Stanger: This functionality doesn’t connect to an FTP server. See this line in the post above…...
  • Mark Stanger: The report page is back-end XML so there’s no way to directly manipulate the behavior of that...