Rest Api Explorer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I have a complex scenario at my hands here what client wants from me is an api endpoint to hit from their third party app to the servicenow instance and they want when they hit this api all the attachments related to sn_hr_core_case table should be downloaded on their local machine now what approach i have followed is as of now is created a scripted rest api which is calling two script includes since the major problem is the ammount of data is more that 10k on my instance what i am doing is first creating the batches of around 1000 attachments each and then zipping the files the zipping part is done in custom action which is going in the loop when rest api hits and at max it can process upto 3000 attachments that is three batches of zip files more than that the rest api execution time limit is going over
Rest api Code -
Zipper Script include -
Batch Builder Script include -
Custom action screenshots -
my major concern here is wthere architecuture wise this approach is going to hold or not and if not what are the possible approach i can take for such large ammount of data
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hi @sasharma815,
The architecture won't hold, and it's not really a batching problem, it's a synchronous-transaction problem. Every batch still runs inside the same inbound REST transaction, so chunking into 1000s doesn't buy you more time, it just spends the same Transaction Quota Rule window faster with .inForeground() flow calls that block until each zip finishes. Three batches today, maybe four after some tuning, still a hard ceiling next month when the case volume grows.
One thing to fix regardless: your first screenshot shows the Zip Files on HR Case action's Look Up Record step has Target Table set to Incident [incident], not sn_hr_core_case. Even once you decouple the API, that step is resolving case numbers against the wrong table.
- Fix the Look Up Record step's Target Table binding to sn_hr_core_case (or the table variable you're actually passing in).
- Pull HRAttachmentBatchBuilder and HRAttachmentZipExecutor out of the Scripted REST API entirely. Have process() just create a job record with status "queued" and return its sys_id immediately.
- Drive the real batch loop from a Scheduled Script Execution or an event-triggered flow, not the request thread, so you're bound by that job's own runtime, not the REST transaction's quota.
- Write each batch's result (zip sys_id, download link, success or failure) back onto the job record as it completes.
- Give the third party a status endpoint to poll (GET /export-status/{job_id}), or fire a callback once the last batch finishes.
Follow-up that would change my answer: how does the third party actually want to consume this, one combined archive or N zip files they pull down individually? If they need a single file, add a final step once the job's marked complete that re-zips the batch zips (or the underlying attachments) into one.
Thank you,
Vikram Karety
Octigo Solutions INC