There so many ways to get information from a 3rd-party system into ServiceNow and back. It can be done via web services, JDBC, email, file transfer, etc. Let’s say a customer wants to send a CSV file to the ServiceNow instance, they have a couple of choices: attach the file manually to a data source or place the file on an FTP(s) server. Oddly, there is no option to simply have the mid server send the file directly to the ServiceNow instance to be processed by an import set. This is a very common complaint/recommendation that I hear from customers.
Placing a file on an FTP server is typically a good idea, especially when that file will be used by other vendors and you want a common location for these CSV files to be retrieved. This is not always an easy thing to do, however, when there is no public-facing FTP(s) server available and you simply need to send a CSV of users, for example, to ServiceNow.
Introducing, the Scheduled File Importer.
One of ServiceNow’s principal strengths comes from its extensible framework. Built into the framework is the ability to retrieve information using one of a myriad of methods. If you want to get data out of any table, you can get it via direct web services, using basic auth data retrieval, having it pushed to a client, FTP server or Â linux server by using the scheduled data extract, and more. Â However, there are times when none of these solutions give you a logical way to achieve what you want in a simple manner. Â I will give two examples: 1) adding an item to a cart, 2) fetching an attachment from a record. Â For tasks such as these, the flexible Scripted Web Services is the answer.
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.
erviceNow makes configuring SSO into your ServiceNow instance very simple. By enabling a plugin and configuring a couple of properties, single sign-on can be set up in less than 10 minutes. Documentation surrounding these SSO methods are also well done and easy to follow.
Recently, I’ve come across a number or clients that want to use ServiceNow as their main company portal and wish to configure their ServiceNow instance to generate an SSO token that can be consumed by a third party service provider. In other words, they desire to have outbound single sign-on directed to of their other internal applications. Because of this increasingly common request, I have created an update set that can be used for such a purpose called, Outbound Single Sign-on via Digested Token.
here is a new integration to our downloads page for those that need to receive alerts from Interlink’s Business Enterprise Server (BES).Â This integration is structured just like any other alerting integration and follows the same process flow: