...
The Reporting module already provides a generic UI to define and to view reports. Even though this is good for an adhoc approach, to get familiar with the Reporting module in general and specific requirements for reports, this is also "click-intense". Besides this for now these reports are bound to a specific OpenMRS database installation (unless clever ways of myqldump and -load are used). If reports need to be*
- version controlled,
...
- shared between different installation (like test and production env), or
...
- adopted for slightly different usecases while maintaining the general structure,
then it might make sense to externalize the creation of the various report elements. Besides the UI everything is accessible through the Java-API. With some Java knowledge, the creation of Cohort queries, Indicators and Report Definition can be scripted.
The "deployment" of reports can be done in 2 different ways:#
- Through a module, which provides the Administration feature to set up (and remove) persisted report elements (good for production systems).
...
- Through a (misused) Junit testcase, which can easily be invoked from the local development environment (good for development and testing).
An example can be found in the PIH Malawi module ([Source in SVN|http://svn.openmrs.org/openmrs-modules/pihmalawi/]). Please note that this is tailored to the needs of PIH Malawi, but it can serve as a blueprint for other installations.