Inbound REST API Timeout

[j_d]

Is there any way to work around this?   Based on the documentation, adjusting this timeout is not supported.

I am running into an issue where my API calls are timing out.   I've tried to work around this many ways, by batching the data and now filtering on company and ordering by update date... It is now timing out on the filtered data as well.   We have a LOT of data in our instance.   I believe that SN is pulling data from the database and then doing filtering on the returned records (instead of filtering at the database level) and the time it takes to prepare the payload is too long.

Here is an example of data that times out:

/api/now/table/cmdb_ci_computer?sysparm_offset=0&sysparm_limit=1000&sysparm_exclude_reference_link=tr...

The API header tells me there is ~7500 records to return.   Before the first batch of 1000 is returned the data times out with this error:

"error\":{\"detail\":\"Transaction cancelled: maximum execution time exceeded Check logs for error trace or enable glide.rest.debug property to verify REST request processing\",\"message\":\"Transaction cancelled: maximum execution time exceeded\"},\"status\":\"failure\"}"

Is there any way around this?   If I reduce my batch size it MIGHT work, but my expectation is that as the data set grows I will eventually be back here trying to figure out how to solve it again.   Every time I lower my batch size, I increase the total time it takes to retrieve all records.   I'd prefer NOT to make it any smaller.

Thoughts?

[nyancer3]

Hi Justin,

I just ran into this error as well. I have an integration that is pulling in attachments from the receiving side, and it looks like I got the timeout because the attachments took more than a minute to transfer between instances.

I found a known error here: ServiceNow KB: PRB673025: Following an upgrade to Geneva, REST quota rules are added to instances th...

We are on Helsinki Patch 7 in our production instance, so according to the article it should be fixed but it is not. I am going to try the workaround suggested in the KB and let you know how it goes. You can adjust the timeout in the quota rules table, or deactivate them entirely: /sysrule_quota_list.do?sysparm_query=nameLIKEREST.

Thanks,

Nicholas

[nyancer3]

So I just tested the workaround by attaching a bunch of stuff until it failed. I then increased the quota in the receiving system to 240 seconds and it worked the next time I posted a message (the REST call took 84 seconds to process). It looks like adjusting or deactivating the quota in the instance that is returning the 500 error is the solution for this.

For all you MSPs out there, note that the quota records ARE domain-separated so be careful with that one .

Thanks,

Nicholas