I agree that this could be an opportunity to either fix the event module, or rewrite it such that we have something more useful.
The event module uses a hibernate interceptor to capture all changes to OpenmrsObjects. This is useful for Sync, and in general. We should leverage this, since it has been decently debugged, and even has some end-to-end test coverage.
The event module also delivers these events asynchronously (and outside of the hibernate/db transaction) using ActiveMQ. Sync’s atom feeds are already going to support asynchronous reading, and having the write happen outside of the hibernate transaction might be a problem if you end up losing events in some failure mode.
I’m concerned that working asynchronously via ActiveMQ will add an extra moving part and possibility of failure, that we don’t need. We should research this when deciding where to invest effort while working on Sync.
(Maybe this is an opportunity to remove the ActiveMQ dependency entirely, and make the event module simpler, just supporting a simple synchronous Java callback, and then move ActiveMQ into an extension module, if it’s even needed anywhere. @mseaton, @mogoodrich do you know if you’ve used Event anywhere outside of sending radiology orders in Mirebalais/PIH-EMR? )
@darius, we don’t use it beyond that as far as I know. I would definitely support moving the use of ActiveMQ to be optional in some way (or removing it altogether), and focus on supporting a synchronous mechanism to start. Even if we just support the modest goal of eliminating all custom of AOP and interceptors whose sole goal is to detect changes to one or more OpenMRS objects (which are all synchronous right now), and migrate these to use a common event module instead, this would be a reasonably big win.
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.
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.)
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.
