Upgrade process
What is the process for application upgrade? The general high-level process for an object migration (OM) application upgrade is as follows: (1) Generate comparison report, (2) Compare objects, (3) Merge objects, and (4) Validate objects.
Contents
I. Part 1: Generate comparison report
Generate a comparison report of the object migration (OM) application upgrade package in a clean TRIRIGA application environment that you are currently running ("Report 3").
During upgrade, the following reports are used.
Reports for Application Upgrade
Report | Description |
---|---|
Report 1 |
|
Report 2 |
|
Report 3 |
|
Report 4 |
|
II. Part 2: Compare objects
Compare all of the objects in Report 1 with the objects in Report 3. Evaluate the objects for each of the following scenarios.
Scenarios for Object Comparison
Scenario | Description & Action |
---|---|
Objects are in Report 1, but not in Report 3 |
Description
|
Report 3 only Objects are not in Report 1, but are in Report 3 |
Description
|
Both Reports 1 and 3 Objects are in both Report 1 and Report 3 |
Description
|
III. Part 3: Merge objects
You must manually merge the objects in both Report 1 and Report 3 by performing the following two actions.
Make sure to use your most recent custom label when you create the "merge" custom object label.
For example, if your most recent custom object label is Acme:1.0, and you are merging your modified objects with 10.5.2, then the "merge" label must be "Acme:1.0 (IBM-T:10.5.2)". However, if your most recent custom object label is Acme:2.0, then the "merge" label must be "Acme:2.0 (IBM-T:10.5.2)".
Action 1. Create a "merge" custom object label for the objects.
- a. Select .
- b. Click Add.
- c. For Label owner, enter your company name or an abbreviated version of it. In this example, Acme.
- d. For Label version, enter the most recent custom object label version followed by a space, then the IBM TRIRIGA application object label. For example, enter "1.0 (IBM-T:10.5.2)" without the quotation marks.
- e. For Generated From, select the custom object label. In this example, Acme:1.0.
- f. For Merged From, select the IBM TRIRIGA label. In this example, IBM-T:10.5.2.
- g. Enter a Description that describes the intent of this object label.
- h. Click Create.
Object Label Manager > Create Merge Label
Action 2. Analyze each object to be merged by comparing the object changes in Report 2 with the object changes in Report 3. Note that Report 2 contains the actual object changes on your environment. Evaluate the objects with the following guidelines.
Guidelines for Object Merge
Guideline | Description & Action |
---|---|
Objects with more changes in Report 3 than in Report 2 |
Action
|
Report 2 > Report 3 Objects with more changes in Report 2 than in Report 3 |
Action
|
The object changes report ("Report 2") includes workflows and UX metadata. Keep in mind the following items.
- For information on Text Export, see "Exporting workflows as text" in Chapter 7: "Workflow building" of the Application Building for IBM TRIRIGA Application Platform (PDF) user guide.
- For information on Text Export Selected, see Chapter 6: "Exporting workflows as text" of the Object Migration User Guide (PDF).
For UX metadata, the files that are attached to the Web View File metadata, such as HTML and CSS files, are included in comparison reports. But the reports indicate only whether the content files are the same or different. The details on the differences are not reported. When the report indicates No Differences on Web View Files, it means that all properties and any attached content files are the same. If differences are reported, then to determine the exact differences, you must compare the content file versions by using an HTML "diff" tool. For more information on comparing UX metadata, see Compare and merge HTML/JS views.
The UX metadata comparison is more granular in Report 2 than in Report 3.
For example, for any UX metadata change in Report 3, the Object Type is either Application or Web Component, where the Component Type is not set to View. However, for any UX metadata change in Report 2, the Object Type is Application, Model, or Web Component. This fact is relevant because the display path on both reports will show the tree structure of the change starting from the Object Type. For instance, Report 3 will show a change to Data Source ABC in Model ABC of Application ABC as being a change to the Object Type of Application. Report 2 will show the change as a being a change to the Object Type of Model.
During OM import, any changes on the target environment to UX metadata components in a UX Application will be deleted if that UX metadata component cannot be found in the OM package for the same-named UX Application being imported. The same is also true for Web Components, where the Component Type is not set to View. You will need to import the package and apply your changes back after the import.
IV. Part 4: Validate objects
Run the comparison report from the object migration (OM) import package in the development environment where the merge was completed ("Report 4"). Then compare Report 2 and Report 4. Report 4 should be the reverse of Report 2.
Workflows cannot be validated by using this method.
As with previous TRIRIGA versions, use Text Export or Text Export Selected to validate the workflow merge.
V. Object label inheritance and merges
The next time that you want to apply a custom object label to modified objects to prepare for application upgrade, you must create a new custom object label.
For example, if you created and applied Acme:1.0 in 10.5.1, you must start with Acme:2.0 in 10.5.2. Or if you created and applied Acme:1.0 and Acme:2.0 in 10.5.1, you must start with Acme:3.0 in 10.5.2.