Simphony Update Functions
Simphony Update Functions
Update Database
This function will cause Ops start a foreground job that requests any configuration data that has been
changed from the central database since its last database update. Ops will wait for the process to finish
before the user can take another action.
Refresh Database
This function will cause Ops start a background job that requests any configuration data that has been
changed from the central database since its last database update.
I will start with a brief discussion of the syncing architecture. Whenever a change is made to the
enterprise database (either through EMC, Import, or some other mechanism), a row is added to a
table which tracks changes, and a row is updated in another table which tracks when each table
was last changed for a particular level in the hierarchy (zone, enterprise, property, etc.). This
second table is cached in memory by the application server, and refreshed every five minutes
(hardcoded).
The client database (could be DataStore, CheckPostingDB, or KDS) periodically asks the
application server “Do you have anything new for me?” How often the client database does this is
configured in Property Parameters, and can be overridden on the Workstation record. The server
will consult the cached list to see if any tables have a newer change time for the requested
hierarchy levels. If so, it will use the change tracking table to put together a list of changes to
send back to the client. The client will then apply that list of changes to the local database.
Another scheduled job in the client periodically wakes up while the client is idle (i.e. not in a
transaction) to see if there have been any changes to the local database. If there have been,
these changes are used to update the in-memory copy of the database that the client actually
uses for operations.