The Nightly Ledger Run That Slows to a Crawl
A finance team runs a Blue Prism process every night at 22:00. It reads 1,400 open invoices from a work queue, logs into the ERP, and posts each invoice. For the first 300 items the process averages 40 seconds per item. After that, average time per item climbs to 95 seconds, and the run frequently overruns the 06:00 cutoff, leaving 150-250 items unprocessed. The bot runs on a dedicated runtime resource with 8 GB RAM. The process keeps a collection of every processed invoice in memory for a final reconciliation report and never resets it. No other process runs on that resource at night. The queue has a single priority band, and all items were loaded in one batch. Business objects are configured with a 30-second timeout on the ERP login stage.
1. Diagnose the most likely cause of the slowdown and recommend two concrete changes, one in the process and one in queue configuration, that reduce the risk of missing the cutoff.
Read the worked answer
The pattern - steady performance for the first ~300 items, then a near-constant degradation - points to memory growth rather than a network or ERP issue. The process appends every processed invoice to a collection used only for a final reconciliation report. Collections in Blue Prism are held in memory; as the collection grows, each append and each internal operation becomes more expensive, and garbage collection pressure increases. With 8 GB and a long-running process, this compounds. The ERP login timeout is a red herring: a timeout would produce discrete failures, not a smooth slowdown.
Process change: stop accumulating the full collection. Write each invoice result to a work queue tag, a log, or a small output file as it is processed, and build the reconciliation report from the queue's completed items at the end, or in a separate reporting process. If a collection is genuinely needed, cap it and flush periodically.
Queue configuration change: split the load into priority bands or separate queues so that high-value or deadline-critical invoices are processed first. That way a degraded tail does not leave the most important items unprocessed at 06:00. Also consider a second resource to parallelise, but only after the memory leak is fixed, since parallelising a leak multiplies the problem.
2. The team proposes simply restarting the process every 300 items to clear memory. Evaluate this workaround against fixing the root cause.
Read the worked answer
Restarting every 300 items would mask the symptom. It works only if the process is designed to stop and resume cleanly: items must be marked complete in the queue before restart, and the restart must not re-post invoices. That requires idempotency checks, which are exactly the kind of controls a restart-every-N approach tends to skip. The risk is duplicate postings and reconciliation gaps, which in finance are worse than a slow run.
It also hides the real defect: an unbounded collection. The correct fix is to remove or bound the collection. A restart schedule is acceptable only as a temporary mitigation with explicit safeguards: queue item status checked before posting, a unique invoice reference used to detect duplicates, and a monitored restart count. Document it as technical debt with an owner and a removal date. The exam-style judgement is: prefer the root-cause fix; if a workaround is unavoidable, make it safe and time-boxed.