When to use Scripted API or Web Service Import Sets?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-30-2017 05:53 AM
What is best practice for using a custom web service? This will be an integration to a 3rd party where we need to go through the data first and check for required fields, check if records already exist, and do some field mapping.
We would like to be able to reuse for future integrations. Checking for required fields will be common for each integration and if the values already exist for reference fields, field mapping may change slightly but it isn't very complex.
Does anyone know if there is a big drawback to each one? What is best practice for re-usability and maintainability? We are using SOAP but will add REST support later in the year.
I'd like to have something reusable for upcoming integrations with external ticket systems.
- Labels:
-
Best Practices
-
Integrations

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-30-2017 05:58 AM
Hi Steve,
Scripted web services (SOAP or REST) give you complete control over the API and it's behavior. If you want a custom response sent, or need to do something different with the data than the standard table, import, etc. APIs, then scripted APIs are the way to go. Yes, they can be a bit more complex to build because they involve scripting, but they're not that difficult.
We did a show on scripted REST APIs about a year ago on TechNow. Check out episode 23.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-30-2017 06:02 AM
Chuck,
I was leaning towards Scripted APIs as I felt they had more control. It was also easy to edit the response or to give custom error messages.
Let me take a look at the TechNow episode.
Thanks for the input!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-11-2017 06:41 AM
With scripted API you have full control over the request and the response object. You can build complex APIs which needs to create/update records in more than one table or read data from more that one table. You can manipulate the request and response as you need. However, i do recommend using import set web service to create/update records in the back-end table by exposing the operations in the scripted API.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-25-2019 08:42 AM
Hi Chuck,
We have a requirement to add/update records in CMDB only from a third-party interface (Informatica) in real-time (based on actual insert/update happen in that database) and nobody is intended to insert or update records in CMDB directly from ServiceNow UI. Basically, ServiceNow CMDB UI will be read-only for IT Users.
we are not expecting major scripts or transformation logic to be developed for transferring the data from 3rd party interface to CMDB tables. 3rd party interface suppose to consume ServiceNow web service for the particular CMDB table (Insert or Update operation)
so the question is: what is the best practice or recommended way to achieve it?
1) via Import set web services
2) via direct web services
3) REST API
4) Scripted web services/REST API
5) CMDB Instance API
I have seen a lot of forums and ServiceNow videos and all of them says different, however, there is one video . Please watch between minute 3 to minute 5: https://www.youtube.com/watch?v=EhxgEECd7mQ - Import set web services is the good way over direct web services when insert/updating CMDB records are expected. If it is only for reading/query purpose, direct web services is the recommended way - that's what it mentioned.
Any input or advice will be appreciated.