BIRT has a scripted data source that can be used to read in a JSON object. You need to override the open method on the data source (within each report) to convert the JSON object to a more table-like dataset, but it doesn't look too complicated. JasperReports probably has something similar.
Justin On Thu, Feb 23, 2012 at 8:17 AM, Ben Wolfe <[email protected]> wrote: > The created version was very close to C. Cohorts and datasets are not > persisted aver evaluation in the reporting module. So each subsequent call > is a new query to the db. > > Yes, it can handle any number of parameters, spring just passing all the > httprequest object. > > The result is a json object. If BIRT or Jasper can read that, then we're > golden. Kettle/Spoon in Pentaho doesn't read it natively, so Darius is > creating the plugin to know what to do with the results. > > Ben > > > On Wed, Feb 22, 2012 at 12:42 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < > [email protected]> wrote: > >> +1 for C with modifications**** >> >> ** ** >> >> Can Spring handle an arbitrary set of parameters?**** >> >> ** ** >> >> Aren't cohorts/datasets persistent? Part of the session context? Does >> it make sense not to evaluate an already evaluated cohort/dataset on GET? >> That is**** >> >> GET /ws/reporting/cohort?cohortdef=uuid¶m1=value1[¶m2=value2…] -> >> evaluates a cohort def (error if cohortdef not provided or uuid does not >> represent a cohort definition)**** >> >> GET /ws/reporting/cohort/uuid -> returns an already-evaluated cohort >> (error if uuid does not represent a cohort)**** >> >> DELETE /ws/reporting/cohort/uuid -> deletes an already-evaluated cohort >> (no error if uuid is not a cohort)**** >> >> similar for dataset**** >> >> ** ** >> >> Also we should make sure that the transformation of whatever we return >> into something usable by BIRT or Jasper reports is easy as pie**** >> >> ** ** >> >> *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Burke >> Mamlin >> *Sent:* Friday, February 17, 2012 11:35 AM >> *To:* [email protected] >> *Subject:* Re: [OPENMRS-DEV] Reporting Web Service**** >> >> ** ** >> >> Given that we'd like to converge toward a convention of exposing RESTful >> web services, I prefer #2:**** >> >> ** ** >> >> /ws/reporting/******** >> >> ** ** >> >> If we want to support different protocols (e.g., SOAP or some new >> protocol that comes along in the future), I'd rather namespace those >> somewhere other than /ws/**** and remove unneeded redundancy from our URLs. >> **** >> >> ** ** >> >> -Burke**** >> >> On Fri, Feb 17, 2012 at 11:01 AM, Wyclif Luyima <[email protected]> >> wrote:**** >> >> Keep in mind that web service URLs starting with '/ws' are not supported >> for 1.8.0 and earlier versions, i would like us to use this chance to >> probably come up with a convention for modules' REST URL pattern, this will >> allow to probably register common web service filters that can be shared >> across all modules that follow the convention.**** >> >> ** ** >> >> Probably the options we have are:**** >> >> 1. /ws/reporting/rest/******** >> 2. /ws/reporting/******** >> 3. /ws/reportingrest/******** >> >> ** ** >> >> I prefer 1.**** >> >> ** ** >> >> Wyclif**** >> >> ** ** >> >> On Fri, Feb 17, 2012 at 10:52 AM, Darius Jazayeri < >> [email protected]> wrote:**** >> >> Saptarshi, I agree that we should support searching for cohort >> definitions via a query. Just that Burke wrote it out as using a >> "cohortdefinitions" resource (with an s) to query, and a "cohortdefinition" >> resource to fetch. And I'm disagreeing with that.**** >> >> ** ** >> >> -Darius**** >> >> ** ** >> >> On Fri, Feb 17, 2012 at 5:21 AM, Michael Seaton <[email protected]> wrote:* >> *** >> >> Darius, >> >> This looks good to me. I have a strong preference for Option 2 - using a >> Map from column name -> value rather than an array of values in order. >> >> Mike**** >> >> >> >> On 02/17/2012 01:02 AM, Darius Jazayeri wrote: **** >> >> +1 for reporting without the rest. >> >> I do like Option C--at least as I'm interpreting it it's basically Option >> A, but with a more intuitive resource name. >> >> So basically: >> GET /ws/reporting/cohortdefinition -> list all cohort definitions **** >> >> POST /ws/reporting/cohortdefinition -> create a cohort definition (save >> for later)**** >> >> GET /ws/reporting/cohortdefinition/{uuid} -> get one cohort definition*** >> * >> >> POST /ws/reporting/cohortdefinition/{uuid} -> edit a cohort definition >> (save for later)**** >> >> ** ** >> >> GET|POST /ws/reporting/cohort -> error**** >> >> GET /ws/reporting/cohort/{uuid}?[param=value&cohort=uuid] -> evaluates a >> cohort, supports params and base cohort**** >> >> POST /ws/reporting/cohort/{uuid} -> error**** >> >> ** ** >> >> So, the other question up for vote...which way of representing data set >> rows should we use? (I have a weak preference for option 2.)**** >> >> ** ** >> >> metadata: {**** >> >> columns: [ { name: "name", label: "Pretty Name", datatype: >> "java.lang.String"}, ... ]**** >> >> },**** >> >> rows-option-1: [**** >> >> [ "Alice", 5, true ],**** >> >> [ "Bob", 7, true ]**** >> >> ]**** >> >> rows-option-2: [**** >> >> { givenName: "Alice", age: 5, hasAllVaccinations: true },**** >> >> { givenName: "Bob", age: 7, hasAllVaccinations: true }**** >> >> ]**** >> >> ** ** >> >> -Darius**** >> >> On Thu, Feb 16, 2012 at 8:06 PM, Michael Seaton <[email protected]> wrote:* >> *** >> >> Hey Darius, >> >> I've been staring at these choices and keep going back and forth among >> all 3, so I guess I don't have a strong preference. I would lean towards >> whatever best fits in with standard practice and convention. Option C >> seems like my preference at the moment, but I'm going to hit send before I >> change my mind again. One tangential question - can we use >> /ws/reporting/... rather than /ws/reportingrest/... ? Isn't "rest" implied >> here? I'm happy for "reporting" to give up it's namespace to >> "reportingrest" with an objective of one day bringing that functionality >> into the reporting module and doing away with the reportingrest module... >> >> Mike **** >> >> >> >> >> On 02/16/2012 08:32 PM, Burke Mamlin wrote: **** >> >> What about Option C? **** >> >> ** ** >> >> GET|POST /ws/reportingrest/cohortdefinition/{uuid}**** >> >> GET /ws/reportingrest/cohortdefinitions[?q={query}]**** >> >> GET|POST /ws/reportingrest/datasetdefinition/{uuid}**** >> >> GET /ws/reportingrest/datasetdefinitions[?q={query}]**** >> >> GET /ws/reportingrest/cohort/{uuid}**** >> >> GET /ws/reportingrest/dataset/{uuid}[?param=value[¶m2=value2]]**** >> >> ** ** >> >> -Burke**** >> >> ** ** >> >> On Thu, Feb 16, 2012 at 7:46 PM, Darius Jazayeri <[email protected]> >> wrote:**** >> >> Hi All, especially Mike, Burke, and Saptarshi, **** >> >> ** ** >> >> While working on the Pentaho sprint, we've realized that it one key way >> to help people populate data warehouses from OpenMRS without writing lots >> of brittle SQL is to write a PDI plugin for Kettle that accesses OpenMRS >> data via web services. We've always intended to have the Reporting module >> expose the ability to evaluate cohorts and datasets via web service. This >> will be broadly useful, but this sprint gives us an excuse to do it.**** >> >> ** ** >> >> So, we want to let Reporting expose the list of available >> CohortDefinitions, and DataSetDefinitions, and allow you to evaluate those, >> RESTfully. Ben and I discussed this today and came up with two approaches, >> so we wanted to get opinions about which way to go. Ben plans to code one >> up tomorrow morning...**** >> >> ** ** >> >> *Option A (Exposes more of the way the Reporting module really works. I >> prefer this, though it may be more confusing.)***** >> >> ** ** >> >> *Definition Resources***** >> >> ** ** >> >> GET /ws/reportingrest/cohortdefinition -> list of all cohort definitions >> **** >> >> GET /ws/reportingrest/cohortdefinition/UUID -> one particular cohort >> definition**** >> >> ** ** >> >> GET /ws/reportingrest/datasetdefinition -> list of all DSDs**** >> >> GET /ws/reportingrest/datasetdefinition/UUID -> one particular DSD**** >> >> ** ** >> >> Also allow definitions to be created and edited via POSTs**** >> >> ** ** >> >> cohortdefinition resource: >> uuid >> name >> description (in default) >> list of parameters (in default) >> href to /ws/reportingrest/evaluatedcohort/UUID // tells you how to >> evaluate this**** >> >> ** ** >> >> datasetdefinition is similar**** >> >> ** ** >> >> *Definitions are evaluated via different resources***** >> >> ** ** >> >> GET /ws/reportingrest/evaluatedcohort // ERROR**** >> >> GET /ws/reportingrest/evaluatedcohort/UUID // evaluate the >> cohortdefinition with that UUID >> >> GET /ws/reportingrest/evaluateddataset // ERROR >> GET /ws/reportingrest/evaluateddataset/UUID?date=2011-01-01 // evaluate a >> DSD that has a "date" parameter against all patients >> GET /ws/reportingrest/evaluateddataset/UUID?cohort=UUID&date=2011-01-01 >> // evaluate a DSD with a parameter against a specified cohort **** >> >> ** ** >> >> evaluateddataset resource:**** >> >> uuid // of the underlying DSD**** >> >> metadata // column definitions, etc**** >> >> rows // either a list of lists (in the order of the columns in >> metadata) or a list of column.name -> cell value maps**** >> >> ** ** >> >> *Option B (Simpler, and doesn't expose the key definition/evaluated >> distinction from Reporting. Ben prefers this.)***** >> >> ** ** >> >> *A single resource for each definition/evaluated pair***** >> >> ** ** >> >> GET /ws/reportingrest/cohort -> list all cohort definitions (as v=ref)*** >> * >> >> GET /ws/reportingrest/cohort/UUID -> specific definition (as v=default)** >> ** >> >> GET /ws/reportingrest/cohort/UUID?v=evaluated -> expensive operation; >> evaluates the cohort and includes the result as a "members" property**** >> >> GET /ws/reportingrest/cohort?v=evaluated -> ERROR**** >> >> ** ** >> >> cohort resource**** >> >> uuid // of the cohortDefinition**** >> >> name**** >> >> description (in v=default)**** >> >> members (in v=evaluated)**** >> >> evaluationContext (in v=evaluated)**** >> >> ** ** >> >> GET /ws/reportingrest/dataset -> list all DSDs (as v=ref)**** >> >> GET /ws/reportingrest/dataset/UUID -> specific DSD (as v=default) >> GET /ws/reportingrest/dataset/UUID?v=evaluated -> evaluates the DSD >> GET /ws/reportingrest/dataset/UUID?v=evaluated&date=2011-01-01 -> >> evalutes DSD with a date parameter >> GET /ws/reportingrest/dataset/UUID?v=evaluated&cohort=UUID -> evaluates >> DSD against a specified cohort **** >> >> ** ** >> >> This doesn't lend itself to letting you create cohort definitions or DSDs >> by POSTing to WS, at least not via these resources.**** >> >> ** ** >> >> -Darius**** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> >> ** ** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> >> ** ** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> >> ** ** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> >> ** ** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> >> ** ** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
