Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
Child pages
  • Reporting Web Services and Pentaho Integration Enhancements
Skip to end of metadata
Go to start of metadata

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 module

Reporting REST web services module

Pentaho Kettle

Writing a Pentaho Kettle plugin

PDI plugin for OpenMRS

1 Comment

  1. 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.