Backing up an entire repository is useful so that it can be restored to a point in time or downloaded for transfer to another console. To do this, select the repository you wish to back up and click the “Backup” button. A zip file containing all files in the repository will be created.

To restore a backup, click on the file in the console tree and click restore.

Every repository has the ability to import rules and data files from a pre-existing repository to be used during rule writing. This allows large data files to be stored in a single repository and provides a means for packaging rule sets up as individual rules.

Managing these features can only be done after a repository has been created.

To add a new repository to include from, simply click on the “+” button and specify the source repository.

At times you may wish to copy not just individual configurations, but also all of the dependent rule sets it needs to function. This would, for example, apply if you were copying a configuration from staging into production.

When you select a different target repository in the configuration copy, a new set of options appear as shown:

These options allow you to copy the configuration in isolation, or to copy the configuration plus the dependent rule sets, and to clear the target repository of all its configurations and rule sets to perform a clean copy with both the configuration and all dependent rule sets.

You can easily move configurations, rule sets and data files between repositories (provided that you have the relevant access to them).

Use the copy function for the respective file and specify a new target repository.

Once a backup is created, you can download it and upload it to a different console. This can help with moving complex best practice rule sets with lots of dependent data files from one system to another, and also allows for easy sharing of rule sets between rule set creators.

Repositories are used to separate and securely manage configurations, rule sets and data (data files, content or test data) for a given server. They can also be used in combination with user roles to separate responsibilities for rule writing, testing and deployment between different users.

By default, repositories are not enabled, and configurations, rule sets and data are stored directly under the root of the relevant section in the administration tree.

To create a new repository, simply click the Repositories link in the administration tree. The following will be presented:

Enter a name for the repository in the “Details” section (such as “Test”) and click on Create.

Note that you can also filter repositories from this location. Adding a filter allows you to limit the number of repositories shown in the administration tree. This speeds up the console and also makes development within a single repository much easier.

A new repository will now exist under configurations, rule sets and data, however you will not be able to see these folders until they contain some data.

To create a new configuration, rule set or data file in a repository, select that repository on the creation page as shown below:

In this example, once you have uploaded a file to the Console Demo repository, it becomes visible in the administration tree as shown here:

If you are separating your user base into different skill levels, you can set the allowed rule groups to be used by the rule writer using the repository. This allows you to create a simpler user experience with more high-level rules for less technical rule writers.

Simply “untick” the All checkbox and you will be able to select specific rule groups that are appropriate for the given repository.

The groups available to you will depend on the settings against your role. Please note that even though an administrator may set allowed rule groups here, the user role settings take priority. So, the repository level settings should only be used to define subsets.

In a similar way to the copying of configurations shown above, you can also copy dependent rule sets. This is useful, for example, when copying a rule set between a test and production server, or when copying a rule set fragment.