Skip to main content
This article moved to workflowserver.io permanently.

Developer Mode and Export of Configurations

General information​

Developer Mode is a mode for synchronizing schemes, forms, and metadata with the file system. It can be used during development, for example, you can put the configuration in Git for collaborative programming. The Workflow Server also supports export and import of configurations.

Fig1

  1. Configuration export to archive.
  2. Configuration import from archive.
  3. Switch of Developer Mode.

Developer Mode​

caution

Attention. Using this mode is strongly not recommended if you have more than one instance of Workflow Server connected to the same database.

There are two ways to enable the Developer mode:

  • using the switch on the dashboard.
  • changing the configuration file config.json. The path to the folder with the saved metadata is also configured in the config.
{
  "DeveloperMode": true,
  "MetadataFolder": "../../../../metadata"
}

Developer mode is enabled only locally. That information whether it is enabled is stored in the configuration file only.

After the mode is enabled in the dashboard, the following goes on:

  • An attempt is made to download the current configuration to the file system, to the folder specified by the MetadataFolder setting.
  • An attempt is be made to modify the configuration file.
  • If one of the previous steps ends with an error, the mode will not be activated.

Next:

  • Changes to the schemes, forms and metadata will duplicate with the changes to the file system.
  • When starting the server, the current configuration will be backed up to the folder with the same name in the root directory.
  • The database will be updated with the metadata from the file system.

The files are organized is the same way as in the archive for import and export. You can pack the contents of the metadata folder into a zip file to import the configuration to another developer, but it is recommended to use the Import configuration button on the dashboard for doing this.

Structure of files describing the configuration​

├── Forms
│   ├── formName1.json
│   ├── formName1-code.html
│   ├── ...
│   ├── formNameN.json
│   ├── formNameN-code.html
├── Workflow
│   ├── codeScheme1.xml
│   ├── ...
│   ├── codeSchemeN.xml
│   ├── workflow-settings.json
├── metadata.json
├── users.json
└── version.txt (created only when exporting the configuration)

  • Workflow - each workflow scheme is stored in a separate file named {scheme code}.xml, additional settings for all schemes are stored in the file workflow-settings.json.

  • Forms - each form is stored in the following two files:

    • the form parameters - in {form name}.json.
    • the form markup - in {form name}-code.html.

  • metadata.json - contains the settings data

    • Plugins
    • Cors
    • Logger
    • Code Actions
    • Security (without type, login and password)
    • MultiServer
    • SingleServer
    • Callback API
    • LDAP
    • Identity Server
    • Business Flow

  • users.json - contains the Users' data.

  • version.txt - created only when exporting the configuration; contains the exact time of the archive export, the version of the Workflow Server.

Configuration Export and Import​

If necessary, you can export the settings to a zip archive and import them at another stand. When exporting, you can specify whether to export the hashes of user passwords. After importing this configuration, if the hashes have not been exported, you should set the passwords for users manually. When importing, the current configuration is deleted and replaced with the imported one.