Export Script¶

The export script exports the metadata of a Virtual DataPort Server. The features of this script are equivalent to the “Export” and “Export database” dialogs of the Administration Tool (see section Exporting and Importing the Server Metadata).

The metadata can be exported to:

A file that contains all the VQL statements to recreate the exported elements (option --file)
Two files (option --property includeProperties):
1. A file that contains the VQL statements of all the elements of the database. The values of the parameters that depend on the environment are variables instead of the actual values.
2. And, a properties file that contains the values of the variables. See more about this in the section Export to a File with Properties.
Or, a Repository: the metadata is stored in a set of files, where each file contains the VQL statement to create an element (option --repository).

After the exporting process, there will be a folder for each virtual database of the Server. In each of these folders, there will be a folder for each type of element: folders, data sources, views, etc. And in them, a file for each element, which will contain the VQL statement to create that element. This is useful if you want to use a revision control system such as Version Control System (VCS) to keep track of the changes in the metadata and the configuration of a Server.

Note

If you want to store the metadata of the Server in a VCS, we recommend using the VCS integration of Virtual DataPort (see section Version Control Systems Integration). However, you may need to export to repository if your VCS is not supported.

This script is located in the directory <DENODO_HOME>/bin and its syntax is the following:

export --login <login> [ --password <password> ]
       [ --configurationfile <filename> ]
       --server [//]<host>:[<port>][/<database name>] [ --nobom ]
       [ --metadatapassword <password> ]
       {   --file <filename>
         | --repository <path to repository>
           [ {   --element <path to element>
              | --repository-element <identifier path> }
           ]*
       }
       [ --singleuser ] [ -P <property name>=<property value> ]*
       [ --view <views> ]


export --revision -l <login> [ -p <password> ]
       [ -cf <configurationFile> ] h <URI> -f <outputFilename>
       -fc <from_commit> [ -tc <to_commit> ]
       [ -P includePrivileges=yes|no ]
       [ -P includeServerConfiguration=yes|no ]

Parameters of the export script¶
Parameter Name	Description
-l --login <login>	Login name used to connect to the Server. `<login>` has to be an administrator if you want to export all the metadata of the Server.
-p --password <password>	Password used to connect to the Server. Use the script `encrypt_password` to encrypt the password. That way you can avoid entering it in plain text. E.g. `--password encrypted:Gr16MjvuXhRzPtPH/yTXHw==` If you do not provide the parameter `-p` nor `-cf`, the script will prompt you for your password.
-cf --configurationfile <filename>	File with one line that contains this: `password=<password>` or this: `password=encrypted:<encrypted_password>` Use the script `encrypt_password` to encrypt the password. That way you can avoid entering it in plain text. Incompatible with -p.
-h --server <URI of the Server>	URI of the Server (<host>:[<port>][/<database name>]) If `<database_name>` is present, the script exports the metadata of `<database_name>`. If it is missing, the script exports the metadata of all the virtual databases and also the settings of the Server.
-f --file <filename>	Name of the target file where the VQL statements will be stored. This option is not compatible with the option `--repository` (`-r`)
-z --zip	If present, the script compresses the result on a zip file.
-nb --nobom	If you add this parameter, the script generates the output files without the “Byte order mark” (BOM). By default, the script adds the BOM mark to the output files to indicate that they are encoded in UTF-8. Thanks to this mark, the applications that have to read these files can quickly detect their encoding without having to guess it. However, there are applications that cannot handle the BOM. In that case, add this parameter.
-mp --metadatapassword <password>	Encrypt the sensitive values using the given password (e.g. passwords of data sources). You can indicate the password encrypted to avoid entering it in plain text. To do this, use the script `encrypt_password` to obtain the encrypted password and prefix the value with `encrypted`. E.g. `-mp "encrypted:Gr16MjvuXhRzPtPH/yTXHw=="`
-r --repository <path to repository>	Path to the directory where the Repository will be created or where it already exists. This option is not compatible with the option `--file` (`-f`)
-revision	If VCS configured, generate the VQL from the difference of 2 commits or 2 tags
-e --element	The relative path of a single element in a repository, relative to its future position in the repository. E.g. `/databases/admin/view s/incidents.vql`
-re --repository-element	The identifier path of an element. The syntax of this identifier is: `database:type[:subtype]:[folderPath/]name` E.g. admin:view:/incidents The values of `type` are `datasource`, `view`, `webservice`, `storedprocedure`, `folder`, `database`. The value of `subtype` can be `custom`, `df`, `essbase`, `jdbc`, `json`, `ldap`, `mongodb`, `odbc`, `olap`, `salesforce`, `sapbwbapi`, `saperp`, `ws`, `xml`.
-su --singleuser	Only valid when exporting to a file (`--file`) If present, the file generated will begin with the statement `ENTER SINGLE USER MODE` and end with `EXIT SINGLE USER MODE`, so that Virtual DataPort switches to single user mode while importing this file. This option is ignored when exporting to a Repository. Note: you are strongly advised to import metadata into a Virtual DataPort server in single user mode.
-P --property	Set of settings that control the export process. You can specify one or more properties with this syntax: `<property name> = {yes \| no}` Properties than can be passed to the export script (–property parameter) lists the available properties.
-v --view <views>	List of comma-separated view names to include in the export. Only valid when exporting to a file (`--file`). The `<database_name>` must be present in the `--server` option E.g. `-v view1,"View2"` If `<database_name>` is not included in the `--server` option, the view names must be prefixed with the database name E.g. `-v database1:view1,database2:"View2"`
`-fc` –from-commit	Only applicable for -revision Specifies the starting commit hash to begin searching for differences (mandatory)
`-tc` –to-commit	Only applicable for -revision Specifies the ending commit hash for the difference comparison (optional, default: HEAD)

The properties that control the export process (-P, --property) are the following:

Properties than can be passed to the export script (-\-property parameter)¶
Possible Arguments for --property	Description
cluster	Default value: `no`. If `yes`, the following elements will not be exported: JMS listeners: only one of the Servers must connect to a JMS queue or topic. The configuration of the “Cache maintenance task” of each database. However, even with this option, it does export the global configuration of the “Cache maintenance task”. Server connectivity settings: Server port number ODBC port number Monitoring port number Auxiliary monitoring port number Shutdown port number Web container HTTP port number Web container shutdown port number Auxiliary web container port number JVM settings of the Server and the embedded Web container Note: this parameter is deprecated. The section Features Deprecated in Denodo Platform lists all the features that are deprecated. When working in an environment with a cluster of Virtual DataPort servers. The main Server must have different settings from the rest. E.g., the “Cache maintenance task” only can be active in one of the Servers. In this scenario, we recommend adding the parameter `-P cluster=yes` when exporting the metadata from the main Server to import it into the other Server. Adding the parameter `-P` `cluster=yes` is equivalent to adding the following properties: -P includeJMSListeners=no -P includeDatabaseCacheMaintenanceProperties=no -P excludeServerConfigurationProperties= com.denodo.vdb.vdbinterface.server.VDBManagerImpl.registryURL, com.denodo.vdb.vdbinterface.server.VDBManagerImpl.registryPort, com.denodo.vdb.vdbinterface.server.VDBManagerImpl.shutdownPort, com.denodo.vdb.vdbinterface.server.VDBManagerImpl.factoryPort, com.denodo.vdb.vdbinterface.server.VDBManagerImpl.odbcPort, com.denodo.vdb.cache.cacheMaintenance, java.env.DENODO_OPTS_START, java.env.DENODO_OPTS_STOP -P excludeWebContainerConfigurationProperties=com.denodo.tomcat.http.port, com.denodo.tomcat.shutdown.port, com.denodo.tomcat.jmx.rmi.port, com.denodo.tomcat.jmx.port, java.env.DENODO_OPTS_START, java.env.DENODO_OPTS_STOP
exclude_jdbc_wrapper_properties	When you add `-P includeProperties=yes`, add `-P exclude_jdbc_wrapper_properties=yes` if you want the parameters `CATALOGNAME` and `SCHEMANAME` of the `CREATE WRAPPER JDBC` statements to contain the actual value instead of a property. Default value: `no`.
excludeServerConfigurationProperties	When exporting the entire Virtual DataPort server, the output includes all the settings of the Server: cache module, concurrent requests, default i18n, etc. This property is a comma-separated list of these properties whose value will not be exported. Make sure you do not put the space character between the comma and the name of each property. Default value: empty list. Valid values: com.denodo.vdb.vdbinterface.server.VDBManagerImpl.registryURL com.denodo.vdb.vdbinterface.server.VDBManagerImpl.registryPort com.denodo.vdb.vdbinterface.server.VDBManagerImpl.shutdownPort com.denodo.vdb.vdbinterface.server.VDBManagerImpl.factoryPort com.denodo.vdb.vdbinterface.server.VDBManagerImpl.odbcPort com.denodo.vdb.cache.cacheMaintenance java.env.DENODO_OPTS_START java.env.DENODO_OPTS_STOP
excludeWebContainerConfigurationProperties	When exporting the entire Virtual DataPort server, the output includes all the settings of the embedded Web container. This property is a comma-separated list of these properties, whose value will not be exported. Default value: empty list. Valid values: `com.denodo.tomcat.http.port` `com.denodo.tomcat.shutdown.port` `com.denodo.tomcat.jmx.rmi.port` `com.denodo.tomcat.jmx.port` `java.env.DENODO_OPTS_START` `java.env.DENODO_OPTS_STOP`
includeEnvSpecificElements	If `yes`, the output does not include the VQL to create the elements that are independent of the environment and only includes the VQL to create the elements that depend on the environment such as data sources, users and their privileges, JMS listeners, Server settings, etc. The section Exporting Environment-Dependent and Independent Elements to Different Files lists which elements are considered dependent on the environment. Note: this parameter is deprecated. Instead, use `includeProperties`. The section Features Deprecated in Denodo Platform lists all the features that are deprecated.
includeNonEnvSpecificElements	If `yes`, the output does not include the VQL to create the elements that depend on the environment and only includes the VQL to create the elements that are independent of the environment such as views, Web services, etc. The section Exporting Environment-Dependent and Independent Elements to Different Files lists which elements are considered independent from the environment. Note: this parameter is deprecated. Instead, use `includeProperties`. The section Features Deprecated in Denodo Platform lists all the features that are deprecated.
replaceExistingElements	If `yes`, the CREATE statements will have the REPLACE clause. E.g.: CREATE OR REPLACE VIEW p_customer AS SELECT …
dropElements	If `yes`, the `CREATE` statement of each element are preceded by a `DROP` statement. E.g.: `DROP VIEW IF EXISTS p_customer CASCADE; CREATE VIEW p_customer AS SELECT ...`
includeContents	If `yes`, when exporting a folder, the output will have the VQL statements to create the folder and the elements contained in this folder, including other folders. If no, the output will only contain the VQL statement to create the folder. Default value: `no`.
includeCreateDatabase	Only valid when exporting an entire database. If `yes`, the output includes the following statements that will recreate the exported database: DROP DATABASE IF EXISTS <exported db name>; CREATE DATABASE <exported db name>; If you export all the metadata of a Server, the output already includes the statements to create the databases.
includeDatabaseCacheMaintenanceProperties	When exporting the metadata of the Server or a single database, the output includes the settings of the “Cache maintenance task”. If `no`, the output will not include the settings of the “Cache maintenance task” of any database. However, if you export the metadata of the entire Server, the output will include the global settings of this task. Default value: `yes`.
includeDependencies	If `yes`, the output includes the VQL statements to create the elements that the element you are exporting depends on. For example, if you export a base view and set this option to `yes`, the script will also export the metadata of the data source. Only useful when you are not exporting the metadata of an entire database or Server.
includeDeployments	If `yes` the output will include `DEPLOY` statements for the web services that are deployed. Default value: `no`.
includeJars	If `yes`, the output includes the Jars that were imported into the Server with the File > Jar Management wizard of the Administration Tool. If you are not exporting the metadata of the entire Server, the output will only include the Jars used by the elements you are exporting. Default value: `no`.
includeJMSListeners	If `yes`, the output will include the statements to create the JMS listeners. Default value: `yes`.
includeProperties	Generates two files: one that contains the metadata and another one that contains the values of the parameters whose value depend on the environment where the Server is running. This option cannot be used when exporting to a repository (`--repository`)
includeResources	If `yes`, the output includes all the files that were imported into the Server with the File > Extension Management > Libraries wizard of the Administration Tool. Default value: `no`.
includeStatistics	By default, the statistics of views are only exported when you export the entire server, not when you export a database nor when you export a view. To include the statistics of the views in the result, add the option `-P includeStatistics=yes`. Default value: `no`.
includeUserPrivileges	If yes, the output will include the statements to replicate the privileges of the exported elements. That is, it will include the statements to do the following: Create the users and the roles that are owners or have privileges assigned over the exported elements. Assign the privileges to these users/roles over the exported views. Default value: `no`.
includeVCSConfiguration	When you export a database with the option `-P includeCreateDatabase=yes`, the output contains the statements CREATE DATABASE and ALTER DATABASE so the database is created with the same configuration, including the VCS settings of the database. If you do not want to export the VCS settings, add `-P includeVCSConfiguration=no`. Default value: `yes`.
includeTagDependencies	If yes, the output will include the tags from elements using them when an export from certain databases is executed. Default value: `no`.

This script returns one of these exit codes:

0: no errors. The metadata was exported successfully.

126: one of the elements could not be exported.

1: for other errors. E.g. the script could not open a connection to the Virtual DataPort Server.

Examples

Example 1:

export --server "//localhost:9999/database1"
       --login admin
       --password encrypted:iGTAJvv6CjEd1EvBVZyO4SSkgYCE7Z2C5PMZBLRUYk2YgeibnNZmk4HyTDcecoZuounNgjKxbsh1GO5bXjpRlRIkHOUaaVMj4INs7G3bLa3AE/1MGgSfiv3V4oC/1RVf
       --singleuser
       --zip
       --file denodo_virtual_dataport_metadata.zip
       --property includejars=yes
       --property includeProperties=yes

In this example, we export the metadata of the database1 of the Server running in localhost, port 9999, using the credentials admin/admin. The encrypted password has been obtained with the script encrypt_password.

The resulting VQL file and the properties file are stored and compressed in the file denodo_virtual_dataport_metadata.zip.

Example 2:

export --server "//localhost:9999"
       --login admin
       --password admin
       --singleuser
       --repository "C:/repository"
       --property includejars=yes

In this example, we export to a Repository the metadata of all the databases and the settings of the Server. The Repository will be created in the directory C:\repository

Example 3:

export --server "//localhost:9999"
       --login admin
       --password encrypted:iGTAJvv6CjEd1EvBVZyO4SSkgYCE7Z2C5PMZBLRUYk2YgeibnNZmk4HyTDcecoZuounNgjKxbsh1GO5bXjpRlRIkHOUaaVMj4INs7G3bLa3AE/1MGgSfiv3V4oC/1RVf
       --singleuser
       --repository "C:/repository"
       --repository-element
         "vdp_testing:datasource:jdbc:/Data sources/internet_ds"

In this example, we export to a Repository the metadata of the data source JDBC named internet_ds of the database vdp_testing.

Example 4:

export --revision -l admin -p admin -h localhost:9999/admin -f
       revision.output -fc ab12cd34 -tc HEAD -P includePrivileges=yes -P includeServerConfiguration=yes

In this example, we export the VQL revision from commit ab12cd34 to HEAD to file ‘revision.output’ using the specified connection parameters.

USER MANUALS

Export Script¶