Connecting the master domain manager to a new database

Connecting the master domain manager to a new database involves reconfiguring the system to recognize and interact with the new database. This process typically includes updating connection strings, ensuring database drivers are compatible, migrating relevant data, and validating connectivity. This ensures the master domain manager can continue to perform its tasks without interruption, leveraging the new database resources and capabilities.

About this task

This section applies to HCL Workload Automation master domain managers and their backups. It documents how to connect the master domain manager and backup master domain manager to a new database. If your environment contains pools, see Connecting the master domain manager to a new database when using pools.

Note: This cloning procedure does not clone the following information from the source environment:
  • The preproduction plan
  • The history of job runs and job statistics
  • The audit records
  • The state of running event rule instances. This means that any complex event rules, where part of the rule has been satisfied prior to cloning of the environment, are generated as new rules after the cloning procedure. Even if the subsequent conditions of the event rule are satisfied, the record that the first part of the rule was satisfied is no longer available, so the rule will never be completely satisfied.

Follow this procedure to export data from your previous database, import it to a new one, and connect the master domain manager and backup master domain manager to the new database.

Procedure

  1. Install the new database.
  2. Run the configureDb command to create the new database on the new target RDBMS. For more information, see Database configuration - configureDb script.
  3. On the master domain manager, extract all scheduling object definitions and global options from the previous RDBMS running the dataexport command. 
    dataexport source_dir export_dir
    where:
    source_dir
    Is the TWS_HOME directory of HCL Workload Automation.
    export_dir
    Is the directory where the export files are created.
    For example:
    dataexport.cmd F:\IWS1023\twsDBuser F:\IWS1023\export
    For more information, see dataexport.
  4. Verify that the following files were created in export_dir:
    • acls.def
    • calendars.def
    • erules.def
    • folders.def
    • globalOpts.def
    • jobs.def
      Note: The record length supported by DB2® is 4095 bytes, but it decreases to 4000 bytes with Oracle. When you migrate your job definitions to Oracle, any job with task string (scripts or commands) exceeding 4000 bytes in length are not migrated. In this case, the data import utility replaces the job definition with a dummy job definition and sets the job priority to 0, guaranteeing that successors are not run.
    • parms.def
    • prompts.def
    • rcgroups.def
    • resources.def
    • scheds.def
    • sdoms.def
    • srols.def
    • topology.def
    • users.def (includes encrypted user passwords)
    • vartables.def
  5. Run exportserverdata to export dynamic domain manager data from the database. This command is not documented because it is an internal command. The command is located in /opt/HCL/TWA/TDWB/bin/. For the purpose of this procedure, use the following syntax: 
    ./exportserverdata.sh -dbUsr username -dbPwd password 
[-exportFile exportFile]
    where:
    dbUsr
    Is the database user. This parameter is required.
    dbPwd
    Is the database user password. This parameter is required.
    -exportFile
    Is the file name to which the server data is to be exported from the database. This parameter is required if you use a file different from the default server.properties file, located in the same path as the exportserverdata command. If you use a file other than server.properties, specify the name and path of the file.
  6. Stop WebSphere Application Server Liberty on the master domain manager and backup master domain manager.
  7. Reconfigure the master domain manager and backup master domain manager by performing the following changes:
    1. Edit the WebSphere Application Server Liberty datasource.xml file, so that it points to the new RDBMS. For more information, see Changing the properties for the database.
    2. In the TWA_DATA_DIR/usr/servers/engineServer/resources/properties/TWSConfig.properties file, uncomment the com.ibm.tws.dao.rdbms.rdbmsName line and specify the name of your RDBMS. For more information, see Changing the properties for the database.
    3. In the TWA_DATA_DIR/broker/config/DAOCommon.properties file, change the com.ibm.tdwb.dao.rdbms.rdbmsName line to specify the name of your RDBMS.
    4. In the TWA_DATA_DIR/broker/config/CLIConfig.properties file, change the following strings:
      com.ibm.tdwb.dao.rdbms.rdbmsName
      to specify the name of your RDBMS.
      com.ibm.tdwb.dao.rdbms.jdbcPath
      to specify the path to your JDBC connection string.
      com.ibm.tdwb.dao.rdbms.jdbcDriver
      to specify the name of the class implementing your JDBC driver.
    5. In the TWA_DATA_DIR/usr/servers/engineServer/jvm.options file, specify the path to the database drivers.
    6. In the TWA_home/TDWB/bin/tdwb_env.sh file, specify the path to the database drivers.
  8. Run addserverdata to add dynamic domain manager data in the database. The command is located in /opt/HCL/TWA/TDWB/bin/. This command is not documented because it is an internal command. For the purpose of this procedure, use the following syntax: 
    ./addserverdata.sh -dbUsr username -dbPwd password 
-importFile importFile {[-MDM true]}
    where:
    dbUsr
    Is the database user. This parameter is required.
    dbPwd
    Is the database user password. This parameter is required.
    -importFile
    Is the file name from which the server data is to be imported into the database. This parameter is required if you use a file different from the default server.properties file, located in the same path as the addserverdata command. If you use a file other than server.properties, specify the name and path of the file.
    MDM
    Specifies whether the workstation where you run the command is the master domain manager. This parameter is required on the master domain manager and is optional on the dynamic domain manager.
  9. Restart WebSphere Application Server Liberty on the master domain manager.
  10. Reload the shell session for the changes to take effect and check that the environment is working correctly by running the following commands: 
    optman ls
composer display cpu=MDM_name
  11. Wait for the dynamic workload broker definition to be created, and subsequently for all dynamic agents to register with the master domain manager.
  12. Run the dataimport command to import data from your previous RBDMS. 
    dataimport.cmd F:\IWS1023\twsDBuser F:\IWS1023\export
    where:
    source_dir
    is the TWS_HOME directory of the source environment instance of HCL Workload Automation, which corresponds to installation_dir/TWS.
    export_dir
    is the directory where you copied the object definitions and the global options retrieved from the source environment.
    For more information, see dataimport.
  13. Run the following command to align the plan with the information inserted in the database: 
    Jnextplan -for 0000 -noremove
  14. Run the following command to extend the plan by 24 hours: 
    JnextPlan -to startOfDay tz your_timezone -noremove
    For more information about Jnextplan, see JnextPlan.
    The master domain manager and backup master domain manager are now configured to connect to the new database and your environment is up and running.

    If you need to connect the Dynamic Workload Console to a new database, see Connecting the Dynamic Workload Console to a new node or database.