Phase 1, MongoDB as a Native PRD Datasource, Implementation Status

Implementation Details

The embedded datasource project has been implemented in the context of MongoDB as a native datasource in Pentaho Reporting.  MongoDB is now the first embedded datasource in the Pentaho Reporting project.

We did remain close to the architecture as it is described in the Embedded Datasource Architecture document. In most cases, the only deviation is where we have not yet completed all the requirements as described in the doc, but still wish to do so. Here is the specific list where we are not yet complete (straight from the architecture doc):

1. In cases where there is no available cross-platform compatible UI, then the tradition PDI datasource UI is displayed for the user. We have plumbed for this, but have tested it and it is not working. So it is incomplete, but should be close.
2. If no output step is defined, the input step becomes the output step. We have not coded this failover. You must have an output step today.
3. Under certain "advanced mode" circumstances, different datasource query types can belong to the same datasource. In this case, the name of the datasource will be "Mixed Type Datasource". (//TODO: think of a better name for this) We do not support "mixed mode" at all right now. If the advanced user creates this environment, results are undefined.

See the steps below for specifics like template location and template specific requirements.

Steps for Creating a New Embedded Datasource for Pentaho Reporting

1. Create a Kettle transformation template.
   1. The name of the KTR file is the name that will display in Pentaho Report Designer under the New Datasource.... menu options.
   2. The transformation must have at least two steps. The configuration step, typically the data source step, must be labeled "input". The step to retrieve the resulting rows from must be labeled "output". You may have any number of steps in between, before or after these two steps.
   3. The configuration step must have a XUL dialog user interface that supports at least the XUL Swing libraries, descended from the org.pentaho.di.ui.trans.step.BaseStepGenericXulDialog class in the PDI project. This dialog should reside in the same package as the PDI step dialog. The dialog name should be prefixed exactly like it's PDI companion, but the suffix should replace the "Dialog" portion of the name with "XulDialog". This naming discrepancy should go away when PRD-4513 is implemented. The idea is to support existing dialogs that are not XUL-ified, while encouraging designers of new steps to create XUL dialogs for steps that can support the PDI SWT side and the PRD Swing side without having to write the UI twice. 
2. Once created, the template should be placed in the PRD distribution under the resources/datasources folder.
3. The classes for the step and its user interface parts must be available to the Kettle and Pentaho Report Designer classpaths. The simplest way to meet this requirement is to create the project as a PDI plugin.

While these are the generic steps for creating a new embedded datasource, there may be hiccups in some of the details around the dialog. Because of the PRD query container still being a native Swing dialog, there may be some wiring needed to get both Preview functionality and valid enabled states on the dialog to function correctly. The second implementation should help us iron some if this out, as well as resolving case PRD-4512. I recommend looking closely at the XUL definition for the MongoDB dialog, as well as its model and controller, org.pentaho.di.ui.trans.steps.mongodbinput.models.MongoDbModel and org.pentaho.di.ui.trans.steps.mongodbinput.MongoDbInputXulDialog.

Next Phase: Case Backlog

The following items have been logged as a backlog for the next phase of the embedded datasource project.

BAD-39 Instaview and Reporting embedded datasource templates: create concrete ID (UI and architecture)