These are some common questions you may need to ask while planning your integrations on the NOW platform based on the Pareto principle (80/20 Rule)
ServiceNow integrations support three use cases
1) Process Integration
2) UI Integration
3) Data Integration
1) Is this an import to ServiceNow or an export from ServiceNow?
2) Which system is initiating this conversation? Is this a push or pull?
3) Can the integration be done asynchronously in the background or synchronously while you wait. Most integrations can be done async, for example, sending a batch of compliance records to your governance agency every month.
4) Are you doing the integration once or on a regular basis? One time or recurring integration? An example of a one-time integration is importing a legacy spreadsheet and then maintaining that data in ServiceNow in the future.
5) Does the data need to be updated in real-time or batched at periodic intervals? Depending on the volume of data exchanged, there may be performance impacts, and it may be better to run the export or import at off-peak hours or spread them over the course of the day.
6) Are there times that work better for the integration?
7) Is this a unidirectional or bi-directional exchange? Do each system kept informed of the changes by the other or one considered as the source of authority or other the consumer
😎 Does the data need to be transformed between the systems? Often times the data need to be modified, mapped or transformed in the system since the fields and formats are different. It is best to answer the questions early to understand the level of effort involved. For example, you may need to map the date format or map a user field to a customer field.
9) Which system is the source of authority? In other words, you may need to understand which system has the final say if the system goes out of sync, for example, the HR system is the source of authority even though the NOW platform receives information from the HR system and sends the updates
10) What common formats and protocols are supported by both systems? For example Excel, CSV, JSON, XML or protocols such as FTP, HTTP, JDBC, ODBC. Knowing these answers gives you insights into how your integration will be built
11) Do you need to exchange all the information every time, or can we do incremental updates or is that even possible? This saves time and processing on both systems
12) Does an existing integration already exist? In other words, are there tools already built, or do I need to create one?
13) What level of error reporting or retry do you require? If there is an issue with the integration, such as remote systems not responding or you expected 50 records, and you only receive 48, what should be done in such cases? Is the report sufficient? Should an incident be created
14) Do you understand the amount of data required to exchange, and how long will it take? How much data is involved, and how long does it take? If you try to exchange 10 GB of data and it takes 4 hours, and the requirement needs an hourly refresh, you are going to run into some problems
15) Are there any data retention policies? Some organizations have data policies on how long the data can reside in their systems and what happens to the data after that period. Knowing these policies, you can overcome compliance and governance issues.
a. Table Rotation
b. Archiving
c. Remote tables
16) What security or credentials are required for your integration?
a. Is it a publicly available open API you are trying to access or grant access to? Do ServiceNow need credentials
b. Does the third party system require ServiceNow credentials?
c. Does that account have proper roles and ACLs?
17) What type of credentials are required?
a. Login/password
b. OAuth
c. JWT
d. API Key
Note: Know what you can and cannot support
18) Service Level Agreements (SLAs)
Source: https://en.wikipedia.org/wiki/High_availability
Note: Typically SLAs, are not offered for many services under Free or Shared tiers or free products
19) Availability Metrics
• MTTR - Mean Time To Recovery is the average time it takes to restore a component or service after a failure occurs
• MTBF - Mean Time Between Failures is the length of time that you can reasonably expect a component to last between outages
20) Recovery Metrics
• RTO - Recovery Time Objective refers to the maximum acceptable time that an application or service can be unavailable after a failure
• RPO - Recovery Point Objective defines the maximum duration of data loss that is acceptable during a disaster
21) Timeouts
Connection Timeout
The connection timeout is the maximum time a client (i.e. the ServiceNow instance or MID server) will wait for a TCP connection to be established with the web service endpoint. This can be set manually for each request using the setHttpTimeout(milliseconds) method. This timeout value applies to both synchronous and asynchronous requests. Note that calling this method will also override the socket timeout for the request.
Socket Timeout
The socket timeout is the maximum time a client will wait to receive an individual TCP packet from the endpoint. This can be set manually for each request using the setHttpTimeout(milliseconds) method. This timeout value applies to both synchronous and asynchronous requests. Note that calling this method will also override the connection timeout for the request.
ECC Timeout
The ECC timeout value is the amount of time that an asynchronous request will wait for the response to show up in the ECC Queue. This timeout applies to all asynchronous requests, both with a MID Server and without. However, this does not apply to synchronous requests because they do not use the ECC Queue. This can be controlled globally using the properties "glide.rest.outbound.ecc_response.timeout" or "glide.soap.outbound.ecc_response.timeout". This is also controlled on a per request basis through passing the number of seconds to the waitForResponse(seconds) method.
Based on Chuck Tomasi's video
From <https://www.youtube.com/watch?v=hX39spCtY5M> (Running Time: 9 Minutes and 28 Seconds)
Please mark the article as helpful if it is helpful to you.
