Reporting Web Services and Pentaho Integration Enhancements
Primary mentor | @Lluis Martinez |
Backup mentor | TBD |
Assigned to | @Sashrika Waidyarathna |
Abstract
Reporting REST web services exposes the reporting module's definitions via REST web services. We would like to leverage this to make it easier for people to use business intelligence tools, like Pentaho, with OpenMRS reporting data.
Actually there is a working prototype of a Pentaho Data Integration plugin for Eclipse, that pulls data from OpenMRS via the reporting REST web services. This plugin uses Eclipse's SWT (Standard Widget Toolkit) for the user interface.
Project Champions
TBD
Objectives
Proposed improvements
Support for listing and evaluating all different kinds of definitions (currently only cohort definition and dataset definition are supported)
Support for evaluating an entire report
Optionally, to have the ability to queue report requests
The plugin that allows Kettle (aka Pentaho Data Integration) to consume reporting REST services to apply transformations can be improved as follows:
User interface should support different types of parameters
Add support for more kinds of queries to the reporting REST services
Extra Credit
Resources
Reporting REST web services module
Note that it is not necessary to have a PDI plugin; this was developed before REST existed. The OpenMRS REST API can be used directly with Pentaho; due to a problem on the Pentaho side (perhaps due to the ugly xml we were producing then), it cannot be consumed by a REST widget but can be consumed by an HTTP widget (at least this was the case 6 months ago when I last did it).
The problem with reporting is that its objects seem to be transient, and if cohorts, datasets and reports can be made persistent, I think they should be child objects of the definitions which created them. Whether the presence of serialized objects within the reporting data model breaks the REST paradigm needs to be investigated.
There was some discussion around the REST module about how "action" calls should be handled, for example, the triggering the generation of a report. The discussion was small, but the idea was to use "PUT" calls because they are not idempotent; the body of the call would contain parameter values. This same capability is needed for the OpenMRS-SDMX-HD-DHIS2 integration project.