Updating the CES Database Automatically

About Updating the CES Database Automatically

Over time, it may become necessary to change the data model, based on changes in requirements, problems that occur, or new functionality that is added. Data model changes generally fall into one of the following types:

  • Modification of existing attributes or properties in a specific category or class: These are considered high impact changes. If the changed category is used by the user and contains data, that data may have to be recreated, depending on the actual changes made to the attribute(s). Examples of this kind of change are: changing the label of a property, changing the mandatory status of a property, or changing a normal property to a primary key.
  • Creating or modifying forms for a specific category or class: These are considered high impact changes. If a form is modified during or after deployment, as part of customization, then a change to the out-of-the-box version of the same form will create conflict and have to be resolved manually, to retain the customization.
  • Adding a new attribute or property to a specific category or class: These are considered low impact, since they do not impact the existing setup.
  • Adding a new category or class:  These are considered low impact, since they do not impact the existing setup.

All data model changes made during any main cycle, for example a new release, a service pack, etc. are provided as CES DBLoad files. These changes are distributed with clear demarcation in the package. For example, R1n SPx changes are available in <OS_a>/resources/sdm/sdmdb/dbUpdate/R1nSPx, where n is the last number on the release (R17, R18, etc) and x is the number of the service pack (SP1, SP2, etc.).

This process can be carried out manually, but it is difficult and time consuming. The difficulties associated with manual updating include:

  • setting up DBLoad and running the scripts manually
  • configuring the DBLoad utility is not easy
  • there is no information in the database to determine which data model changes are applied
  • messages displayed while running the DBLoad utility cannot be interpreted
  • trouble shooting this process is difficult

To make this process easier, an automated method is provided as a stand-alone tool, CESDBUpdate. This tool does the following:

  • Determines the existing level of the CES database
  • Executes the scripts to update the CES database to the requested level
  • Interprets messages generated during script execution and reports meaningful information to the user.

For information about configuring the dbload.cfg file, refer to CES Enterprise Catalog Installation : User Tasks : Post Installation Tasks : CES DBLoad Configuration : Configuring the DBLoad Utility.

Ensure that the JDBC thin driver files are copied to the CES Installation directory, <OS_a>/docs/javacommon where <OS_a> refers to the supported platform of the software, for example, intel_a for Windows or aix_a for IBM AIX.

  • For an Oracle database on Windows, the JDBC thin driver files (classes12.zip and ojdbc14.jar) are located under %ORACLE_HOME%\jdbc\lib directory,

    where
    %ORACLE_HOME% refers to the installation directory of the Oracle software.

  • For an Oracle database on UNIX, the JDBC thin driver files (classes12.zip and ojdbc14.jar) are located under $ORACLE_HOME/jdbc/lib directory,

    where
    $ORACLE_HOME refers to the installation directory of the Oracle software.

  • For a DB2 database on UNIX, the JDBC thin driver files (db2jcc.jar and db2jcc_license_cu.jar) are available under $DB2_HOME/java directory,

    where
    $DB2_HOME refers to the installation directory of the DB2 software.

When Updating the CES Database Automatically

  • The CESDBUpdate changes, once applied, cannot be rolled back. Therefore, you should make a backup of your CES database before starting the update process.
  • The CESDBUpdate tool does not require any additional setup, and can be run with the CATStart command (CATStart -run CESDBUpdate. bat in Windows, catstart -run CESDBUpdate.sh in UNIX).
  • Any necessary information is obtained from the environment, or through interactive input or parameters. Some of the information obtained interactively may include:
    • Valid database vendor: (ORACLE or DB2)
    • Valid database name: (generally, ORACLE_SID in ORACLE, database name in DB2)
    • Valid database host: (machine on which the database is running)
    • Valid database port: (In ORACLE this is the listener port. In DB2 this is the instance port)
    • Password for the cisdba: (The tool connects to the database as the cisdba user, so the password is necessary.)
    • Valid database service name: (The value for this can be found in <CATInstallPath>/resources/sdm/exploreJS/admin/configs/dbload.cfg)
    • Valid application server home directory: (Only IBM WebSphere Application Server 6.x is supported.)
  • The list of scripts and the order of execution for update are stored in the CESDBUpdate.xml file in <OS_a>/resources/sdm/sdmdb/dbUpdate. CESDBUpdate actually refers to this file for verification and execution of the scripts.
  • Creation or modification of forms or configurations are customization activities, performed at the customer site.
  • During the update process, you have the option of updating the current database level to any other available level.
  • You will be prompted to select the desired level before executing the update operation.
  • The CESDBUpdate tool cannot determine changes made as part of customization done during or after installation. Therefore, many customization changes must be handled manually. In addition, it cannot provide information on conflicts between customization changes and out-of-the-box changes.
  • Depending on the amount and complexity of the customization performed, the CESDBUpdate process may make the update process much easier. The amount of customization that must be handled manually will be minimized.
  • The CESDBUpdate tool can carry over all customization, including data, that does not conflict with out-of-the-box changes.  Therefore, those customizations will still exist following the update process.
  • If the CES product has been extensively customized, then the automatic CES database update will not be practical. Manual intervention will be required.

How to Update the CES Database Automatically

This task explains how to update the CES database automatically:

  1. The CESDBUpdate tool is run from the command line.

    In Windows: CATStart -run CESDBUpdate.bat -env ENOVIA_CES.V5R18 -direnv /sdm/data/applications/CES_Indus/LCANav_Patch/R18REL

    In UNIX: catstart -run CESDBUpdate.sh -env ENOVIA_CES.V5R18 -direnv /sdm/data/applications/CES_Indus/LCANav_Patch/R18REL
     

  2. During the update process you will be prompted for various pieces of information.

  3. The following is an example of running the script and entering the necessary information, when prompted:

  4. Once you have entered the necessary information, the update process begins. The following is an example of the display that may occur during the update process.

  5. Once the update process has finished, the following is output:

  6. You can also find details of the update in the CES_RELEASE_INFO table.

  7. If you happen to run the CESDBUpdate tool after the database has already been updated, you may see something like:

  8. If you happen to enter the wrong password, you may see something like this: