The purpose of Configuration Spaces is to minimize the downtime during the upgrade or modification of configurations in . It may also be used to mitigate problems that arise from configuration changes while the system is operated. This is achieved using passive spaces and the active space.

In a passive space, you can make changes to a set of configurations while the same configurations continue to run in production in the active space. You can then copy the modified set of configurations into the active space to replace the existing configurations with minimal downtime. This is the preferred way to make changes to the content of a space which is in production. For instance, when you save an Ultra configuration, in the active space, the affected workflow configurations will temporarily exist in an invalid state. Attempts to start workflows in this state will cause them to abort. This problem does not occur if you save a configuration in a passive space.

Concept

A configuration space is a complete self-contained set of configurations, without dependencies to other spaces.

When a new space is created, it only contains mandatory system tasks.

A configuration space contains both the ‘latest’ and ‘previous’ versions of all the configurations from the space from which it was copied.

Configuration spaces only affect configurations (and generated code). They do not affect other system objects such as ECS, users, defined picos, or the contents of various disk storages (aggregation, inter-workflow etc), or installed mzp files.

It is not possible to import runtime data to, or export runtime data from, a passive space. This can only be performed in the active space. In run-time, workflows, workflow groups, event notifiers and alarm detectors can only be executed in the active space.

You can optionally create offline spaces that are not accessible for viewing or changing configurations, but that are useful for backup purposes. These spaces do not have running service instances and therefore do not consume any system resources.

Workflow executions can only be done in the active space. When you are working in a passive space in the Desktop, the following features are disabled:

In addition, all mzsh commands that affect workflow executions are unavailable in passive spaces.

Tasks that do not affect runtime state or data, e.g. configuration import/export, or creating configurations, can be used in passive spaces.

In the Desktop

It is important that the user knows which space they are working in. If there are several spaces, there is a dropdown list in the Desktop Launcher from which you can select the space that you want to work in when you login to the Desktop.

List of available spaces

The space that you are working in is also indicated in the Desktop title bar.

The titlebar displays the current space. [Desktop @staging] in this instance

In addition, to tell the difference between different spaces, you can have a different background color for each space.

To change the Desktop application background color of a space, you set the Desktop property mz.gui.color.space.<space name> for the relevant Desktop instance.

For example, if you want to set the active space to blue and a passive space that you have named 'backup' to yellow, set the following in the Instance Settings in the Desktop Launcher:

The value can be any of the following colors: blue, green, yellow, orange, red, darkblue, darkgreen, magenta or darkred.

For information about how to set these properties for all Desktops that connect to the Platform, see 2.6 System Properties in the System Administrator's Guide.