How to migrate concepts automatically from CSV files?

Software Bahmni
1

Is there a way to migrate concepts and concept sets automatically from CSV files on server startup, e.g., when running ‘vagrant up’ for a Bahmni instance?

https://bahmni.atlassian.net/wiki/display/BAH/Migrate+Concepts+and+Concept+Sets

Thanks, Dominic

2

Hi @dsurrao,

We are actively working on tackling this exact topic with the OpenMRS Initializer module. Please read through the README, in particular the Domain ‘concepts’ subsection. This is work in progress though, but perhaps would you be willing to collaborate?

This is not specific to Bahmni, but we actually are developing this in the context of the metadata management of Bahmni instances.

3

Thanks @mksd! I’ll take look at this.

4

Hi @mksd,

  • Should I build the dev branch since there is no master branch?
  • Could you please share a sample CSV file fully defining some concepts?
  • Does the current code work with OpenMRS 2.0 distributions?

Thanks.

5

Hi @dsurrao,

Should I build the dev branch since there is no master branch?

Correct. The master branch will only be created upon the first release, hopefully around early July. So you should expect this to be bumpy and changing until there is a master branch.

Could you please share a sample CSV file fully defining some concepts?

You can either look at test resources (here) or through a real work-in-progress configuration that we are working on (here). You may keep an eye on both locations as this module is under active development and will keep changing in the next few weeks.

Does the current code work with OpenMRS 2.0 distributions?

See here: Core 1.11.8+ We are developing using Bahmni 0.88, so that’s Core 2.0.3 I believe. However you may faces some issues with the metadatasharing domain with Core 2.1 because of TRUNK-5169. This is currently delaying our upgrade to Bahmni 0.89.

1 Like
6

Hi @mksd,

I ran into a couple of issues when building the dev branch using “mvn clean install”:

  1. A compilation error in the AddressHierarchyMessagesLoadingTest.java class, I commented out that line for now: [INFO] ------------------------------------------------------------- [ERROR] /Users/dddd/IdeaProjects/openmrs-module-initializer/api/src/test/java/org/openmrs/module/initializer/AddressHierarchyMessagesLoadingTest.java:[53,65] cannot find symbol symbol: variable GLOBAL_PROP_I18N_SUPPORT location: class org.openmrs.module.addresshierarchy.AddressHierarchyConstants [INFO] 1 error [INFO] ------------------------------------------------------------- [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] Initializer … SUCCESS [ 0.569 s] [INFO] Initializer API … FAILURE [ 2.686 s] [INFO] Initializer OMOD … SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE

  2. The unit test AddressHierarchyMessagesLoadingTest.refreshCache_shouldLoadAddressHierarchyMessages() fails. I’ve commented out that test in my local version as well.

7

Hi @dsurrao,

The reason why you are bumping onto those issues is because Initializer 1.0-SNAPSHOT depends on a SNAPSHOT version of Address Hierarchy that is assumed to hold the i18n support feature. However this hasn’t been merged into AH’s master branch yet.

The simple way out of this is to skip tests altogether. A more complicated way would be to clone and build our fork of AH. That way the needed JARs will in your .m2 folder. You would have to clone and build the dev branch of our fork (here).

8

I’ll skip tests for the build.

I also ran into runtime errors that I resolved by adding messages_fr.properties and messages_es.properties files to the …/api/src/main/resources folder.

Thanks!

9

Thanks for reporting this, can you let me know the steps to reproduce those runtime errors that you mentioned?

10

The error shows during the maven build, and also on the administration page when the module is started.

ERROR - ModuleFactory.getModuleFromFile(532) |2017-05-31 08:12:31,238| Error getting module object from file initializer-1.0-SNAPSHOT.omod

org.openmrs.module.ModuleException: No message properties file messages_fr.properties for language fr

at org.openmrs.module.ModuleFileParser.getMessages(ModuleFileParser.java:595)

at org.openmrs.module.ModuleFileParser.parse(ModuleFileParser.java:266)

at org.openmrs.module.ModuleFactory.getModuleFromFile(ModuleFactory.java:528)

at org.openmrs.module.ModuleFactory.loadModule(ModuleFactory.java:107)

at org.openmrs.module.ModuleFactory.loadModules(ModuleFactory.java:186)

at org.openmrs.module.ModuleFactory.loadModules(ModuleFactory.java:169)

at org.openmrs.module.ModuleUtil.startup(ModuleUtil.java:76)

at org.openmrs.api.context.Context.startup(Context.java:883)

at org.openmrs.web.Listener.startOpenmrs(Listener.java:227)

at org.openmrs.web.WebDaemon$1.run(WebDaemon.java:42)

11

Thanks @dsurrao, config.xml was still referencing those two files for ‘fr’ and ‘es’ locales even though we had removed them. It is now solved and pushed in dev.