Export/Import of Configuration

The export action of the individual XDM configuration objects can create YAML and ZIP files for the import.

YAML

Generates a YAML file containing all settings of the objects to be exported in a single file.

ZIP

Generates a ZIP folder, with several individual YAML-files. Each YAML-file is stored in a directory according to its type. For example, when exporting a native table backup task template named 'A backup template', a YAML-file 'A backup template.yaml' is created inside the directory /TaskTemplate/native-table-backup-task-template/ of the ZIP-file. This kind of export is suitable for usage in git-repositories together with XDM’s configuration as code feature.

Using file reference

There is the possibility to store properties in separate files. For example, task stage hook code can be written in a separate file. This file can then be referenced in the yaml file of the task stage hook and the import automatically inserts the code from the referenced file.

The yaml files can use the extracted data by writing #{file:FILE_NAME}. During the import of the .zip file, all occurrences of a reference will be replaced by the specific value of the reference. The files do not necessarily have to be on the same level as the yaml file in which it is referenced. It is possible to use relative path specifications.

Formatting behavior in YAML export for code with tabs

A longer text like modification or stage hook code needs paragraphs and indentations for better reading. When an object which contains such code is part of an export, sometimes the code is formatted as well as in the code field in the user interface. In other cases paragraphs and indentations are displayed as \n or \t. This looks more confusing, especially when working with configuration as code. To understand which usages of tab or other space cause the nested structure, here are some examples for explanation. This applies to a readable export, because the text must be converted to a valid YAML format.

Code and export examples

The following example is formatted as desired.

    for (var i=0; i<10; i++) {
      print('This is a export test #');
      print(i);
    }

The export output would look like this:

...
code: |-
  for (var i=0; i<10; i++) {
      print('This is a export test #');
      print(i);
    }
...

When adding a tab at the end of the first line, the output would change to

...
code: "for (var i=0; i<10; i++) {    \n    print('This is a export test #');\n\
  \    print(i);\n}"
...

At the end of the entire code a tab has no bad effect, because the text is trimmed. So a tab is only not allowed when some other text follows in the next line. Text after a tab like a comment is no problem.

  for (var i=0; i<10; i++) {    // comment after tab
      print('This is a export test #');
      print(i);
  }

Another example for bad formatted exports is this:

  for (var i=0; i<10; i++) {
      print('This is a export test #');

      print(i);
  }

A paragraph is not allowed after an indented line if it is followed by another line. The export would look like this:

...
code: "for (var i=0; i<10; i++) {\n    print('This is a export test #');\n   \
    \ \n    print(i);\n}"
...

Paragraphs are only allowed at the first level:

  for (var i=0; i<10; i++) {
  print('This is a export test #');

  print(i);
  }

  if(2=3) {
      print('That is wrong');
  }

Here a paragraph follows the first print command which has no tab or white space in front and a second paragraph separates the for loop from the if condition.

Import and Export Between Different XDM Versions

The export and import of XDM configurations between different XDM instances can be used to synchronize two or more XDM installations. Each export file includes a version indicator at the top of the file. This indicator specifies the version of the exported YAML file.

The import process performs a version check of the imported file and compares it with the version of the XDM instance:

If the version of the imported file is higher than the version of the XDM instance, the import process might succeed, but success is not guaranteed. If new properties or new object types are part of the source YAML file the import might fail, because the target XDM instance does not support these new properties or object types.
If the version of the imported file is lower than the version of the XDM instance, the import process will automatically migrate the configuration to the current version of the running XDM instance.

Export with Different License Keys

When objects are exported from an XDM installation using a temporary license key, such as during a trial of enhanced features, and are imported into an XDM installation using a standard license key, the import might fail. This is because the target XDM installation may not support the enhanced features included in the exported objects.

Password Encryption in Credential Objects

XDM Credential objects contain a username and a password. To prevent the password from being stored in plain text in the YAML file, it is encrypted. Encryption is performed using a secret key, which is used to both encrypt and decrypt the password.

The export and import process utilizes a dedicated encryption key shared by all XDM instances. This ensures that a password exported from one XDM instance can be successfully imported into another XDM instance.