Exporters¶
Denodo Scheduler allows new custom exporters to be created.
To create a new exporter the interface
com.denodo.scheduler.api.exporter.Exporter
needs to be implemented.
This interface has the following methods:
init
. Initializes the exporter and optionally tests whether the data targets (if any) are reachable and correctly configured.export
. Method invoked by Scheduler to perform the document export.getName
. Method invoked by Scheduler to get the name of the exporter.
Another interface called
com.denodo.scheduler.api.exporter.SchedulerExporter
can be
implemented in order to provide information about the job execution time
(the first time the job was executed, before retrying it, if it was
necessary), the job retry number and the retry execution time. This
interface has the following methods:
open
. Initializes resources needed by the exporter and gets runtime information about the executed job.close
. Closes any resources opened by the exporter and returns a collection of resources if necessary. For instance, you can return the path of a file generated by the exporter, as shows the following code snippet. Then, you could get those resources in a handler.
Collection<ExporterResource> resources = new LinkedHashSet<ExporterResource>();
resources.add(new DefaultExporterResource(outputPath));
return resources;
Exceptions thrown by both methods will be shown at the job report.
This interface is extended by the interface
com.denodo.scheduler.api.exporter.SchedulerExporterExtended
, which
provides two new methods:
isOpen
. Should return true if the exporter was successfully opened and has not been closed yet.isClosed
. Should return true if the exporter has never been opened or it has already been closed. Closed exporters will not receive new documents to export from Scheduler, while the others will. This way, if an exporter fails in itsopen
method, it will receive no documents to export, with the consequent improvement in performance.
CSV and SQL exporters implement this interface in order to just open the exported files once, write everything and close them. JDBC exporters implement this interface in order to just open once the connection against the database, delete the table content (if configured), insert the exported tuples and close it (if configured to never rollback, see section Postprocessing Section (Exporters)). New user-defined exporters may also implement this interface.
JDBC exporters implement the interface
com.denodo.scheduler.api.exporter.batch.ExporterBatch
which defines
one method:
getBatchSize
. Returns the batch size configured for the exporter (see section Postprocessing Section (Exporters)).
User-defined exporters may also implement this interface. Implementing
ExporterBatch
will allow configuring the number of documents
received on each call to the exporter’s export
method. It is
recommended that custom exporters that implement ExporterBatch
define a configuration parameter for specifying the batch size. This
way, users will be able to configure the exporter’s batch size
graphically. When ExporterBatch
is not implemented, the default
batch size will be 200.
Custom exporters may also implement the interface
com.denodo.commons.schema.ISchema
which defines one method:
setSchema(com.denodo.commons.schema.Schema schema)
. Provides the exporter with the schema of the data being exported by the Scheduler server. This method is called by the Scheduler server before theopen
method ofSchedulerExporter
is called, so exporters implementingISchema
andSchedulerExporter
can know the schema of the exported data before initializing the resources needed by the exporter (for example, before creating a table in a DB).
For more information please refer to the Denodo Scheduler Javadoc
documentation or the example for creating an exporter in
DENODO_HOME/samples/scheduler/exporter-api
.