Object Migration import tips
You can use these tips to better understand the Object Migration import process.
| Object Migration area | Tip |
| Associations | The Object Migration process merges associations. Any new associations stay intact. |
| Business Object Type (general information) | Business object type information is overwritten by the import process. |
| Cache | In past implementations of Object Migration it was necessary to clear / refresh the system’s cache after a successful import. It is no longer necessary to clear the cache. The import process automatically refreshes the cache. |
| Content objects | These objects are used and referenced by Record Data and Form objects and are added automatically as required dependents during the Export process. During import, all content objects show as new objects (green). If a content object in the source has the same name as a content object in the target, a new content object is created in the target during import. |
| Default form | When the form is imported, the default flag is set to the form that is imported. You might want to reset it. |
| Duplicate objects | If the target system contains more than one object with the same name, a warning is written to the Object Migration log. For example, say a query at the Module level and a query in one of the module’s business objects. The import process updates the object in the target system that has the lowest ID with the object from the import package. |
| Dynamic list | All dynamic list information is overwritten by the import process. |
| Field mapping | Field mapping is overwritten, with 1 exception. If a control start number of the imported field mapping is smaller than a current control number, the current control number is retained. |
| Fields | The Object Migration process merges business
object fields. All modifications to existing fields in the business
object are overwritten with several exceptions:
Whenever possible, change existing fields in the forms. If the required and the read-only attributes are set in the Data Modeler, they cannot be overridden in the form. If changes are made to existing field properties prior to the import, these changes need to be redone after the import. |
| Forms | All form information is overwritten by the Object Migration import. To preserve any modified form, rename the form. To retain the original form, make a copy of the form before you change it and rename it back to the original name. |
| Import twice | In past implementations of Object Migration it was necessary to perform every import twice. The import process now automatically imports the Object Migration package twice. |
| Language tables | When an object migration package that was created before TRIRIGA Application Platform 3.3 is imported into an environment that was upgraded to TRIRIGA Application Platform or later and IBM TRIRIGA 10.3 or later, the language table is deleted. |
| Navigation collection / Navigation item | All navigation collection/navigation item information
is overwritten by the import process. To preserve any of your modifications
to the managers:
Alternatively, if the changes are minimal, you could make note of the changes and reapply after the import. In some circumstances, this alternative method might be the quicker option. |
| Module | Existing modules are not changed by the import process and any new modules are added. |
| Portal | When an imported portal has the same name as an existing portal, all portal information is overwritten by the import process. |
| Pre-Create workflow | If a pre-create workflow is modified, after
an import you need to repoint this attribute in the Data Modeler to
the renamed workflow. The import process resets the attribute to a
workflow with the prefix tri. |
| Publish name | If the publish name is modified prior to the import, redo the modification after the import. |
| Queries/Reports | All query/report information is overwritten by the import process. To preserve any modified queries/reports, rename the query/report. To retain the original query/report, make a copy of the query/report before you change it and rename it back to the original name. |
| Record Data | All record data information is overwritten by
the import process. With older versions of Object Migration, the Record Data XML was not exported with the name of the form or the object state, which causes unpredictable behavior during import. If new Record Data does not have a Form name, the system uses the default form for the business object. Also, if the object state is not specified, the system chooses an arbitrary action to transition the new Record Data from the null state. The migration package includes information for all associations that are discovered in the source environment for Record Data included in the package. Associations for Record Data included in the package are established for the target environment during the migration package import process. When you create the package, you can choose to not include association information for any record. Open the panel for the Record Data included in the package. Select one or more records, and click the Do Not Include Associations link. A red asterisk appears next to the record name in the Record Data panel for any records that will not include association information during the migration process. To reinclude record association information, select one or more records in the Record Data panel, and click the Include Associations link. For those packages generated with older versions, export your packages again. |
| Section | Business object sections are merged in the Object Migration import. |
| Section field | Section fields are merged in the Object Migration import. |
| Security group | All security group information is overwritten
by the import process. Security group members are not included in the import process. |
| State family | The Object Migration import overwrites business object state families. |
| Static list | All static list types are overwritten by the import process. However, static list values are merged. |
| Structure | The import process overwrites structure. |
| Style | Object Migration’s import tries to replace styles, with 2 exceptions: System styles and styles that are in use are not replaced. |
| Workflows | Workflows are overwritten by an import, but
the version is retained and the state of the workflow is preserved. When you import a workflow and the workflow is triggered by an association with an association string that is not currently in the Association Types list, the import adds the string to the Association Types list. Asynchronous Workflows (such as action, association, de-association)
Synchronous Workflows
|