The event module sends out the event asynchronously and I think it should stay that way, I personally don’t support the idea of completely changing this behavior just because of sync, how about if we make the behavior configurable?
@wyclif my understanding from the previous discussants is, since the current usage requirement is synchronous, they suggest making it the default, and then the asynchronous becomes the non default option that one has to turn on and configure.
What I am specifically suggesting (after only a small amount of thought, and no analysis) is that we’d change the event module to support two different things:
- synchronous event handling, where you get a callback directly from the hibernate interceptor. (This would guarantee you get the event delivered, and also allow you to rollback a DB transaction.)
- asynchronous event handling, where you get a callback “later”. (This is the current behavior, there’s a small chance that events get lost, you’re not allowed to rollback the transaction.)
- I would in fact like to make this optional, so that we can drop ActiveMQ as a requirement for distributions that don’t require async events.
@wyclif, do you know of any use cases where the event module is actually used?
I’m only aware of the registration core module, it fires events whenever a new patient is registered but it uses to fire events rather than listening for them. I think the atom feed modules also uses it to to listen for events.
Hey @pgesek, I just wanted to check, if we can help with anything else to move it forward. Did you have a chance to talk with Jakub about the timeline?
together with @alalo and @dserkowski, we are software developers at SolDevelo and we’ll start working on Sync 2.0. Currently, we are looking at the existing documentation and familiarizing ourselves with the project. In this week we will start by creating new tickets for the upcoming initial work and will end with a demo showcase sometime next week. We plan to work in two-week sprints. Every sprint will be started with an official introduction and ended with demo showcase. We want to start the first sprint in next week. We are excited to be part of this effort.
If you have any questions feel free to ask
we have two questions:
First, in the discussion above is mentioned about the new repository for Sync 2.0. May I ask for creation this if it doesn’t already exist?
Second, on the JIRA we prefer to use existing Sync Module (SYNC) project with new fix version ‘Sync 2.0’ or create new ‘Sync 2.0’ project? No matter which option you consider better, I would like to ask for creating a project or a fix version.
In the past we’ve had some discussions around sync 2.0, there were things that had to be decided and some of them are the same questions you have, doesn’t seem like we ever reached a decision, you can find the talk thread here.
(Wyclif this is in fact the same talk thread that you linked to.)
I’m going to make an executive decision on these points. Since there is no continuity of the codebase or design, and no intention for compatibility between this and the old sync:
- New repository (or repositories) for this codebase
- New JIRA project (or projects)
Note that the design envisions multiple collaborating components, that may also be reused outside of Sync, so I would expect that we’ll actually create multiple repositories, and multiple JIRA projects. (I do expect that there will be at least an openmrs-module-sync2 repo and a “Sync 2” JIRA project, and you might be able to build a sprint board within this JIRA project. Though I expect you will need to base the sprint board on a “sync2” label because you’re going to have tickets in multiple JIRA projects.)
Here is how you request a JIRA project: https://help.openmrs.org/customer/en/portal/articles/1439079-requesting-a-jira-project
For requesting a new code repository under the OpenMRS org, see https://wiki.openmrs.org/display/docs/Code+Repositories (the short answer is that you should write a new post in the #dev:repo-management category saying specifically what you want).
(If you’re new to this project and not 100% sure what details to put in, I can help figure that out.)
This project is going to be very valuable, and I’m really looking forward to seeing it happen.
we asked for repositories for Sync2 and atomfeed. Do we need to create a separate project on JIRA for the atomfeed repo or use the only Sync2?
Best regards, Przemyslaw
I would say have them separate
Okay, so I will create a new help desk case for this project, thank you for the reply.
Hi Everyone, we’ve started with implementation. Referring to this, we have one question.
- Do you want to add Travis CI to created modules?
Would be nice to do so
@pkornowski is there anything else that we need? Are there any blockers for the development?
Currently, we’re still preparing the environment for Sync 2.0 module. More precisely, we need Atomfeed and FHIR module. Our first step is to make these modules to be more generic, fix and implement some part of FHIR logic. Next, we’re going to start to implement Sync 2.0 logic. At first, this module will support only 2.0.X OpenMRS version.
We’ll have asked about some OpenMRS -> FHIR mappings in next week because not all exist and we’ll like to implement them.
When we’ll start implementing concrete Sync logic, it would be great if any org that use OpenMRS 2.0.X+ will be interested to use Sync 2.0 and giving us feedback about this. This should help us focus our results and meet user expectations.
A few thoughts/questions:
- some of the sync resources (Location, Provider) are covered by mCSD (an IHE profile of FHIR being supported by OpenHIE). See https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_mCSD.pdf
- It looks like the Parent-Child relationship would assume that there is only one server that a child would sync from? What about the case of an independent Client Registry that is FHIR compliant? Would you sync the non-patient resources with the parent and then (for both the parent and children) sync patient resources with the Client Registry? (Same question for a Facility Registry or Health Worker Registry using mCSD).
tl;dr you may want to have the option to have multiple FHIR servers for syncing different resources.
- As an FYI, there is an OpenHIM FHIR sync meditator (STU3) for practitioners https://github.com/openhie/openhim-mediator-fhir-sync which maybe could be extended to help manage your FHIR sync process(es) by providing a nice UI for periodicity of syncs and providing audit logs (e.g. ATNA). Not sure if @rcrichton knows of any similar mediators already in existence.