Running Bahmni Appointments scheduling on OpenMRS

Tags: #<Tag:0x00007f3030c8d838> #<Tag:0x00007f3030c8d770> #<Tag:0x00007f3030c8d6a8> #<Tag:0x00007f3030c8d540>

Hello all,

We are working for a client, who is using OpenMRS. They wants to use the Bahmni-Appointments-Module on top of OpenMRS(without the whole bahmni distribution).

We had started working towards this. Here is some information about the steps we have taken. While testing the Bahmni Appointments module on OpenMRS ref app, we found out there are conflicts with existing openmrs appointments scheduling module.

An association from the table patient_appointment_audit refers to an unmapped class: org.openmrs.module.appointments.model.Appointment

As an easy fix, we removed the existing appointment scheduling app. Post this step, OpenMRS is unable to start these three modules:

  • Reference Metadata Module
  • Reference Demo Data Module
  • Chart Search Module

We wanted to hear from the broader community about:

  • What could be a possible way to mitigate these issues?
  • What are the possible reasons for these modules requiring appointments scheduling module?
  • Will it be possible to replace the openmrs appointments scheduling module with the bahmni appointment scheduling module?

Let us know your thoughts/opinions.

@angshuonline @dkayiwa @mksd @mksrom @rrameshbtech @binduak @snehabagri @jdick

2 Likes

Thanks @mddubey for summarising this.

So we will be able to get rid of Reference Metadata (cc @jsibley, and see also here).

Reference Demo Data can be removed right away, that module is not mandatory at all, as the name suggests.

The main question is: why does Chart Search seems to have such a strong dependency on AS? Cc @k.joseph. (I haven’t looked yet.)

1 Like

what’s that?

Sorry, Appointment Scheduling.

i don’t think chart-search should depend on AS, we probably need to investigate and drop that relationship if its not required but existing

2 Likes

@mddubey did you try remove the requiring of Appointment Scheduling from these modules and see how it goes?

1 Like

Hello @dkayiwa,

No, I have not yet got the chance to do it yet. Surely, that’s one option I can try by cloning them locally remove dependency and try starting. I have not yet got the time to do it, working on other things to get Bahmni Appointment Scheduling on OpenMRS.

Another thing is I am not very sure, why do these modules require AS module so I test those specific features. I am not fully aware of these modules, I ran into this problem because I was using refapp-docker image and that comes with these modules.

I think we can do away with this by simply changing require module to aware of module.

1 Like

@mddubey this is what @dkayiwa has referred to.

1 Like

Thanks a lot @dkayiwa and @mksd for the references. I will give it a try once I am done with my current work in hand.

Hello @dkayiwa and @mksd,

Today I tried below steps to make reference-metadata independent of appointment-scheduling module

  • Clone reference-metada repo, move appointment-scheduling dependency to aware_of_module section.

  • Remove the appointmentschedulingui-1.7.0.omod and appointmentscheduling-1.10.0.omod.

  • Remove the existing referencemetadata-2.9.0.omod from webapps/openmrs/WEB-INF/bundledModules/referencemetadata-2.9.0.omod

  • Build the referencemetadata-2.9.0.omod from my cloned repo, and put it in webapps/openmrs/WEB-INF/bundledModules/referencemetadata-2.9.0.omod.

  • Restart the server.

After this I don’t see the UI and I see this error instead

If you are seeing this page, it means that the OpenMRS Platform is running successfully, but no user interface module is installed.

IMO, this means the ref-app is not able to start.

In the startup logs, I see the error below

java.lang.NoClassDefFoundError: org/openmrs/module/appointmentscheduling/AppointmentType

If I check the references for AppointmentType in the reference-metadata code, I don’t see any references for it. This is the only reference which doesn’t look like of AppointmentType model. I think it should have worked, not sure if I am missing anything trivial here.

Did you replace each require module with aware of module?

No, just the one I mentioned. There was one other module ‘emr-api’ as a required dependency, which I didn’t touch.

In other words, if i got the reference application and simply replace require_module with aware_of_module in only that one module, would i reproduce the problem you are reporting of? java.lang.NoClassDefFoundError: org/openmrs/module/appointmentscheduling/AppointmentType

I think you would need to delete these two modules

appointmentschedulingui-1.7.0.omod and appointmentscheduling-1.10.0.omod .

Here is a commit on my fork which has the changes I am talking about.

There’s chances that a couple of conditional beans have to be put in place so that everything’s still fine when the non-required module is missing. That’s going to be the complicated part.

I’m saying that while skipping through this in 15 sec, so take it with a grain of salt.

@mksd, Or I would say the references to all aware_of_modules should be conditional if possible.

E.g.

if(appSchedulingModuleIsStarted){// do app scheduling stuff}

Here is the way to know if a module is installed and started. I am just not sure where is it referring to appointment scheduling type since I don’t see any references.

CC @dkayiwa

@dkayiwa, @mksd

I figured out the problem. It is not the reference-metadata module which is creating problem, but it is the reference-demodata which is giving those errors.

I removed the reference-demodata module and restart the server, it seems to be working as expected.

1 Like

Just adding some more information here. I was trying to fix the demodata module by putting a guard clause here like below:

		Module m = ModuleFactory.getModuleById("appointmentscheduling");
		if (m == null){
			log.info("Not creating demo data for appointment-scheduling since the appointment-scheduling module is not installed");
			return;
		}

While this should work, right now I feel it fails while creating bean for AppointmentTypeDeployHandler. This bean mentions AppointmentType as the Type for AbstractObjectDeployHandler. I think because of this it will always try to resolve AppointmentType as spring bean in the module startup.

I tried annotating it with @Lazy annotation but that was not helpful either. @dkayiwa, @mksd Do you have some info on how this could be tackled?

@dkayiwa,

I will create a card to change the reference-metadata omod to have aware_of dependency for appointmentscheduling instead of required.

As of now I cannot fix the reference-demodata because of the problem above. We will not be able to run reference-demodata without appointment-scheduling. I can actually change the reference-demodata to have a required dependency on appointment-scheduling since these two are tightly coupled. Let me know your thoughts.

CC: @mksd