Skip to content

Explorer

Change Log

Whenever an entity (e.g. a data series, a feature class a models setup, etc.) are added or updated the system will make an entry in the change log with information about the user, the machine, the time and the activity, thus making timeline of changes to an entity.

This is done by default and for all entities. However, because of this the information is quite general.

Tools modifying entities apply more information about the operation, describing the actions taken by each tool in a sequence.

With scripting it is possible to create and modify entities and unless programed otherwise only the default logging will be supplied. However, the Change Log module has an API (see the API documentation) which allows custom log-records to be added instead of the default logs, see below scripting example.

Display of Change Log

Whenever an entity is selected in the UI the metadata manager is able to display the set of changes to this entity, in a separate tab in the property grid.

The above shows an example of the change log of a time series which was created by running the resample tool on a time series called “ANGASMAYO-60CXT33EN2QB01 - 1 - ANGASMAYO (Caudal) (Extract)” and the above tool settings. The first log record shows the input time series detail, the second the tool settings.

By default the application will show the last 100 logs (this is a configurable setting in the Dhi.solutions.Shell.exe.Config file).

View all logs

A separate query tool is available to access the entire change log for an entity (or set of entities).

Selecting the above new time series the query result can look like this:

Make a script with Change Log

The below sample script will rename a time series and add custom change log record instead of the default update record script.

After running the script the change log of the data series will look like:

Metadata

Where change log is automatically generated dynamic information, metadata is user defined, user edited and more static information associated with entities.

Defining metadata properties

Defining the metadata properties is a task which involves users as well as system administrator. Each installation should agree on a common set of meta data properties.

At a technical level the metadata properties must be expressed as an XML schema. An example of a simple schema is xml file.

It defines one property, identification, which is optional (minoccurs=0) and consists of two (also optional) values, originator and publicationdate. The first is a string, while the latter is a date-time.

Data types of properties in such a schema should be kept to standard types as defined by http://www.w3.org/2001/XMLSchema.

A more elaborate sample is this – but still constructed following the line from above : xml file.

Note in addition to string and datetime, decimal types are also used.

Configuring metadata properties

Bringing the defined the metadata properties into the Workbench is carried out via a ”Metadata Schema Import” tool available in the Other Tools section of the Tools Explorer.

The tool takes two settings:

  • The path and name of the xsd-file holding the schema to import

  • The Entity Type Name for which the schema shall be applied. This is selected from a drop-down listing the supported types

Execution of the tool will validate the schema and eventually replace an existing schema for the entity type.

Displaying metadata properties

When an entity is selected in the UI and a schema is defined for the entity type and additional tab-page in the Properties dialog will appear showing the meta data.

Editing metadata properties

The same dialog used for displaying metadata can be used to modify the meta data. Updates are committed to the database immediately.

Translating metadata keys

It is possible to translate the metadata keys (the properties defined in the XSD file) to a readable format or to another language.

Currently this requires manual table updated in the database using the appropriate database management tool.

The tables to update are:

  • Language – which holds the language code and name (e.g. de-DE for German or en-US for US English)

    Inserting can be accomplished by such a SQL statement:

    INSERT INTO workspace1."language"(id, code, "name") VALUES ('7ea4af4b-d04c-4cd7-8b77-e9709b274d1c', 'en-US', 'English (United States)');

  • Translated key – which holds the reference to the language, the full XSD key and the translation.
    This can insert a translation of Identification and its description:

    INSERT INTO workspace1.translated_key(id, language_id, "key", "value") VALUES ('06D8C6FC-4E9A-4877-A570-2A00E419F5B6', '7ea4af4b-d04c-4cd7-8b77-e9709b274d1c', '/metadata/identification', 'Identification');

    INSERT INTO workspace1.translated_key(id, language_id, "key", "value") VALUES ('60075350-2542-49FB-8989-044F534F0AFA', '7ea4af4b-d04c-4cd7-8b77-e9709b274d1c', '/metadata/identification_description', 'Identification Category');