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
  • List of all objects that are associated with the custom object labels.
  • This report (CSV file) is created during preparation.
Report 2
  • Report of all object changes that are associated with the custom object labels.
  • This report (TXT file) is created during preparation.
Report 3
  • Comparison report from the OM application upgrade in a clean environment.
  • This report is created during upgrade.
Report 4
  • Comparison report from the OM application upgrade in a development environment.
  • This report is created during upgrade.

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
  • These objects are modified by you (the customer), but are not modified by IBM TRIRIGA in the application upgrade.
Action
  • None. The modified objects should already be in the production system. Ignore these objects because they are not part of the application upgrade package.

Report 3 only

Objects are not in Report 1, but are in Report 3

Description
  • These objects are not modified, and are safe to import. The objects are part of the application upgrade package and were never touched by you (the customer) in the environment. No object modifications will be overwritten.
Action
  • None. The modified objects are only in the application upgrade package.

Both Reports 1 and 3

Objects are in both Report 1 and Report 3

Description
  • These objects are modified by you (the customer) and by IBM TRIRIGA in the application upgrade package.
Action
  • Remove the objects that are in both Report 1 and Report 3 from the package and import the package in the Object Migration tool. Then proceed to Part 3.

III. Part 3: Merge objects

You must manually merge the objects in both Report 1 and Report 3 by performing the following two actions.

Note: Merge Label

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 Tools > System Setup > System > Object Label Manager.
  • 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

Example of creating an object 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
  • Import the objects and then manually apply the Report 2 changes to the upgraded object. Perform the manual merge for all objects in this state.
  • Apply the "merge" custom object label to the In Progress objects.

Report 2 > Report 3

Objects with more changes in Report 2 than in Report 3

Action
  • Do not import the objects. Manually apply the Report 3 changes to the existing objects. Perform the manual merge for all objects in this state.
  • Apply the "merge" custom object label to the In Progress objects.
Note: Object Changes Report

The object changes report ("Report 2") includes workflows and UX metadata. Keep in mind the following items.

For workflows, the report indicates only whether a workflow’s details are the same or different between revisions. To determine the exact differences, you must use the Text Export or Text Export Selected feature.

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.

Note: UX Metadata Object Type

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.

Note: Workflow Validation

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

Note: Custom Object Label

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.

Example of Object Label Inheritance and Merges

Example of object label inheritance and merges