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

   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
   
   #Optional Parameters
   REFERENCES_CHECK=ALL

2. Run the Preassessment report:

   java -jar MonthlyUpdate.jar -i <ini_file> -p <Table Owner Password> -z <User Password> -t <Log Name>

   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)	********
   -t	(Optional) The base name of the log file and folder.	<null>

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: Summarizes the previous repository version, the new repository version, the workspace against which the report ran, and related information. It also includes a count of all attributes that Oracle changed and a count of attributes that are critical (that is, in conflict with customer changes).
  • Full Summary: Provides a count of Oracle changes by top-level object type. This section is informational.
  • Critical Summary: Provides a count, by top-level object type, of changes where both the customer and Oracle changed the same attribute on the same object. This section indicates the maximum possible number of conflicts that might affect customer functionality.

• Categorization — You can filter both sections to All, Critical, or Informational.

  Note: It is recommended filtering to Critical only.
  • UI Layer: Shows each specific attribute at the user interface layer that Oracle changed. When you select Critical, the report shows only the attributes where both the customer and Oracle changed the same attribute on the same object.
  • Business Layer: Shows each specific attribute at the business layer that Oracle changed. When you select Critical, the report shows only the attributes where both the customer and Oracle changed the same attribute on the same object.

• Testing Data

  • Repository: Shows each affected object and all objects that reference it. For example, if Oracle changes an applet that ten different views use, the report lists those ten views.
  • Test Automation: Shows each affected object that a Siebel Test Automation script references.