Difference between revisions of "25.10.2013 VME-DB"

Revision as of 12:24, 28 October 2013

Meeting 25 October 2013, 12:00-18:00 pm

Location: FAO, Rome.

Presents:

• M. Assante - CNR
• A. Ellenbroek - FAO
• A. Gentile - FAO
• E. Van Ingen - FAO

Agenda

12:00-13:00

Discussion: M. Assante, E. Van Ingen

• Status and presentations of the new tools
  • The gCube Reports Modeler
  • The gCube Reporting Library

13:00-14:00

Lunch Break

14:00-17:30

Discussion: M. Assante, A. Ellenbroek, A. Gentile, E. Van Ingen

• VME-DB / iMarine Interoperability
  • iMarine Templates Web Application
  • iMarine Reports Web Application
  • How to transform VME-DB Reports in iMarine Reports and viceversa.
  • How to save VME-DB Reports in iMarine Workspace

Notes

• iMarine VME-DB Application will be divided into 3 tiers:
  • [1] VME-DB: The Database containing the VME Reports (Relational/Graph Structure)
  • [2] iMarineReports: The WebApplication delegated to the creation and editing of VME Reports
  • [3] Report Storage Gateway (RSG): The (mediator) Webservice that will make [1] and [2]interoperable.

• The communication between [3] and [2]. will be based on a ReportModel that [2] is able to read and write.
  • CNR to provide FAO an API (ReportsModeler) to easily create and read ReportModel instances based on the gCube Reporting Library:

<groupId>org.gcube.portal</groupId>
<artifactId>gcube-reporting-library</artifactId>

• A VME Report (even its Fact Sheet Representation) originates from a Query (join) executed against the VME-DB.
  • As a result a VME Report contains unique and referenced (shared among other VME Reports) information.

Proposed solution: the main idea is to separate the editing of unique and referenced information.

From an end-user point of view

• When an end-user opens a VME Report in [2] (Report Instance in the following) he can edit only the Unique parts of the report, specifically, the ones belonging to the VME-DB relations named: VME, SpecificMeasure, Profile.

• The opened Report Instance contains also the references without giving the possibility of editing them (in this stage). The identified references are the VME-DB relations named: GeneralMeasure, InformationSource, History_1, History_2.

• It is possible for an end-user to associate and remove References from a Report Instance, e.g. remove or associate more than an InformationSource. The References list (where users can choose from) is populated in "real-time" by [2] trough a specific call to [3].

• A Report Instance can be saved in the workspace, an explicit action is required by the end user to export it to the VME-DB.

• The editing of References will be performed through a separated WebApp (CNR To Do) called Reference Editor. In the Reference Editor a reference can be edited through the following steps:
  • Step1: The list of VME Reports available is shown to the User, the User chooses a VME Report containing the Reference he wants to edit.
  • Step2: The list of the all the References "Associated" to the yet chosen VME Report is shown, User chooses the Reference.
  • Step3: At this point the User acquires a Lock on this Reference, the user edits and saves, the reference is committed in the VME-DB (still through [3]), the reference is unlocked.

• Each Report Instance having References is guaranteed to show the most updated ones since, wether the Report Instance comes directly from [3] or was previously saved in the workspace, [2] always asks [3] these references (that comes directly from [1]). ([3] passes [2] the reference identifier not the reference itself).

From an developer point of view

types: {Vme,Refs,InformationSource,GeneralMeasure,History1,History2}

A ReportRef has attributes id and type

[3] Draft Interface 

Type getTypes();
 
ReportEntry - List<nameValue>
 
List<ReportEntry> listReports(type);
 
ReportModel getReport(type, reportId);
 
publishDelta(List<ReportModel>);
 
publishRef(ReportModel);