This chapter describes the best practices when using the configuration space functionality.
Always Take a Backup Copy
Before you execute a spacecopy to your active space, it is recommended that you always take a backup copy of the active space. This means that if an error occurs after you have copied your modified configurations to the active space, you have a copy of the previous version of the active space to which you can revert. See 2.2 Activating a Space.
Use Offline Spaces for Backup Copies
When you create a space for a backup copy, it is recommended that you use spacecreate with the offline flag. This is particularly important if you plan to have a large number of copies, since these may otherwise consume a significant amount of system resources.
Drain and Stop Workflows before a spacecopy
Before coping a passive space to the active space, you must drain and stop all the workflows running in the active space. However this does not apply to workflows running on ECSA - they must be left to run without interruption.
Naming Spaces
To ensure that there is no confusion in managing your configuration spaces, passive spaces must be clearly named to reflect their purpose.
For example, before you copy your modified set of configurations from a passive space to the active space, you should create a backup space to which you can copy the content of the active space. You could name the passive space created for this purpose 'backup'.
Passive spaces can be named to reflect some logical meaning in your release process, similar to how you might refer to different environments, e.g. 'dev' 'preprod' , 'qa' or 'production'.
Note!
Lower case must always be used when naming spaces.
Ensure Passive Space Based on Prior Version of Active Space
Before you copy a passive space to the active space, always ensure that the passive space is based on the latest version of the active space. This ensures that formats from the active space are not lost. You can track actions taken in the active space by setting an event notification or using the System Log. For further information, see the section below, Tracking Configuration Space Actions.
Note!
As spacecopy removes all existing configurations prior to the copy, you must be careful to not remove ultra formats used by runtime data. For example, removing a format used by ECS or aggregation data will prevent data extraction.
Tracking Configuration Space Actions
In order to track the actions taken with spaces, you can set event notifications so that whenever a space is created, copied or removed you can have this event logged, e.g. in a database or in the System Log.
For example, if you want a notification to be generated in a log file whenever a spacecopy is executed and the active space is the destination space.
For more details on the Space Action Event, refer to 4.3.28 Space Action Event, in the Desktop User's Guide.
By default, logs some preset actions in the System Log:
When a user logs in or out of a space, the message in the System Log includes the user and the space in which the user is/was logged in.
When a user performs a
spacecopy,spacecreateorspaceremove, the message in the System Log includes details of the space operation performed.When a user makes any change to a configuration, the System Log has an entry of the operation and the user details.
spacecopy Does Not Cover Same Object Types as systemexport
The spacecopy command does not cover the same object types as the systemexport command. spacecopy only works with configurations, and not global objects. For example, spacecopy does not include system data such as users, pico hosts, and other system data, which you can include with systemexport.