Recommended Timer Design for Multiple Master Data Syncs in OutSystems 11

Back to Forums

Shradha nair

Solved

Question

Timers

Architecture

Best Practices

OutSystems 11

Web

We have a master data synchronization requirement in OutSystems 11 where around 40+ masters are synchronized through a common API.

The same API is used for all masters, with a different Master Code passed in the request. The response structure can vary depending on the Master Code.

The synchronization frequency also varies:

Some masters need to run daily
Some need to run weekly
A few may need to be triggered on an ad-hoc basis

From an architecture and maintainability perspective, what would be the recommended approach?

Should we:

Create a separate Timer for each master, or
Use fewer/common Timers and process multiple masters based on their configured frequency?

Also, how does OutSystems 11 handle multiple Timers scheduled at the same time? If the available Timer execution threads/slots are already occupied, will the remaining Timers wait/queue until a slot becomes available?

Would appreciate any recommendations or best practices for designing this type of master synchronization.

02 Sep

Rahul

MVP

Solution

Same API for all masters
MasterCode drives the variation
Mixed frequencies
Maintainability is a priority

I’d recommend:

Create a dedicated “Sync” application that:
- Owns the master entities that are shared.
- Contains the timers and sync logic.
- Exposes public server actions to other apps if needed.
Use a small set of timers
At least:
- - SyncMasters_Daily
  - SyncMasters_Weekly
- For ad‑hoc:
  - Either a SyncMasters_AdHoc timer triggered manually, or a public action you can call from an admin screen.
Config‑driven orchestration:
- Config entity per master with:
  - MasterCode
  - Frequency
  - Enabled flag
  - LastRunDateTime
  - Optional Priority
- Timer reads this table, selects the due, enabled masters, and processes them in order (by priority or by MasterCode).
Master‑specific processing actions:
- Have one action per master type that knows how to:
  - Call the API with the specific MasterCode.
  - Parse its particular response structure.
  - Perform data synchronization (insert/update/delete).
- Dispatcher timer just calls these actions in a loop.
Protect against long runs:
- Inside the timer, check elapsed time and stop if approaching the 20‑minute timeout; update the config so remaining masters will be picked up in the next run.
- Optionally split heavy masters into their own timer (e.g. SyncProductMasterHeavy) for isolation.

This gives you:

Central governance of all master syncs.
Ability to add/change masters by editing data/config, not adding new timers.
Reduced contention on timer threads while still supporting different frequencies.

02 Sep

Huarlem Lima

Hi Shradha,

Just adding to Rahul's answer on your second question: yes, timers queue. Each front-end server can only run a limited number of timers at the same time (by default 3), and that limit is set per environment in the Configuration Tool ("Max. Concurrent Timers"). When all slots are busy, the other timers simply wait and start as soon as a slot is free, so nothing is lost, but they may start later than their scheduled time.

That's one more reason to go with a few config-driven timers instead of 40: they won't compete for the same slots at midnight.

For the ad-hoc runs, you can call the Wake<TimerName> action from an admin screen instead of creating another timer.

26 Sep

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.

See the full guidelines