1. Database Upgrade Guide
  2. Running the RepositoryUpdate Pre-Assessment

Running the RepositoryUpdate Pre-Assessment

This topic describes how to run the RepositoryUpdate Pre-Assessment Report to preview and categorize RepositoryUpdate changes, identify critical conflicts, and review output reports to estimate the effort required before running the full RepositoryUpdate utility.

You can run the RepositoryUpdate Pre-Assessment process to understand what changes would be made by a full execution of the RepositoryUpdate utility. This provides insight into the following areas:

  • Identification and categorization of the specific changes that RepositoryUpdate makes:

    • Critical changes are identified when the customer’s repository and the Oracle-provided repository indicate that the same attribute on the same object changed.
    • Informational changes provide insight into other changes that RepositoryUpdate makes.

  • Reports that allow customers to preassess the effort required to apply the changes in the RepositoryUpdate payload:

    • An HTML report that you can share without requiring access to the Siebel application.
    • Web Tools views that allow sorting, searching, and other capabilities provided by Siebel list applets and other standard artifacts.

To Generate the RepositoryUpdate Pre-Assessment Report

Follow these steps:

  1. Create an INI file defining critical parameters. Copy the setup.ini file generated by PostInstallDBSetup and make minor changes to it. The following table illustrates the required content:

    Parameter Description Example
    SIEBSRVR_ROOT The Siebel Server root directory. This is the parent of the "siebsrvr" folder. C:\Siebel\siebsrvr
    REPOSITORY The name of the Repository against which the analysis should be performed. Siebel Repository
    DB_TYPE Oracle, MSSQL,DB2UDB ORACLE
    ODBC_DSN The ODBC source to use for running the report. Siebel_DSN
    TBLO The tableowner. SIEBEL or dbo
    TBLOUSER If the tableowner user is different from the tableowner, such as on MSSQL, this would be the actual username, such as SIEBEL, while the TBLO would be "dbo". SIEBEL
    SIEBUSER An actual Siebel user with database login privileges (typically SADMIN). SADMIN
    SSE_ROLE The grantee role that all users share for the Siebel database. SSE_ROLE
    UNICODEDB Whether or not the database is Unicode. Y
    PRIMARY_LANG_CD The primary language code specified when the database was installed. ENU
    OTHER_LANG_CD Any other language codes that are used in the customer's implementation (comma-separated list). FIN,DEU,FRA
    PARENT_WS The Workspace against which the assessment should be performed. This should be the same workspace against which you would run the RepositoryUpdate utility itself so that your preassessment will be consistent with your actual results when you run the full utility. int_release_X
    REFERENCES_CHECK

    This indicates whether reference checks should be performed for all objects or only for objects which have critical issues. Possible values are "ALL" or "CRITICAL".

    For more information, see References Check Parameter.

    Default is "CRITICAL"

    		 CRITICAL
    LOG_FOLDER

    The location where the logs and HTML report should be generated.

    Default is the ...\siebsrvr\log folder.

    		 x:\Siebel\MonthlyUpdate\Preassessment\26.6\report
    UPT_FOLDER If UPT analysis is to be performed, copy the UPT files from the production environment into a folder on the development machine where the Pre-Assessment Report will be run and specify that folder here x:\Siebel\MonthlyUpdate\Preassessment\26.6\UPT
    LOG_ANALYSIS_FOLDER If product Object Manager log file analysis is to be performed, copy the Object Manager logs from the production environment into a folder on the development machine where the Pre-Assessment Report will be run and specify that folder here x:\Siebel\MonthlyUpdate\Preassessment\26.6\OM_Logs

    Example of INI file:

    SIEBSRVR_ROOT=C:\Siebel\
REPOSITORY=Siebel Repository
DBTYPE=Oracle
ODBC_DSN=ORA025133
TBLO=ORA025133
TBLOUSER=ORA025133
SIEBUSER=SADMIN
SSE_ROLE=SSE_ROLE
UNICODEDB=Y
PRIMARY_LANG_CD=ENU
OTHER_LANG_CD=
PARENT_WS=int_child
LOG_FOLDER=x:\Siebel\MonthlyUpdate\Preassessment\26.6\report
           
#Optional Parameters
REFERENCES_CHECK=ALL
UPT_FOLDER=x:\Siebel\MonthlyUpdate\Preassessment\26.6\UPT
LOG_ANALYSIS_FOLDER=x:\Siebel\MonthlyUpdate\Preassessment\26.6\OM_Logs

  2. Run the Preassessment report:

    java -jar MonthlyUpdate.jar -i <ini_file> -p <Table Owner Password> -z <User Password>
    Argument Description Example
    -i

    The name of the INI file created in the previous step.

    If this is not in the same folder, a full path is required.

    		 RU_setup.ini
    -p The Tableowner's password ********
    -z The user's password (typically the SADMIN user) ********

  3. Review the output in the HTML file that was generated into the specified log folder.

References Check Parameter

The RepositoryUpdate Pre-Assessment Report can inspect the repository to determine where a change might affect other objects. For example, a change to a business component might affect an applet, workflow, picklist, or another object that references that business component. This information can help you focus testing on areas that are heavily used in a customer implementation.

You can run reference checks at two levels of verbosity:

  • ALL — The report performs reference checks for any change made by Oracle.
  • CRITICAL — The report performs reference checks only for artifacts that both Oracle and the customer changed.

The default value is Critical.

Components of the RepositoryUpdate Pre-Assessment Report

The RepositoryUpdate Pre-Assessment Report includes three top-level areas, each with child sections as described below:

  • Summary

    • Update Info: Provides a summary indicating the previous Repository version, the new Repository version, the Workspace against which the report was executed, and so on. It also provides a count of all the attributes changed by Oracle, along with a count of those which are critical (that is, in conflict with customer changes).
    • Full Summary: A count, by top-level object type, of the changes made by Oracle for each object type. This is informational.
    • Critical Summary: A count, by top-level object type, of the changes where both the customer and Oracle made changes to the same object and attribute. This provides insight into the maximum possible number of conflicts that might affect customer functionality.

  • Categorization

    Note: You can filter both sections to All, Critical, or Informational.
    Note: It is recommended filtering to Critical only. In all cases, the analysis shows each specific attribute at the given level that was touched by Oracle. When "Critical" is selected, this shows only the attributes where both the customer and Oracle changed the same attribute on the same object.
    • UI Layer
    • Business Layer
    • Database Layer

  • Testing Data

    • Repository–Shows each affected object and all objects that reference that object. For example, if a changed Applet is used on ten different Views, those ten Views will be listed.

    • Test Automation–Shows each affected object that is referenced in a Siebel Test Automation script.

      Note: The Test Automation Scripts must exist in the Development environment against which the Pre-Assessment Report is executed.

    • Usage Pattern Tracking–Compares the changes made by Oracle to the actual end-user usage in Production as captured by Usage Pattern Tracking.

      To use this feature:
      1. Turn on Usage Pattern Tracking in the Production environment for some period of time–a week or more–to capture end-user behavior.
      2. Copy the UPT logs to a folder on the Development environment and specify the UPT_FOLDER parameter in the INI file.
    • Object Manager Logs–Analyzes logs from the Production environment to compare the changes made by Oracle to end-user behavior.
      1. Copy Object Manager logs to a folder on the Development environment
      2. Specify the LOG_ANALYSIS_FOLDER parameter in the INI folder.

Reviewing the Pre-Assessment Report and Preserving Customization

During analysis of the Monthly Update Pre-Assessment Report results, you will be able to review conflicts between your changes and those provided in the RepositoryUpdate content. In some cases, it will be appropriate to take the change in the Oracle package, while in other cases, you may wish to preserve your customizations. This is not always a simple proposition–choosing to maintain existing customization may interfere with new features, while accepting the Oracle changes may break existing functionality. It is important to perform this analysis carefully.

Some examples:

  • You have modified the validation rule for a BusComp Field and Oracle modified the validation rule for that same Field. You should inspect the two and determine which would be more appropriate for your implementation. In this type of case, you may actually want to combine the two rules, so you would make a note of it before running the RepositoryUpdate process and manually combine the two rules later.
  • You have modified the "Force Active" attribute of a BusComp field from NULL to "N", and Oracle has modified it to "Y". In this case, you would want to keep the Oracle value, because there must be some reason that it was set to true (for example, to make it available to some C++ code or Workflow). Keeping your value of "N" would break that functionality.
  • You have modified the Search Specification for an existing BusComp and Oracle has modified the same Search Specification. You know that your users prefer your setting, so you want to keep it as it is.

In the cases where you are sure you wish to keep your value when you run RepositoryUpdate, you can perform the following steps:

  1. In Web Tools, find the Pre-Assessment Report record that you are interested in.
  2. Check the Retain Customer Value option for any attribute where you want to maintain your value.
  3. When running the RepositoryUpdate utility, you must do the following:
    1. Specify the same parent Integration Workspace that you used for the Pre-Assessment Report.
    2. Add the "-0" command line argument, specifying the Id of the Pre-Assessment Report as provided by Web Tools.

      For more information on the use of the RepositoryUpdate utility, refer to RepositoryUpdate Utility.