As we are working on a Bahmni distribution that is preconfigured out of the box as much as possible for Cambodian primary care facilities, we need to have it preloaded with the ad-hoc address template, address hierarchy… etc.
Is that something that must be done through a ‘configuration module’, or there is a way somewhere to load these master and meta data?
(Q.) Is there something that would do this using the necessary resources (address template XML, address hierarchy CSV… etc) when they are saved in the right place?
First of all I am trying to assess whether what we are up to here requires a custom module or not.
The alternative would be that - somehow - Bahmni Config can help proceed with this without installing any new module.
Otherwise, if an additional module is indeed required, see below.
I’m not sure what you are pointing us to here. Of course we want to use those import & configuration features of the Address Hierarchy module, but this has got to happen programmatically before the first user attempts to login.
This is meant to be used in a custom module’s activator, correct?
I don’t really understand why Metadata Deploy would be an improvement from simply loading the address hierarchy (and address template) from the activator using directly the API of Address Hierarchy?
@gsluthra, a bit of a Bahmni 101 question here: is there a place in Bahmni Config that could be used to host resources that should in fact be processed by a module’s activator?
… as opposed to being pure Bahmni Apps UI configuration files (like the form definitions for example).
The reason why I am asking is because then we would lean towards adding a configuration module, whose activator would do or not do initialization tasks based on what it finds inside that location within Bahmni Config.
But perhaps is this all a complete heresy from a design standpoint.
Hi @mksd, in one of our implementations the usecase was that there were multiple clinics that needs similar setup i.e similar observation forms, similar address hierarchy etc.
We had a lot of meta data like OpenMRS Concepts, some of the default users, roles etc that needs to be preloaded for the implementation at any of the hospital sites.
So the approach we have taken was to add a step to load the database dump i.e mysql dump with all the data in our deployment steps.
[quote]You can do the following :
Install Fresh Bahmni
Add all the prerequisite information. i.e your metadata from UI
Take a dump of mysql and keep it as default db dump(In our case we kept it in config/dbdump folder)
@mksd - good quesiton, I agree this is needed. I don’t think there is a good way to do this currently.
Around a year ago I found that we had the same need, and I started spiking on a solution within the addresshierarchy module. I believe this is where the solution belongs, so it can be available to any downstream distribution. Unfortunately, I never finished it, I can’t find any ticket for it, and I can’t remember why or exactly how complete it is. I think I may have held it back since I did not yet have a good solution implemented for determining if the hierarchy has changed between system restarts (eg. if it needs to be reloaded fresh or not). It’s possible that it is largely done aside from that.
In any event, the code that I started to write is sitting in a branch called “configuration” in the addresshierarchy module in github. Here is the branch and the relevant commit.
It’d be great if you have a few cycles to have a look at what I started, see if it makes any sense, and take it over the finish line. It does a bit more than just addresshierarchy configuration - it also configures the address template fields needed for core (since these tend to be inextricably related, and have overlapping configurations). As I mention above, I think it’s pretty close to being useful.
Also, for some context, I posted this related thread around the same time, as a more general discussion of file-based OpenMRS configuration, as it is a bit of a wild west without many existing conventions to govern it, yet is being used more.
Happy to work with you on this, and to continue on the conversations.
Thanks @mseaton, this is very interesting. As you said, it looks like the work you did is completed already. If not then of course I’m happy to take it from where you left it and create an ad-hoc ticket.
A dumb rule would be to reload whatever is in configuration/addresshierarchy each time the module is started. Making the provided configuration acting as an override.
Another option would be to archive applied configurations, but then they should be uniquely identified to ensure that an already applied configuration can’t be ever processed a second time. Like having the configuration saved under folder named after a UUID:
The above configuration would mean that 11fef7ac has been applied in the past and 48c10376 is the next override.
It could be up to the the Core to browse the configuration folder and expose the next ones to go through an ad-hoc service: xyzService.getPendingConfigByArtifactId("addresshierarchy"). It would then be also up to the Core to manage the processing of the pending configs to ensure that they are indeed archived upon successful processing… etc.
This connects to the related thread that you pointed me to. That conversation about setting up a convention feels quite spot on and I would like to rebound on it a later point.
@mksd sorry, just reading this thread now, but I was just chatting with @mseaton about this…
For what it’s worth, we implemented a metadata deploy “AddressBundle” in our PIH Core module to ease the job of writing code to load in a hierarchy. It might not be what you are looking for, because it’s not code-free, you’d still need to write a class to define a @Component bean to install your hierarchy–but it’s only a single, small class. If you are interested, here’s the code. It’s still in the PIH Core module, but it should be moved to the address hierarchy module (and I think this would be straightforward after making address hierarchy “aware_of” metadata deploy). I may actually be moving it in the near future (but if you want to do so earlier, feel free just let me know).
Here are the two classes that implement the bundle and could be moved to Address Hierarchy:
And here’s a could example “configuration” beans we use to install our Haiti and Liberia Hierarchies:
I have liked and bookmarked! Will dig into it when I’ve put stuff behind with Address Hierarchy and i18n. But thanks a bunch already, that’s some serious resource sharing, really appreciated.
Great, glad it helps! I have been meaning to look into your plan for i18n in more detail, but haven’t had a chance yet… I’m still planning to, but feel free to ping me on the other thread if you’ve got immediate questions.
I have done a lot already, i spent all week on it basically. I’m hoping to come up with a PR within a week.
It’s some serious TDD development to bring this in while keeping your existing tests passing. Excellent that there are plenty of tests in AddressHierarchyServiceTest!
@mksd I Am inquiring if the solution you were seeking here was implemented. I happen to have need of the same solution too for some implementation. I was searching and came across the thread…
just let me know).
Will dig into it when I’ve put stuff behind with Address Hierarchy and i18n. But thanks a bunch already, that’s some serious resource sharing, really appreciated.