Hello community,
I administer a DHIS2 instance (internal) which must import the OrgUnits of a national instance (reference) to facilitate automation of data integration.
But there are manually created Orgunit in the internal instance. Which caused a UID difference.
My goal is to update the Orgunit UIDs created manually in the internal instance.
Best,
Demba
Bonjour la communauté,
J’administre une instance DHIS2 (interne) qui doit importer les OrgUnit d’une instance nationale (référence) pour faciliter automatisation de l’intégration de données.
Mais il y a des Orgunit créées manuellement dans l’instance interne. Ce qui a causé une différence de UID.
Mon objectif est de mettre a jours les UID des Orgunit créées manuellement dans l’instance interne.
Would it be possible to delete all the OUs in the instance where the OUs were created manually and then import them from the other instance, or is it required to have additional/different OUs in one instance that are not going to be present in the other instance?
I have two constraints:
1- There are OrgUnits from instance 2 that have children that are not in instance 1.
2- The manually created OrgUnits in instance 2 contain Tracker and Aggregation data.
What I think of as a solution is:
1- Import the OrgUnits from instance 1 to instance 2?
2- Transfer the data from the OrgUnits of instance 2 created manually to the OrgUnits imported from instance 1?
3- Delete the manually created OrgUnits of instance 2?
How to carry out points 2), 3) and 4). Because I work with version 2.38 of DHIS2. And the transfer functionality with the DHIS2 Capture version 2.2 application no longer works.
Please note: We have Tracker and Aggregation data.
First, the steps are to ensure that both instances will have the same OU hierarchy, right? This is important because although this might not be exactly the same for your case if you are creating a custom data integration; however, I think the warning in the Configure metadata synchronizing documentation page could still be relevant since it might be the reason behind the conflicts in the UID:
Additionally, it seems that the DHIS2 instances have different uses to a certain extent? If that’s correct then it might be useful to have a central instance which both instances can sync from; however, all metadata in the central instance should be the same as the two instances as the warning explains.
Since there are OUs in instance 2 which are not in instance 1, why not start by importing the OUs in instance 2 into instance 1? This will help ensure that both instances have the same OU hierarchy? You could use the Import/Export app to perform this step.
Is this step necessary if both instances have the same OU hierarchy? Isn’t the data in the OUs in instance 2 in OUs that are not in instance 1 so where’d the data be transferred to?
I’m asking the questions about to get a clearer perspective; however, I believe the Import / Export app should be a perfect tool for the steps you mentioned if they seem to resolve the issue you are facing.
I’d recommend to start by using test instances that are a replication of the production instances to ensure that no data is loss or critical issues appear in the process, and then after all the changes are applied correctly, perform in the production instance.
