Background: For an app we want to store settings with an external service. I am looking for a way to ensure that requests can always be assigned to the correct DHIS2 instance - and the systemId seemed to be the right ID - until I realized that it does not change the different demo systems.
On the flip-side: if such an ID exists, does it stay constant if the system is upgraded?
Hi @peter.albert - the system identifier is generated automatically on first startup of a new database (I think in dhis2-core it’s here but a dhis2-core dev can tell better) and present in the db at configuration.systemid. It is used for sync between DHIS2 and other multi-instance interactions so probably you can inject a random UUID yourself.
Hi @peter.albert - what @dhuser mentioned is correct, the configuration table in the database is assigned a UUID (universally unique identifier) at startup time on a clean database. As this is a UUID it should be globally-unique, but as all DHIS2 instances are independent (there’s no global registry of instances) this cannot be guaranteed. If a database is cloned without clearing this field in the database, the source and destination instance will have identical systemid values. This is the case for the two play.dhis2.org instances you referenced, which are both clones of the same source database with a pre-defined systemid. Hope this helps.
if such an ID exists, does it stay constant if the system is upgraded?
Yes, for upgrades on the same database this id should remain constant (unless manually cleared or modified)