A replenishment job adds records to a single-use pool on a schedule, so the pool does not run out and no one has to add records by hand. The job reads data from a source system and adds it to the pool as new records. This article covers setting one up and the commands it uses. Setting a pool’s replenishment job and schedule requires the Manage Data Pools permission. The commands a job runs are not checked against the role of whoever triggers it, and commands that change data can only target pools the project owns.
Related ACCELQ conceptA replenishment job is an ordinary ACCELQ Job (a scheduled execution). Rather than testing your application, it produces test data using the no-code Data Pool commands.
How replenishment works
The job gathers data from a source, such as a file, a spreadsheet, a database, or a message queue, and writes it into a pool as fresh Ready records. Because it is a normal Job, it runs on a schedule and reports results like any other Job.
Common trigger: environment refreshesA frequent reason to replenish is an environment refresh. When a lower environment is reset from a baseline, the valid accounts, SIMs or IDs change, and a pool filled from the old data goes stale. Running the replenishment job as part of the refresh, or on a schedule just after it, reloads the pool with current data so tests keep passing.
Set up replenishment
A replenishment job needs two things: logic that gets data from a source, and a schedule on the pool.
Source data from other systems
A replenishment job gets its raw data using ACCELQ’s existing no-code command libraries, then shapes it into records and adds it to the pool. ACCELQ provides libraries for files, Excel, relational databases, NoSQL databases, message queues, JSON, XML and more, so a job can read data from the system where it is kept. The pattern is always the same: read from the source, then add to the pool.
[IMAGE: A replenishment job reading records from a database and adding them to a pool.]
Attach the job and set a schedule
First build a Scenario whose logic produces pool data, using the commands below, and make it a Job. Then, on the pool, set this Job as its replenishment job and choose a schedule: on demand, daily at a time, or weekly on a day and time. The pool’s health band then shows the last run’s result, the next scheduled run, and current availability, so you can see whether replenishment is adding records as fast as tests use them.
[IMAGE: The replenishment settings on a pool, showing the job, the schedule, and the health band.]
Commands and patterns
Inside the job, a small set of commands covers adding, refreshing and pruning records.
Commands for maintaining data
Every Data Pool command identifies the pool by its ID, shown for each pool in the Data Pools list. The ID never changes, so renaming a pool does not affect your logic.
Inside the job you use the no-code Data Pool commands to write and maintain records. The ones you will use most:
| Command | What it does |
|---|---|
| Add a record to a Data Pool | Inserts one record (column values as JSON), with its Data Class and, if the pool uses Record Scope & Variability, its environments or variants. |
| Add records to a Data Pool in bulk | Inserts many records at once from a JSON array, the usual way a job loads a batch. |
| Get count of Data Pool records by status | How many are Ready, Used, and so on, used to decide how much to add. |
| Find Data Pool records | Locates records by status, Data Class or column value (not an encrypted column), to update, recycle or delete. |
| Update a column on Data Pool records | Changes a value on one record or a found set. |
| Set the status of Data Pool records | Moves records between statuses; records in flight are skipped. |
| Recycle Used Data Pool records to Ready | Returns used records to Ready, for pools that refresh rather than regenerate. |
| Delete Data Pool records | Prunes expired or exhausted records. |
Supply encrypted columns as plain values when adding or updating records; ACCELQ encrypts them as they are stored and masks them in Job logs.
Build a self-regulating job
The most useful pattern tops the pool up to a target without over-filling. The job first reads how many Ready records remain, and adds only enough to reach the target. Here DP-1042 is the ID of a Prepaid SIMs pool:
(if ready is below your target, gather that many new records from the source)
Add records to Data Pool “DP-1042” from newRecords. Store added count in added.
Because the job checks the current count first, it adds only what is needed and is safe to run on a frequent schedule.
Recycle and prune
Not every pool regenerates data from scratch. Some simply reuse the same records after a cool-down, and for those you use Recycle Used Data Pool records to Ready to return consumed records to availability. A job can also Delete Data Pool records that have expired or should no longer be used. Records that are currently in flight are never touched by either.
Start simpleBegin with one scheduled job that checks the Ready count and tops up from your source. Add recycling or pruning only if your data actually needs it.
Comments
0 comments
Please sign in to leave a comment.