Frequently update a system property using script.

[Jon23]

After reading SN Documentation, KB1000746, and several posts about the use of system properties with 'Ignore cache' checked [true], I am still unclear if it's okay (no impact to performance) to update a system property frequently using a script.

My requirement is to query records that have updated since the last time a process ran.  This processing job would simply get the existing property (date/time) value for use in the query, then update the property with current date/time ready for the next run.  The process runs hourly (may change to run every 15 minutes).

If updating a system property frequently is not a good idea, what is an alternative?  Creating a custom table that basically looks like the sys properties table?

[Sheldon Swift]

As a one-off, using a system property might be acceptable, but based on the information I have, it’s not the approach I would recommend. I discussed this scenario with a few other architects, and none of them prefer using a system property for this purpose. Perhaps the community will offer additional perspectives.

[HIROSHI SATOH]

If there are no restrictions, it would be natural to create a new table.
I think using the sysauto table is a good idea, and managing the data as CI in the CMDB is also a good idea.

[Mark Roethof · Accepted solution]

Hi there,

Ignore cache on System Properties isn't that long around yet, that's also why a ton of out-of-the-box system properties don't use this 😅. Where possible, do apply this!

Though in general, if a System Property is updated multiple times a day, is a System Property then the way to go? Often not. An alternative, like a custom table just for one property? That sounds like overengineering (and custom tables are not unlimited).

There's not just one road to go. At some customers I've seen them creating a table with a collection of a ton of values for several apps/processes etc. You could even set some nice security on it so process owners might even update their own "properties".

For what you are describing though, the last time a process ran, that will be known anyway right? Why than store it in a system property or custom table? Why not just query for the last time?