Event Module

classic Classic list List threaded Threaded
5 messages Options
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Event Module


My spike this week is around setting up an "atom feed" of changes in openmrs.  This will allow another system to ping openmrs periodically and know when new data is being entered or edited. (the wiki page for the atomfeed module is but a shell for now)

Executive summary:
  • The module is just called "event" and we hope to integrate it to core eventually to prevent module devs from having to AOP for messaging
  • The module registers AOP around the services for now
  • The module exposes things like "Patient created" "patient updated", "concept deleted", etc
  • Other modules can register to be notified of these Events using either Spring or a simple java call
You can see the longer api calls on the wiki page for the Event module:
https://wiki.openmrs.org/display/docs/Event+Module

I'd like to spend a few minutes on the design call today discussing this, but also feel free to voice ideas/opinions/outrage here as well.

Ben


[hidden email] from OpenMRS Developers' mailing list
Wyclif Luyima-2 Wyclif Luyima-2
Reply | Threaded
Open this post in threaded view
|

Re: Event Module

Since this will be using AOP, does it mean calls like patientService.addIdentifier(Patient, Identifier)(this is hypothetical) wouldn't be picked up by the event bus machinery, this is one of the reasons why i tend to be against convenience/short hand calls on services to create new entries via add/register() methods as sometimes we suggest during design calls.

Wyclif

On Wed, Apr 18, 2012 at 8:39 AM, Ben Wolfe <[hidden email]> wrote:

My spike this week is around setting up an "atom feed" of changes in openmrs.  This will allow another system to ping openmrs periodically and know when new data is being entered or edited. (the wiki page for the atomfeed module is but a shell for now)

Executive summary:
  • The module is just called "event" and we hope to integrate it to core eventually to prevent module devs from having to AOP for messaging
  • The module registers AOP around the services for now
  • The module exposes things like "Patient created" "patient updated", "concept deleted", etc
  • Other modules can register to be notified of these Events using either Spring or a simple java call
You can see the longer api calls on the wiki page for the Event module:
https://wiki.openmrs.org/display/docs/Event+Module

I'd like to spend a few minutes on the design call today discussing this, but also feel free to voice ideas/opinions/outrage here as well.

Ben


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: Event Module

The idea is that the event module would be updated if that method is added. The user would just need to listen to the appropriate event or a new event key if need be. The idea is that the other module author then doesn't need to keep track of the API and/or know all possible method calls in depth in order to know when something is changed.

Ben

On Wednesday, April 18, 2012, Wyclif Luyima wrote:
Since this will be using AOP, does it mean calls like patientService.addIdentifier(Patient, Identifier)(this is hypothetical) wouldn't be picked up by the event bus machinery, this is one of the reasons why i tend to be against convenience/short hand calls on services to create new entries via add/register() methods as sometimes we suggest during design calls.

Wyclif

On Wed, Apr 18, 2012 at 8:39 AM, Ben Wolfe <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;ben@openmrs.org&#39;);" target="_blank">ben@...> wrote:

My spike this week is around setting up an "atom feed" of changes in openmrs.  This will allow another system to ping openmrs periodically and know when new data is being entered or edited. (the wiki page for the atomfeed module is but a shell for now)

Executive summary:
  • The module is just called "event" and we hope to integrate it to core eventually to prevent module devs from having to AOP for messaging
  • The module registers AOP around the services for now
  • The module exposes things like "Patient created" "patient updated", "concept deleted", etc
  • Other modules can register to be notified of these Events using either Spring or a simple java call
You can see the longer api calls on the wiki page for the Event module:
https://wiki.openmrs.org/display/docs/Event+Module

I'd like to spend a few minutes on the design call today discussing this, but also feel free to voice ideas/opinions/outrage here as well.

Ben


<a href="javascript:_e({}, &#39;cvml&#39;, &#39;LISTSERV@LISTSERV.IUPUI.EDU?body\x3dSIGNOFF%20openmrs-devel-l&#39;);" target="_blank">Click here to unsubscribe from OpenMRS Developers' mailing list


<a href="javascript:_e({}, &#39;cvml&#39;, &#39;LISTSERV@LISTSERV.IUPUI.EDU?body\x3dSIGNOFF%20openmrs-devel-l&#39;);" target="_blank">Click here to unsubscribe from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Event Module

In reply to this post by Ben Wolfe (openmrs)
Are there two modules?  An event module seems appropriate to introduce an event bus that other modules can register with to send or list for event (e.g., providing the event management that an enterprise container like JBoss would); however, exposing these events as an ATOM feeds seems out of scope for an event bus module – i.e., I was expecting an event module to introduce an event bus and an atomfeed module that uses the event bus for the particular use case of exposing changes as ATOM feeds.

-Burke

On Wed, Apr 18, 2012 at 8:39 AM, Ben Wolfe <[hidden email]> wrote:

My spike this week is around setting up an "atom feed" of changes in openmrs.  This will allow another system to ping openmrs periodically and know when new data is being entered or edited. (the wiki page for the atomfeed module is but a shell for now)

Executive summary:
  • The module is just called "event" and we hope to integrate it to core eventually to prevent module devs from having to AOP for messaging
  • The module registers AOP around the services for now
  • The module exposes things like "Patient created" "patient updated", "concept deleted", etc
  • Other modules can register to be notified of these Events using either Spring or a simple java call
You can see the longer api calls on the wiki page for the Event module:
https://wiki.openmrs.org/display/docs/Event+Module

I'd like to spend a few minutes on the design call today discussing this, but also feel free to voice ideas/opinions/outrage here as well.

Ben


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: Event Module

That is exactly how it is split, sorry for the confusion. Should have put an extra sentence in there describing the dependency!

Ben

On Wednesday, April 18, 2012, Burke Mamlin wrote:
Are there two modules?  An event module seems appropriate to introduce an event bus that other modules can register with to send or list for event (e.g., providing the event management that an enterprise container like JBoss would); however, exposing these events as an ATOM feeds seems out of scope for an event bus module – i.e., I was expecting an event module to introduce an event bus and an atomfeed module that uses the event bus for the particular use case of exposing changes as ATOM feeds.

-Burke

On Wed, Apr 18, 2012 at 8:39 AM, Ben Wolfe <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;ben@openmrs.org&#39;);" target="_blank">ben@...> wrote:

My spike this week is around setting up an "atom feed" of changes in openmrs.  This will allow another system to ping openmrs periodically and know when new data is being entered or edited. (the wiki page for the atomfeed module is but a shell for now)

Executive summary:
  • The module is just called "event" and we hope to integrate it to core eventually to prevent module devs from having to AOP for messaging
  • The module registers AOP around the services for now
  • The module exposes things like "Patient created" "patient updated", "concept deleted", etc
  • Other modules can register to be notified of these Events using either Spring or a simple java call
You can see the longer api calls on the wiki page for the Event module:
https://wiki.openmrs.org/display/docs/Event+Module

I'd like to spend a few minutes on the design call today discussing this, but also feel free to voice ideas/opinions/outrage here as well.

Ben


<a href="javascript:_e({}, &#39;cvml&#39;, &#39;LISTSERV@LISTSERV.IUPUI.EDU?body\x3dSIGNOFF%20openmrs-devel-l&#39;);" target="_blank">Click here to unsubscribe from OpenMRS Developers' mailing list


<a href="javascript:_e({}, &#39;cvml&#39;, &#39;LISTSERV@LISTSERV.IUPUI.EDU?body\x3dSIGNOFF%20openmrs-devel-l&#39;);" target="_blank">Click here to unsubscribe from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list