Migration Project

Use migration project to migrate data from source to target server.

By default, new migration projects created via the UI under Business Process Automation > Migration Project Management > Migration Projects, will have a Project Type of Export. The project type is purely informational in this version of the feature; i.e. there is no restriction on exporting projects which have a project type of Import. The main use is to identify the primary purpose of the migration project.

The Manual Sequencing flag indicates whether or not to allow the application to decide the order in which data is loaded. If this is checked, you must order the data in the required sequence. See the Manual Sequencing section below for a full description.

The Commit Scope indicates which transaction scope should be used when importing data. There are two possible values:

• Object ID (default) specifies that each object within a group should be treated as an individual unit of work. If one object import fails it will not impact other object transactions.
• Group specifies that all the objects within a group should be treated as an individual unit of work. If one object in the group fails, then the whole group will fail but no other group will be impacted.

The Refresh Cache flag indicates whether in memory cache objects should be refreshed after an import. By default, this flag is selected.

The Raise Lifetime Events flag indicates whether lifetime events for objects created, modified or removed on import should raise workflow events. By default, the flag is not selected.

Both these flags are also available on the Object Group. The current setting for the Refresh Cache and Raise Lifetime Events flags at the Project header level are used for each newly created Object Group. For example, if both flags are set, any newly created Object Group will also have both flags set. However, subsequently changing the flags on the Project header level will not affect previously created Object Groups; only ones created after the change.

The next step is to define the groups of objects of specific types, e.g. Agent, by using the New Migration Object button.

The type of object in the migration object group is determined by the Screen Set ID (also known as a Finder Set). A screen set specifies the Finder used to search for objects of a given type. Once the Screen Set ID is selected e.g. AGENT, the grid for saving an Object ID will be associated to objects of that type, i.e. by using the Find or List icons on the Object ID field, it will present the Finder Query page for the type, i.e. in this example will present an Agent Finder.

One or more IDs can then be added to the groups and saved. The group can also be edited later to remove previously saved Object IDs or to add new Object IDs.

Any number of additional groups can be added including multiple groups of the same type. By default, the list of Migration Object Groups will display in the order they were added. It is only when the Migration Project is Finished and saved to the database that the true sequence of how the object groups should be processed is calculated.

The Transaction Code specifies how the object data should be processed by the target system and can currently be one of: -

• Insert: Create new object and report an error if an object with the same ID already exists
• Insert Ignore: Create new object only if object does not already exist. Do not error if it does.
• Insert Update: Update an existing object or create one if it does not already exist.
• Delete: Remove object. Report an error if it does not exist.

Migration Project Status

During the life cycle of a migration project, the status of the project can change to reflect its current state.

When an Export project is first created it will be in ACTIVE status and when it is successfully exported it will be in EXPORTED status. Because an Import project is typically created when a Project Package is imported, the initial status will normally be IMPORTED for a successfully imported package. The PARTIAL status indicates that some objects were imported successfully whereas some others will have failed.

There is also an ERROR status that is intended to show that errors occurred during either the import or export process depending on the Project Type and system where the process occurred.

The RUNNING status indicates that an Import or Export process is currently in progress and should therefore ultimately change to one of IMPORTED, PARTIAL, EXPORTED or ERROR when complete based on results.

Migration Object Status

As well as status at the Project level, each migration object group and individual Object ID also has a status. If any one of a group’s objects has an ERROR status, then the overall group status is also ERROR. The Object ID which is in error will also have a Failure Reason ID to explain why the error occurred. See below for a list of possible IDs and an explanation of the reason for failure and options for resolution.

Failure Reason ID	Reason	Solution
MIGR_PROJ_PK_NOT_EXIST	An Object ID in an Export project does not exist.	Recreate Object or remove Object ID from Migration Object Group.
DBXML_IMPORT_INTERNAL_ERROR	DBXML has reported an error trying to load an object group.	Review logs (may need to turn on DBXML log ID) and take appropriate corrective action.

 

Migration Project Version

The Version field is designed for informational purposes to reflect which version of an exported project was used for an import. The Export project will start at version “1” and increment each time an update is made to the project. When an exported package is imported into a target system, the version of the project at the time of export will show in the imported project.

Manual Sequencing

Some object IDs, for example LOCATION, can appear as a foreign key on many tables in the OTM data model. Consequently, it can appear, based purely on the data dictionary, that there is a circular relationship between certain tables. Clearly this is not the case as the application context prevents such a situation (many foreign keys are optional fields and only used in certain specific cases).

However, what this means is that for certain object types e.g. Service Provider, depending on the level of configuration complexity on a particular instance, that the automatically determined sequence is not sufficient.

For any such cases, the Manual Sequencing override flag can be used to control the sequence of importing groups. Use of this flag enables the Link Sequence field allowing values to be specified for each Migration Object Group in the project. This will cause the entered values to be used when processing the data and these will not be overridden by the application when the project is saved.

The Link Sequence is an integer field and reordering of groups may require updating multiple groups. For example, if groups exist with sequences 1, 2, 3 & 4 and the requirement is to move the current item 2 to follow the current item 3, this would be achieved as follows:

• Renumber group 4 to be group 5
• Renumber group 2 to be group 4
• Save project.

Note: Following is a list of known Object Types that may need to be manually sequenced in the order specified: 1). AGENT_EVENT, AGENT. 2). SAVED_QUERY, SAVED_CONDITION. 3). REPORT, IPP_PRINTER.