Update the Repository

When you have migrated your configuration to the new IDM installation, you need to handle the data that is stored in your repository. There are two options to update a repository:

Upgrade your existing IDM 6.5 repository.
Create a new IDM 7 repository, then migrate your data to the new repository.

When you have upgraded the repository, or created a new repository, start the IDM server and test that all your scripts are working as expected, before migrating your data.

Upgrade an Existing Repository

Upgrading an existing repository means that you do not need to migrate data. However, you need to run a series of scripts that modify the repository, to use the new features in IDM 7.

Note

Upgrading an existing repository is not supported if you use a DS repository. If you're upgrading from a previous IDM release with a DS repository, you must create a new repository, then migrate your data to the new repository.

Prepare an existing repository for IDM 7 as follows:

Clear all configobjects related tables. For example, in MySQL run:

DELETE FROM openidm.configobjects;
DELETE FROM openidm.configobjectproperties;

Increase the column length of the objectid column in the locks table.
Queued synchronization creates locks when it acquires the mappings to process on an IDM node. The length of the objectid column in the locks table in versions prior to IDM 7 is 38 characters. Because the lock _id is set to the mapping name, it can easily exceed 38 characters. Increase the length of this column to 255 characters.
Delete existing openidm-authorized role relationships.
Previous IDM releases created a relationship to the openidm-authorized for every new managed user. IDM 7 handles the default authorization differently, setting a defaultUserRoles property for users on authentication. For more information, see XREF.
In existing deployments, you can delete these existing relationships from the repository as follows:
```
DELETE FROM openidm.relationships
WHERE firstResourceCollection = 'internal/role' AND firstResourceId = 'openidm-authorized'
OR secondResourceCollection = 'internal/role' AND secondResourceId = 'openidm-authorized';
    
```

From your IDM 7 installation, run the schema update scripts for your database type.

These scripts are located in the openidm/db/database-type/scripts/updates directory:

00-relationshipresources.sql

This script adds a new relationshipresources table, and loads the table with a distinct list of the resources that have existing relationships linked between them. Loading the data might take some time, if the relationship table is large. You will also need to update your repo.jdbc.json file, adding the new mapping to your explicitMappings configuration:

"relationshipresources": {
  "table": "relationshipresources",
  "objectToColumn": {
    "_id": {
      "column": "id",
      "isNotNull": true
    },
    "originResourceCollection": {
      "column": "originresourcecollection",
      "isNotNull": true
    },
    "originProperty": {
      "column": "originproperty",
      "isNotNull": true
    },
    "refResourceCollection": {
      "column": "refresourcecollection",
      "isNotNull": true
    },
    "originFirst": {
      "column": "originfirst",
      "isNotNull": true,
      "type": "BOOLEAN"
    },
    "reverseProperty": "reverseproperty"
  }
}

01-syncqueue.sql

Removes the remainingRetries property from the queued synchronization object. IDM 7 lets you configure an infinite number of queued synchronization retries.

Remove the remainingRetries code block from conf/repo.jdbc.json file. Example code block to delete:

"remainingRetries": {
  "column": "remainingRetries",
  "type": "NUMBER"
}

02-importobjects.sql

Adds support for bulk import.

03-reconassoc.sql

Adds recon association tables to your repository.

You will also need to update your repo.jdbc.json to include the new recon/assoc mappings to your explicitMapping configuration:

"recon/assoc" : {
    "table" : "reconassoc",
    "objectToColumn" : {
        "_id" : "objectid",
        "_rev" : "rev",
        "mapping" : "mapping",
        "sourceResourceCollection" : "sourceResourceCollection",
        "targetResourceCollection" : "targetResourceCollection",
        "isAnalysis" : "isAnalysis",
        "finishTime" : "finishTime"
    }
},
"recon/assoc/entry" : {
    "table" : "reconassocentry",
    "objectToColumn" : {
        "_id" : "objectid",
        "_rev" : "rev",
        "reconId" : "reconId",
        "situation" : "situation",
        "action" : "action",
        "phase" : "phase",
        "linkQualifier" : "linkQualifier",
        "sourceObjectId" : "sourceObjectId",
        "targetObjectId" : "targetObjectId",
        "status" : "status",
        "exception" : "exception",
        "message" : "message",
        "messageDetail" : {"column" : "messagedetail", "type" : "JSON_MAP"},
        "ambiguousTargetObjectIds" : "ambiguousTargetObjectIds"
    }
},
"recon/assoc/entry/view" : {
    "table" : "reconassocentryview",
    "objectToColumn" : {
        "_id" : "objectid",
        "_rev" : "rev",
        "mapping" : "mapping",
        "reconId" : "reconId",
        "situation" : "situation",
        "action" : "action",
        "linkQualifier" : "linkQualifier",
        "sourceObjectId" : "sourceObjectId",
        "targetObjectId" : "targetObjectId",
        "sourceResourceCollection" : "sourceResourceCollection",
        "targetResourceCollection" : "targetResourceCollection",
        "status" : "status",
        "exception" : "exception",
        "message" : "message",
        "messageDetail" : "messageDetail",
        "ambiguousTargetObjectIds" : "ambiguousTargetObjectIds"
    }
}

If you use a Microsoft SQL Server repository, run the following additional scripts:

04-alter_ntext_openidm.sql
05-alter_ntext_audit.sql

These convert uses of ntext to nvarchar(max), because Microsoft is deprecating ntext.

Important

For a managed relational database service such as Amazon RDS, be aware that some update scripts might require root level access to the system tables in the underlying database.

Specifically, certain PostgreSQL update scripts require access to the pg_attribute table. Because the database service super user is not the same as the PostgreSQL root user, such scripts might fail with a permissions error. In this case, investigate the failing script, and use an ALTER TABLE command on the specific IDM table instead.

Launch IDM and run the following Groovy script to clear the reconprogressstate data in your repository:

def result = openidm.query(
  "repo/reconprogressstate", [ "_queryFilter" : "true", "_fields" : "_id" ]).result;
for ( item in result ) {
  openidm.delete("repo/reconprogressstate/" + item["_id"], null);
}
return result.size() + " reconprogressstate records deleted";

This script will work regardless of the type of repository, and can be sent as a REST call. For example:

curl \
 --header "X-OpenIDM-Username: openidm-admin" \
 --header "X-OpenIDM-Password: openidm-admin" \
 --header "Content-Type: application/json" \
 --request POST \
 --data '{
   "type":"groovy",
   "source":"def result = openidm.query(\"repo/reconprogressstate\", [ \"_queryFilter\" : \"true\", \"_fields\" : \"_id\" ]).result; for ( item in result ) { openidm.delete(\"repo/reconprogressstate/\" + item[\"_id\"], null); }; return result.size() + \" reconprogressstate records deleted\";"
 }' \
 "http://localhost:8080/openidm/script?_action=eval"
"1 reconprogressstate records deleted"

Verify that all scripts and functions behave as expected.

Create a New Repository

Set up a new repository, following the steps in Select a Repository. A new repository is already configured for all the new capabilities in IDM, but does require migrating existing data to that repository.

If you create a new repository, you must still update your configuration files to use the new features.

After you have set up the new repository, migrate your data to that repository.