Skip to content

feat(#114): Create OpenMRS Mediator#115

Open
witash wants to merge 70 commits intomainfrom
openmrs-mediator
Open

feat(#114): Create OpenMRS Mediator#115
witash wants to merge 70 commits intomainfrom
openmrs-mediator

Conversation

@witash
Copy link
Copy Markdown
Contributor

@witash witash commented Mar 14, 2024

Change mediator to accept unformatted documents from CHT and map them to FHIR resources that will be accepted by OpenMRS in the mediator.

Closes https://github.com/medic/config-gandaki/issues/25 https://github.com/medic/config-gandaki/issues/5 #124 #125

@witash witash changed the title feat(#114): Create OpenMRS Mediator for Patient resource feat(#114): Create OpenMRS Mediator May 16, 2024
@witash
Copy link
Copy Markdown
Contributor Author

witash commented May 16, 2024

#124 #125

@witash witash marked this pull request as ready for review May 27, 2024 09:41
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to add this to the startup.sh?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another thing about openmrs when testing locally it is now working.
A call to POST localhost:5001/mediator/cht/sync retutrn socket hang up
In OpenHIM transaction logs also:
GET openhim-core:5001/openmrs/Patient/?_lastUpdated=gt2024-05-27T16:41:02.989Z
getaddrinfo ENOTFOUND openmrs

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

latest commit should fix the error. but if openmrs is not running, sync doesn't do anything
also added it to startup.sh temporarily, although not every deployment will want a local copy of openmrs

the next problem is that this image has a very old version of the fhir module that doesn't work right, and its missing the cht identifier types; I fixed that locally by downloading the latest fhir omod from https://addons.openmrs.org/show/org.openmrs.module.openmrs-fhir2-module and running ocker cp ~/Downloads/fhir2-2.1.0.omod chis-interop-openmrs-1:/usr/local/tomcat/.OpenMRS/modules/fhir2-2.1.0.omod and manually creating the identifier types in the UI but need to dockerize somehow

@lorerod lorerod self-requested a review May 30, 2024 15:18
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@witash, can you please add the configs to cht-config so that we can reproduce the entire workflow in the e2e tests using only this repo and not depending on config-gandaki?
Let me know if I can help.
Thanks

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the config be private @binokaryg, as is the case with most of our projects?

@lorerod is there an alternative to testing in case the config cannot be copied in a public repo?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the config is private with limited access to collaborators.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andrablaj, from what I understand, we do not need the entire config. It's just an outbound push configuration and a couple of forms that do not need to be precisely the same. I’m right, @witash?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea, for the LTFU the configurator put the outbound push configuration in the settings automatically.
What we need to add/modify for tests is not anything specific to the gandaki config. a sample outbound push for cht form submission and inbound form for patient creation and inblound forms

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added the inbound forms and outbound for patient creation

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, with this, can I create a patient from CHT to Openmrs and vice versa?

@andrablaj andrablaj requested a review from binokaryg May 31, 2024 10:05
@lorerod
Copy link
Copy Markdown
Contributor

lorerod commented Oct 29, 2024

@witash I see that the last run for e2e test here is not failing with toomanyrequests: Rate exceede The fail error changed to this:

 Network cht-net  Creating
 Network cht-net  Created
 Volume "chis-interop_hapi-db-volume"  Creating
 Volume "chis-interop_hapi-db-volume"  Created
 Container chis-interop-configurator-1  Creating
 Container hapi-db  Creating
 Container openhim-mongo  Creating
 Container openhim-mongo  Created
 Container chis-interop-configurator-1  Created
 Container hapi-db  Created
 Container openhim-core  Creating
 Container mediator  Creating
 Container hapi-fhir  Creating
 Container mediator  Created
 Container openhim-core  Created
 Container openhim-console  Creating
 Container hapi-fhir  Created
 Container openhim-console  Created
 Container chis-interop-configurator-1  Starting
 Container hapi-db  Starting
 Container openhim-mongo  Starting
 Container chis-interop-configurator-1  Started
 Container mediator  Starting
 Container openhim-mongo  Started
 Container openhim-core  Starting
 Container hapi-db  Started
 Container hapi-fhir  Starting
 Container hapi-fhir  Started
 Container mediator  Started
 Container openhim-core  Started
 Container openhim-console  Starting
 Container openhim-console  Started


   Possible URLs after startup:
   -----------
   OpenMRS         http://localhost:8090/
   OpenMRS MySQL   localhost:3306
   CHT Core        https://localhost:8843/
   OpenHIM Console http://localhost:9000/


Waiting for configurator to finish...
Error response from daemon: No such container: chis-interop-cht-configurator-1

The configurator container name changed from chis-interop-cht-configurator-1 to chis-interop-configurator-1


echo 'Waiting for configurator to finish...'
docker container wait chis-interop-configurator-1
docker container wait chis-interop-cht-configurator-1
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The container name should be: chis-interop-configurator-1
As this is failing.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

chis-interop-configurator and interop-cht-configurator are two different containers. chis-interop-configurator sets up openhim configuration, chis-interop-cht-configurator runs cht-conf to add the cht config for e2e-tests

I guess it should be waiting for both here

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I don't see interop-cht-configurator creation in the logs.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, I don't see an interop-cht-configurator container. @witash are we missing anything?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When running the test locally, there is an interop-cht-configurator. In CI the behavior is different, maybe due to the [too](toomanyrequests: Rate exceede) problem.

Locally the OpenMRS tests are failing :

Workflows
    OpenMRS workflow
      ✕ Should follow the CHT Patient to OpenMRS workflow (4710 ms)
      ✕ Should follow the OpenMRS Patient to CHT workflow (204 ms)
    Loss To Follow-Up (LTFU) workflow
      ✓ Should follow the LTFU workflow (8371 ms)

● Workflows › OpenMRS workflow › Should follow the CHT Patient to OpenMRS workflow
> 140 |       expect(retrieveFhirPatientIdResponse.body.total).toBe(1);

  ● Workflows › OpenMRS workflow › Should follow the OpenMRS Patient to CHT workflow
> 177 |       expect(retrieveFhirPatientIdResponse.body.total).toBe(1);

Both asserting that the patiend ID was created in Fhir.
I'm testing this manually to see if I can reproduce it.

# Cleanup from last test, in case of interruptions
retry_startup() {
max_attempts=5
count=0
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In L17 I introduced a bug. I think the correct command would be ./startup.sh up-test instead of ./startup.sh init

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed with 59bf494

@lorerod
Copy link
Copy Markdown
Contributor

lorerod commented Nov 7, 2024

Changes to make e2e tests pass:

  • Implemented retry logic to pull cht images. The first run in the CI couchdb image is the only one that needed three retries to complete the pull.

  • Skipped openers to cht the patient creation scenario because it is incomplete. I will work on this scenario as part of Update automated tests for CHT and OpenMRS endpoints in the mediator #123

  • Re-enabled e2e test in ci. It is green now. Let's keep an eye on it to see if we can identify the images that give rate-exceeding errors.

PASS test/workflows.spec.ts (26.552 s)
  Workflows
    OpenMRS workflow
      ✓ Should follow the CHT Patient to OpenMRS workflow (11459 ms)
      ○ skipped Should follow the OpenMRS Patient to CHT workflow
    Loss To Follow-Up (LTFU) workflow
      ✓ Should follow the LTFU workflow (6089 ms)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants