Archiving the Decision Center database

Your Decision Center database can contain multiple versions of your rule artifacts. You might want to clean up your database to keep only the versions that you need and archive versions you do not use anymore, which reduces the database size and improves performance.

Active versions are the versions that you currently use and you want to keep (for example, your current version and the more recent versions within the last year).

Inactive versions are the versions that you do not use anymore, and you want to archive (for example, versions that are too old).

To clean up your database, you must copy the active versions to a new schema. You make this copy by using an SQL script that is generated by the gen-archive-repository-script Ant task. To execute this script, you can use a dedicated database connection tool or the execute-schema Ant task.

This new schema becomes the one you use in your daily work, and the old schema is archived. This old schema contains all the data (active and inactive versions) until the moment you archive it. You no longer update it, but you can still use it for queries.

You can select all versions to be copied from a certain date, with the archiveDate parameter. With this parameter, you can also decide to remove the active versions from your old schema so that they remain only in the new schema (see dropOldData). If the archiveDate parameter is not set, all the latest versions of elements in your branches, releases, activities, snapshots, and deployments snapshots are copied into the new schema.

Diagram shows the state of a project before archiving. — Figure 1. Example of a decision service before archiving

Diagram shows the elements that are copied to the new schema. — Figure 2. Example of the decision service after archiving with the parameter `archiveDate`

The Ant tasks that handle the archiving process are:

gen-archive-repository-role
You use this task to grant required privileges to copy the old database content into the new schema. This task uses the same parameters as the task that builds the role for the migration process (gen-migrationXX-role, see Ant tasks for database migration).
gen-archive-repository-script
You specify the following parameters for this task:

username

The administrator's user name.

password

The administrator's password.

server.url

The URL to access Decision Center.

datasourceName

The new data source name.

oldDatabaseSchemaName

The name of the database schema used by the previous data source, which usually matches the user name specified in the data source configuration.

archiveDate

(Optional) The date that specifies which versions to copy, with the format yyyy-mm-dd. All elements created or updated after the date that you set are copied from the old data source to the new one.
If you do not specify archiveDate, only the latest versions of elements visible in your branches, including ungoverned branches, releases, activities, snapshots, and deployment snapshots are copied into the new schema.

dropOldData

(Optional) Use this parameter if you want to delete the active versions from the old database schema, so that you only have inactive versions in the archive.
To do this, the database user for the new data source needs write permission for the old schema. If you remove active versions from the old schema, you can no longer update the old database, but you can access the inactive versions in read-only mode.

Possible values for the dropOldData parameter are true or false, and the default value is false.
Note: You can use the dropOldData feature only with the archiveDate parameter.

outputFile

(Optional) The name of the file where the SQL script is generated.

Tip: In Oracle, you must close and reopen the database connections to get updated privileges.

Example

You are administrator for the Decision Center database. You want to archive versions of the rule artifacts in this database that are older than December 31, 2016.

You use the gen-archive-repository-script with the following parameters:

ant gen-archive-repository-script -DoldDatabaseSchemaName=<odm> -DarchiveDate=2016-12-31

For example, here is the status of the elements in the Loan Validation Services decision service after the active versions are copied to your new schema:

The Main branch of your project is copied, even though it was created in 2014 and last updated in 2015. This is because the main branch is always copied to your new database schema, regardless of the archiveDate parameter. However, this is not the case for sub-branches or snapshots in the project.
Sub-branch 1, which was created in 2014 and last updated in 2014, is not copied.
Sub-branch 2, which was created in 2015 and last updated in 2017 with a new rule, is copied.
In Spring Release, the change activity Adjust Scoring, which does not contain any update after October 2016, is not copied. The status of the activity is not considered (whether it is Complete, Cancelled...), only the activity date is taken into account.
With the archiveDate parameter, versions in a recycle bin that are older than December 31, 2016 are not copied.
Note: If the archivedate parameter is not set, the recycle bin of a branch in your new schema is empty.
The change activity Adjust Insurance was last updated in 2017, so it is copied. It contains several rule artifacts that were not updated since 2015, but they are also copied. If the parent branch is copied, all the latest versions of elements in this branch are copied as well, even if they are older than the archive date.