I want to clone and run the Bahmni Atom feed module.I don’t have idea about vagrant.I want to simply run and test it with simple.Can some one please guide how I can run this module.What are development I needs to setup.
Did you see this: ‘Atom Feed Based Synchronization in Bahmni’?
There is a bunch of reading starting from that page.
What do you mean by?
test it with simple
There are two modules availables one is for openmrs atom feed module which is pretty old.I am looking for the bahmni-atom-feed module which they developed using ATOM library for the interaction with openelis.I want to run that module on Bahmni,Is it possible to run the module?
Is this what you are looking for?
openmrs-elis-atomfeed-client, one of the subprojects of Bahmni Core.
Yes,I have looked at it.Actually I have a use case where I need to connect openmrs with odoo11.Is there any available module which provides this solution?
You can look at this repo to start with. This repo actually works as a Channel Adapter between MRS and ERP. It receives messages from MRS feeds, does the necessary transformation and invokes relevant API calls (XML-RPC) on ERP side. We have ERP side modules that expose certain APIs but potentially you can define your own modules on ERP to expose suitable endpoints or even leverage the existing ERP XML-RPC apis. If you are okay to invest, I think Odoo 11 has decent paid for json REST API plugins as well.
Thanks for the detailed reply.I am also looking at your openmrs-atom-feed module.Does that module works with openmrs.I am trying to build it but getting error.I have started thread please have a look.openmrs-atomfeed module error while building. Please confirm does this module will work with openmrs platform 1.11.9 or 2.x.
Hmm, I can rebuild this without any problem
mvn clean install
That does the job for me. From the other link with paste bin link, this seems like its failing on running some test. I am compiling with Java 8 (1.8.0_112). But I don’t think the JRE/JDK version is the problem.
May I ask what you are trying to achieve by rebuilding? This would make total sense if you are forking and modifying the codebase. However, if you want to use the OMOD, then the idea would be to write another OMOD and have “openmrs-atomfeed” as dependency from your OMOD.
Dependency wise, this OMOD needs legacy-ui and emr-api runtime. Not perfect! We should probably do without emr-api dependency, but this will require moving some code.
If your objective is to understand how the publishing of an “event” or consumption of “events” happen, then you can just look into the core library here, follow the tests in “atomfeed-server” and “atomfeed-client” sub modules.
Thanks @angshuonline my first task was to understand how publishing of an "events"and consumption of “events” happen.The main objective is to understand the atom-feed and used it to connect with openElis as Bahmni does.Can you please tell how your module helps us to achieve this.If your module works for us,then I don’t think we need to build another module from scratch. Just to clear thing we have EMR based on openmrs platform and we are acheiving the same things as bahmni does for the synchronization between Elis and ERP(odoo) which in our case will be odoo11.
Well, we push an event using the atomfeed core apis. and the client side keeps polling for any new events in the feeds.
-
Pushing events - You can follow the code here
-
Consuming events - ELIS - start here and more specifically for the consumption of encounter events here
Imagine, I have only only OpenMRS and I want to integrate with OpenELIS, and none of the components have anything relevant to Bahmni. (assume you are using latest version of ELIS from OpenELIS Global)
- On OpenMRS Side, use the openmrs-atomfeed module (version 2.5.6?) - you will need emr-api module as well.
- On OpenMRS: Assuming you want to raise events on patient creation or encounter creation etc - use your own code or rely on the OpenMRS-Atomfeed default advices (applicable if you are using emr-api endpoints). If you want to write your own code - you can just do that from server side calling - “eventService.notify(event)” where event is something you decide for content and meta information. check how bahmni raises events in patients or encounter (links above)
- On OpenMRS: you need to be running this scheduler : “OpenMRS event publisher task”.
ELIS Side or ERP Side
- You poll for events. check the links that I mentioned above to get an idea.
- Usually we keep running a scheduled job (quartz on elis, or openmrs scheduled task) - that polls for events given the URL and other properties (like auth details)
- You will need a set of client side tables to be created on ELIS side. Check here. The similar thing is done when OpenMRS is the consumer, check here. In OpenMRS it is done at the module startup time. In ELIS, we do that at the time of app setup.
- You would write your own event processor, check any implementation of “EventWorker” above.
If you would want to write and wire everything on your own, you can do it as well, using the core libraries.
- You will find them here, or just use maven to pull the core libraries. See here on oss nexus for all atomfeed core libraries (version 1.9.4)
The concepts of the “simplefeed” protocol built over atom specs (we just call the library atomfeed) is documented in detail
- Simple protocol description
- Another detailed description here
Hope the above helps!
1 Like
@angshuonline i have been trying to start the generated war from this repo on my local installation which is giving me these error log. I am trying to run it on Tomcat 9.
Well, we usually deploy each service as rpm. These services are runnable on their own, and the rpm package installation does some of the essential pre and post installation tasks. Running automated database scripts (like migrations creating database, users, tables etc) is one of them.
I think (and the log files says so … “quartz_cron_scheduler” does not exist) thats what is happening. If you are going to deploy war inside a running tomcat, then you need to ensure
- run the database migration scripts. Take a cue from here
- ensure that some of the system parameters like ‘OPENERP_DB_SERVER’, ‘OPENERP_DB_PASSWORD’ etc etc are passed appropriately.
Your Documentation (GitHub - ICT4H/simplefeed: A simple Atom-based protocol for broadcasting a feed of events.) states following capability:
The provider might choose to make each document represent a period of time e.g. a day, or might divide the series of events evenly so that each document has e.g. 100 entries.
Maybe you can tell me where i can configure the retention period e.g 100 entries or 1 day before archiving is triggered for a normal bahmni/openmrs installation?
BR, Johannes
The “simplefeed” protocol you referred is a spec, rather than an implementation by itself. However, if you are talking in openmrs/bahmni system(s) context with an implementation such as “atomfeed module”, which wraps the core library “atomfeed”, then
- there is currently only one implementation - which is to generate the feed with a specified “number of entries” in the feed document.
- for this, look for a table “chunking_history” in the database, and there you can mention what should the numbers the documents should respect. For example:
mysql> select * from chunking_history; +----+--------------+-------+ | id | chunk_length | start | +----+--------------+-------+ | 1 | 5 | 1 | | 2 | 20 | 6 | +----+--------------+-------+
In the above:
- the 1st feed (feed/1) in generated with 5 entries, starting with the event id = 1. (note, corresponds to event_records.id)
- However, starting with the feed/2, it returns 20 entries, that starts from id=6.
Meaning, with the above configuration
- F/1= 5 entries (entries ranging from 1-5)
- F/2 = 20 entries (Ranging from 6-25)
- F/3 = 20 entries (Ranging from 25-45)
and so on
Word of caution:
- Make sure you do not go and retrospectively change the database values, as this can throw the other systems subscribing to the feed out of sync. So better to do right at the begining.
- For some reason, if you want to change (e.g. to accomodate more events per feed), then do not change older configuration, but rather add a new one - where you should mention the right event_id the new “chunks” start from, and of desired length from now onwards.