In TRIRIGA/MREF Object Migration (OM) is the mechanism for moving metadata changes between environments. When learning about Object Migration one learns that the way it identifies and updates objects is by the object's name, not its ID. IDs are local to an environment and are based on the order in which objects were created in that environment. This makes sense
The fact that it looks for the name as led to several issues over the years. When I first started at TRIRIGA in 2009 there was no enforcement for name uniqueness in objects like queries and workflows. If there was more than one object with the same name, which one get's updated? I always figured it was random because in SQL if you don't specify an order then the order is random. This often led to the wrong object getting updated. I don't know if it was the case back then, but now we do know what order as its specified in the Object Migration User Guide that it will update the one with the lowest Id and log an error in the object migration log.
The duplicate name issue got solved in the base product by adding the object's id to its name so you could differentiate the different workflows. You'll still see some workflows and queries in the system that have their Id's in parenthesis in their name, like triMyCompany - Find (2612).
The other drawback of updating by name is due to human error. Sometimes objects are created with a leading space or trailing space in their name, or even extra spaces somewhere within it. So if an object was created with a trailing space in its name, and then later was fixed. When the new object comes in, the old objects is not an exact match so it would create a new object. This was problematic as it could lead to an environment being out of sync with some objects pointing to the original object and others being pointed to the new one. The only way to have avoided this would have been to rename the existing object in the environment first, and then bring in the OM so that it can find and update the object.
Renaming is a manual process that must be done in each environment prior to bringing in an OM Package. Because it is a manual process it is also prone to human error and your environments can get out of sync if you didn't rename all the same objects the same exact way in each environment. This is always an issue during application upgrades because no list of renamed or deleted objects is provided when a new version comes out.
Name matches are case-insensitive and trimmed
Fortunately the OM Tool logic has changed over the years and now the tool will convert names to uppercase as strip off trailing and leading spaces when it is looking for matches.
Object Migration does not compare names exactly as you typed them. It ignores case, and it ignores spaces at the beginning and the end. Foo, FOO, and Foo with a trailing space are the same object.
It does not ignore extra spaces in the middle. triTask - Find with two spaces is not the same object as triTask - Find with one. Only the ends are stripped.
This means you can now fix the name of an object with a leading or trailing space and OM it to the next environment and it will update that object, and also renaming it as it takes the new name value. It however, does nothing for extra spaces within the name itself. For those you still need to manually rename and then fix.
Association is the exception on the Association String. After Object Migration finds the from and to business objects by name, the Association String must match exactly as it was stored, including case and any extra spaces. Contains and contains are not the same association on import, and a trailing space on the Association String is not ignored. Two associations can still share the same Association String if they connect different business objects.
The value used to decide if it already exists
The lookup is not a global name search. It is type-specific. For some types it is a composite of parent names plus the object name.
A BO always lives in a module. Object Migration finds the module first, then the BO name inside that module. It will not update a BO with the same name that lives in a different module. If the module is not already on the target, put it in the same package. Modules are imported before BOs. The same idea applies to a form: the module and the BO have to exist first.
Object type | Identified by | Notes |
|---|---|---|
Alternate Form List | Alternate form list name | |
Association | From module + from BO + Association String + to module + to BO | In the package the object name looks like |
Budget Token | Token name | |
Business Object | Module name + BO name | |
Calendar Set | Calendar set name | |
Content | File name | In the package the name is a content id plus the file name, so a match almost never happens. |
Document | The document's path | Looked up under the Document module / Document BO. The path is what matches, not the Name field. |
Form | Module name + BO name + form name | |
Form Style | Style name | |
Group | The group's path, for example | Looked up under the Group module / Group BO. The path is what matches, not the Name field. |
Hierarchy Structure | Module name + hierarchy structure name | This is the named flattening definition used by metric reports. It is not the Location, Geography, or Organization tree of records. |
List | Module name + list name | |
Module | Module name | |
Navigation Collection | Navigation collection name | |
Navigation Item | Navigation item name | |
Portal | Portal name | |
Portal Section | Portal section name | |
Query | Module name + query name | If more than one object has the same name, Object Migration writes a warning and updates the one with the lowest ID. IBM's example is a module-level query and a BO-level query. |
Record Data and UX | The record's path, plus the module and, when present, the BO | Same idea as groups and documents: the path matches, not the Name field. |
Scorecard | Scorecard name | |
Workflow | Module name + workflow name, plus the BO when the workflow is defined on one |
Groups, documents, record data, and UX still use the same name compare, but the value is the record's path, not the name you type in the Name field. That is why a group import matches a path like \Admin Group.
If more than one object on the target has the same name, Object Migration writes a warning and updates the one with the lowest ID. IBM's example is a module-level query and a BO-level query.
Control numbers in the published name
Record Data is matched by the record's path. That path comes from the published name. The published name is the BO Mapping: the fields you picked, in order, with punctuation between them.
A BO can have a Control Number field. The platform assigns the next number in that environment when the record leaves the null state. Each environment has its own sequence.
If the Control Number is one of the fields in the published name, the path is different in every environment. Object Migration looks up the path from the package. It does not find the record on the target, because that record's name has a different number. So it creates a new record. You cannot update the existing one this way.
The IBM TRIRIGA Application Platform 5.0 Object Migration User Guide has the same pattern for Dictionary records: the name is mapped from a control number, the sequences differ between source and target, and import can create duplicates. Do not put the Control Number in the published name for records you expect Object Migration to update.
UX is not a merge
If an Application or Web Component already exists on the target, Object Migration creates a revision before the first import pass. UX metadata that is on the target for that application but is not in the package is deleted. That is how a custom view you thought you were leaving alone disappears. Download the attached HTML and CSS yourself if you need to see what will be replaced.
Application and Web Component search is also the one place dependents are auto-selected. For every other type you add dependents yourself, or you import onto a target that already has them.
Comments (0)
No comments yet.
Sign in to comment.