Upgrade Guide for DB2 UDB for z/OS and OS/390 > Postupgrade Tasks for a Development Environment >

Resolving Business Component and Join Conflicts

Upgrades: All upgrades.

Environments: Development environment only.

After the Upgrade Siebel Database Schema phase, you may need to perform manual steps to business component fields and joins, depending upon the complexity of your business component configuration. It is strongly recommended that you thoroughly review the post upgrade configuration to make sure that the object level definitions are preserved as expected. During the upgrade, a list of business component joins and fields that need to be manually rectified are generated in a log file titled, upgcust.log. This particular log file, along with others generated by the upgrade process, can be found under SIEBEL_ROOT/log.

The log file contains two distinct sections:

• Part 1:

  For extension columns on obsolete tables such as S_EMPLOYEE and S_ORG_INT, you need to reimplement the extension columns on the replacement tables. After you have done this, review the business component definition to verify proper operation.

  The report generated by part 1 of the log file provides a list of the business component fields that are based on custom extension columns in obsolete tables such as S_EMPLOYEE and S_ORG_INT. This list displays the following properties:

  • Business component name
  • Field name
  • Column name

    The table S_EMPLOYEE is migrated to three tables, S_CONTACT, S_EMP_PER and S_USER. After you have determined and implemented the approach for previously defined custom extension columns on obsolete tables, you should manually configure the business component field to reference that database column. Any manual reconfiguration must be done in the New Customer Repository after the upgrade has been run.

• Part 2:

  Because the data from S_EMPLOYEE and S_CONTACT has moved into more than one table, there is potential for conflicts between custom configuration from a previous release and standard configuration in 7. You need to resolve these conflicts in order for the application to function as designed.

  After the repository merge has been run, there may be inconsistencies in the join names and joins set at the field level. If you do not resolve these discrepancies, it is likely that the application configuration will result in errors or will result in incorrect behavior. The report generated by part 2 of the log file provides a list of joins that were not updated during the merge process. This list displays the following properties:

  • Business component name
  • Join name

    With this list, you will need to go to each of the business component definitions and manually change the join name from the current value to the value listed in the report. Make sure that there is consistency between the joins as defined by name and the joins defined for each of the fields. Again, any manual configuration must be done in the New Customer Repository after the upgrade has been run.