Upgrading an AE System from Version 12.1 to Version 12.3

As a system administrator, you upgrade your existing Automation Engine system to the latest version.

Important!

This page includes the following:

Prerequisites

  1. Checking for Incompatibilities between Version 12.2 and 12.3

  2. Checking for Incompatibilities between Version 12.1 and 12.2

  3. Preparing for the Upgrade

Installation Steps

Shutting Down the System » Duplicating the Environment » Upgrading the Utility Binaries » Upgrading the AE Database » Upgrading the Remaining Binaries » Starting Up the System » Upgrading the Remaining Components

The installation steps affect the following components:

Communication processes (CPs) are used to connect certain components (such as agents and user interfaces) with the work processes (WPs) and to handle their communication.

JWP stands for Java-based work process and JCP for Java-based communication process.

Shutting Down the System

  1. Stop all clients.

    Stop all clients when your are about to upgrade. This is easily done in the system control of client 0000.

    For more information, see Starting and Stopping Clients by using the Application Interface.

  2. Stop the AE Server Processes.

    Note: If you work in a distributed server environment, all server processes on all participating computers are deactivated. Also pay attention to programs such as Watchdogs, cluster monitoring etc. before ending the server processes. They might raise an alarm or restart the Automation Engine.

    You can stop the server processes using the context menu command Shutdown (AE system) :SHUTDOWN.

  3. Stop the Service Manager.

    • Windows: UCYBSMCL[.EXE] -c STOP_PROCESS -h computer name -n phrase -s name of the service [-m stop mode] [-p password].

    • Unix: ucybsmcl -c STOP_PROCESS -h computer name:port number -n phrase -s name of the service [-m password] [-p password].

Duplicating the Environment

  1. Duplicate the utility binaries (Utilities/Bin).

  2. Duplicate the AE database.

  3. As already described in the section on preparations, creating a database copy provides many advantages. Duplicate it now if you have opted for this step but have not yet executed it. If a database duplicate was already made at an earlier point in time, check if this duplicate must be upgraded.

Upgrading the Utility Binaries

Always use a separate directory in order to avoid mixing files of the different Automation Engine versions. Depending on the computer, you will either install one or several components.

  1. First create a folder whose name represents the Automation Engine version. Then create an individual sub-folder for each component.

  2. Install the utilities, see Installing the Utilities - UNIX or Installing the Utilities - Windows.

  3. Copy the DB folder from the downloaded package to the directory of the utilities. It includes the files for loading the AE database. The DB folder must be a parallel folder of the utilities' BIN directory.

Upgrading the AE Database

Notes:

To Upgrade the Database with AE DB Load Utility

  1. Change the database scheme and loading new initial data to the database.
  2. Select the authentication method

    On the admin computer, the AE.DB Load utility displays a dialog in which you must select an authentication method.

    This dialog is only displayed if the database is upgraded to a new Automation Engine version.

  3. (Optional) Install partitioning with ILM

    On the admin computer, a dialog opens in which you can select the settings for partitioning with ILM. For more information, see ILM - Information Lifecycle Management.

    Important! You cannot undo an AE database partitioning process.

Upgrading the Remaining Binaries

  1. Upgrade AE and ServiceManager.

    1. Install the Automation Engine to a new directory, see Installing the AE - UNIX or Installing the AE - Windows.
    2. Install the new ServiceManager version. Use a new name for the ServiceManager environment (phrase).
  2. Copy the Documentation folder to the new directory.

  3. Upgrade the Automic Web Interface.

    Upgrading an existing installation to the new release upgrades the AWI framework and all its plug‑ins at the same time. Use the same steps to install hot fix packages between releases.

    1. Stop the Apache Tomcat Service.

      1. Open your Windows Services manager.

      2. Stop the Apache Tomcat service.

    2. Back up current files.

      These steps are optional. You can make a safety copy of your entire AWI installation, or just the configuration files. Although, you can use very little of the previous configurations in the new version, you might find it helpful to have a copy for later reference when you configure the upgrade.

      • To backup your whole AWI installation, go to your Tomcat installation, open the webapps folder and make a backup copy of the entire awi folder.

      • To backup only the configuration files, go to the folder where you have the current AWI version installed, and make a backup copy of the folder webapps/awi/config.

    3. Upgrade the application server.

      Important: AWI runs only on Tomcat. If you want to use another application server for the Automic Web Interface, see Installing the Automic Web Interface.

      Before upgrading the application server, check the Automic Compatibility Matrix to see which version is compatible with AWI.

      You will find the upgrade instructions and other relevant information on the homepage of your application server provider. For more information, see Compatibility Information.

    4. Restart the application server.

      You will find the relevant information on the homepage of your application server provider.

    5. Deploy the new AWI version (WAR file) on your application server.

      If you are using Tomcat, copy the awi.war file to the webapps folder of the Tomcat installation. If the Tomcat is running, the awi.war file will be deployed automatically, creating a folder with the same name.

      Important! Deleting the awi.war file removes the corresponding subfolder, which also undeploys the AWI.

      If you are using WebSphere or WebLogic, please refer to their official documentation for more information.

      If you use WebSphere 8.5.5.x, make sure to delete the following files from the AWI folder before deploying the WAR file:

      • WEB-INF/lib/jaxb-api-2.2.11.jar

      • WEB-INF/lib/jaxb-core-2.2.11.jar

      • WEB-INF/lib/jaxb-impl-2.2.11.jar

    6. Configure the new AWI version.

      For more information on how to configure your upgraded AWI, see Configuring Automic Web Interface.

      If you made a backup before you started the upgrade, then you can retrieve the following files and settings from the backup files from the previous webapps/<ECC>/config folder to the new webapps/<AWI>/config folder:

      • uc4config.xml:

        You can replace the new file with your backup.

        If you have more than one AE system connection defined, you can allow your users to choose their connection at login, or you can specify any of the defined connections as the only valid connection. You defined this in the automationengine.index setting of the configuration.properties file.

        Previously, users could not choose a connection and you had to be sure that your one valid connection was defined first in uc4config.xml.

      • configuration.properties:

        Important: Do not replace the file in your new installation with your backup. Instead, define the file as described in this guide. However, you can refer to your backup files for the following two parameters, which may have optionally been defined in your AWI environment:

        • defaultHomeDashboard (This would be the dashboard attribute in the navigation.xml file.)

        • customHomeDashboardsFolder (This would be from the previous configuration.properties file.)

      • logback.xml:

        Do not restore your backed up version.

        However, if you changed the default setting for the severity level of event messages (DEBUG) for the root element, then you might want to make the same change for AWI.

      • Theme folder:

        If you had customized the color or banner logo in your previous environment, then copy the contents of your backed up webapps/awi/config/theme folder to the folder of the same name in your current AWI version.

        For more information, see colors.properties.

  4. Configure and Start the Java Work Process (JWP).

    Notes:

    • As of version 12.0, the JWP installation is mandatory.
    • As of version 12.1, it is mandatory to use and enable the JDBC section in the UCSRV.INI file.

    The JWP is provided in the same directory as all the other Automation Engine files. The directory /configuration/ is created automatically when the JWP is first started and contains the OSGI bundle's cache.

    Unpacking the files

    In Windows, the JWP files are automatically copied from the SETUP.EXE program to the BIN directory. In UNIX, the files are located in the respective TAR archive.

    Copy the provided "plugin" and "lib" directories into the BIN directory of the Automation Engine.

    Important! If the bin directory for this installation already has a "plugin" and/or "lib" directory make sure to delete them before copying the new ones.

    The subsequent installation steps depend on the database type used.

    Java Cryptography Extension (JCE) (Optional - Only for SSO with Kerberos)

    Important! JDK requires these policy files only if you work with Java 8. Java 9 and later versions include and use these files by default.

    1. Install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy.

      The JCE Unlimited Strength Jurisdiction Policy has to be installed on the machines where:

      • The Automic Web Interface runs.
      • The Automation Engine (JWP) runs.

      Download at Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy

      For IBM Java, you must use the policy files of IBM. The unlimited jurisdiction policy files are located in directory SDK /demo/jce/policy-files/unrestricted/. For more information, see https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.1.0/com.ibm.java.security.component.71.doc/security-component/sdkpolicyfiles.html.

      The Readme file contains the installation instructions on how to copy the .jar files to appropriate location (e.g. <java-home>\lib\security). If there are multiple Java installations on the same computer, setting up a policy file for all installations is recommended.

    MS SQL Server

    1. Install JDBC driver.

      1. Download Microsoft JDBC Driver for SQL servers.

      2. Follow the installation instructions on the page (download the .exe file, run it and enter and installation directory).

      3. After installing, copy the .jar file from the appropriate JRE destination folder to the <server>\bin\lib directory of the Automation Engine. Make sure to use the latest JDBC driver available for your Java version.

        Check the Automic Compatibility Matrix to find out which Java versions are supported. For more information, see Compatibility Information.

    2. Activate TCP/IP in the MS SQL server. To do so:

      1. Open the SQL Server Configuration Manager.
      2. Expand SQL Server Network Configuration.
      3. Select Protocols for MSSQLSERVER under SQL Server Network Configuration.
      4. The TCP/IP must be set to Enabled in the right-hand section.
      5. Restart the SQL Server Services.
    3. Determine the MS SQL server port.

      The default port of the MS SQL server port is 1433.

      Note: If you are not sure of the port of your MS SQL server instance, you can find this out from its ERRORLOG file (MSSQL > LOG). One of these messages: "Server is listening on [ 'any'<ipv4> port number]" or "Server is listening on [ 'any'<ipv6> port number]" should be found in the current log file, which contains the port.

    4. Configure the database connection.

      The JWP uses the same INI file (UCSRV.INI, see Automation Engine) as all the other WPs of the Automation Engine system.

      JDBC connection to the database

      Define a separate database connection string for the JWP in the [JDBC] section. You can automatically generate this string by using the following command:

      java -jar ucsrvjp.jar -setup

      The system then verifies that the JDBC driver is available and that the database connection could be established.

      The advantage here is that the connection string of the other WPs ([ODBC] section) does not need to be changed or restarted.

      If you want to use Windows authentication, you must append ;IntegratedSecurity=true to the JDBC connection string in the [JDBC] section of the AE INI file.

      Example

      SQLDRIVERCONNECT=jdbc:sqlserver://localhost:1433;databaseName=AUTOMIC;IntegratedSecurity=true

      Note: When you install the JDBC driver and have to use Windows authentication, you must also copy the sqljdbc_auth.dll file to the BIN directory of the Automation Engine.

      DSN-less ODBC Connection

      This option uses the same database connection string that is also used by all the other WPs in the Automation Engine system. When installing a JWP for an existing system, all WPs must subsequently be restarted.

      A connection string is required in the [ODBC] section of the configuration file, the syntax of which does not require DSN. The server and database name must be specified directly in this case.

      SQLDRIVERCONNECT=ODBCVAR=SNNNNNRN,Driver={SQL Server Native Client VERSION};Server=tcp:SRVNAME,PORT;Database=DBNAME;UID=DBUSER;PWD=DBPWD

      • VERSION- Version of SQL Server Native Client. Is displayed in the SQL Server Configuration Manager.
      • SRVNAME - Name of the database computer.
      • PORT - port of the MS SQL server instance.
      • DBNAME - Database name.
      • DBUSER - Database user.
      • DBPWD - Database password.

      Example

      [ODBC]
      SQLDRIVERCONNECT=ODBCVAR=SNNNNNRN,Driver={SQL Server Native Client 11.0};Server=tcp:dbsrv01,1433;Database=AEV10;UID=user;PWD=password

      The entry should be on one line (no break).

    Oracle

    1. Install JDBC driver.

      1. Copy the JDBC driver ojdbc8.jar from the Oracle database client installation to the lib folder of the JWP.
        The file is located here: ORACLE_HOME/jdbc/lib/ojdbc8.jar.

      2. Copy the xdb6.jar, or xdb.jar, and xmlparserv2.jar files to the lib folder of the JWP to ensure that XML variables are processed correctly.

        The files are either part of the Oracle database or can be downloaded from the Oracle SQL Developer website. They are located here:

        • $SQLDEVELOPER_HOME/modules/oracle.xdk/xmlparserv2.jar

        • $SQLDEVELOPER_HOME/rdbms/jlib/xdb6.jar or $SQLDEVELOPER_HOME/rdbms/jlib/xdb.jar

    2. Configure the database connection

      JDBC connection to the database

      Define a separate database connection string for the JWP in the [JDBC] section. You can automatically generate this string by using the following command:

      java -jar ucsrvjp.jar -setup

      The system then verifies that the JDBC driver is available and that the database connection could be established.

      More information on installing the JDBC driver is available in the Oracle JDBC installation instructions.

    DB2

    1. Install JDBC driver.

      Copy the file db2jcc4.jar (JDBC driver) into the lib directory of the JWP.

      This file is part of the DB2 client and is located in the sub-directory SQLLIB/java.

    2. Configure the database connection

      JDBC connection to the database

      Define a separate database connection string for the JWP in the [JDBC] section. You can automatically generate this string by using the following command:

      java -jar ucsrvjp.jar -setup

      The system then verifies that the JDBC driver is available and that the database connection could be established.

    PostgreSQL

    1. Install the JDBC driver.

      Download the appropriate *.jar file from https://jdbc.postgresql.org/download.html and copy it into the lib directory of the JWP.

    2. Configure the database connection
    3. JDBC connection to the database

      Define a separate database connection string for the JWP in the [JDBC] section. You can automatically generate this string by using the following command:

      java -jar ucsrvjp.jar -setup

      The system then verifies that the JDBC driver is available and that the database connection could be established.

    SSL certificates for LDAP (Optional)

    In order to use SSL, the certificate(s) of the LDAP server must be available to the Java Work Process. The JWP uses the default keystore file cacerts in the lib/security directory of the JRE.

    Keystore file configuration options

    Using an alternative keystore file:

    If you want the JWP(s) to use an alternative keystore file, you have to define the file name and path to a centrally stored file in the JWP_KEYSTORE_PATH key in the UC_SYSTEM_SETTINGS variable. In case the defined path is not accessible or invalid, a log message will be written to the default log location and the JWP will use the default keystore file. For more information, see JWP_KEYSTORE_PATH.

    Creating an individual keystore file using the JWP:

    If you want to use an individual keystore file, you can create it using the following command:

    java -jar ucsrvjp.jar -installcert host:port keystorePath

    In case the defined path in keystorePath does not exist, the JWP creates a new keystore file in that location. You can then define a password for that keystore file.

    Using an alternative password for keystore file access:

    The default password used by the JWP is the default password of the JRE keystore. If you want the JWP to use a different password, you have to define a Login object containing that password by following these steps:

    • Create a Login object (or use an existing one).
    • Use the JWP_KEYSTORE_LOGIN key in the UC_SYSTEM_SETTINGS variable to enter the name of that Login object. For more information, see JWP_KEYSTORE_LOGIN.
    • Open the referenced Login object, select the Login page and add a new row there.
    • In the column Name, select "*", in the column Type select JWP_KEYSTORE.
    • The Login info is optional for this function, but as this column cannot be empty by default, you have to enter something here.
    • Enter the password you chose for the keystore file.

    Adding the certificates

    1. Add certificates using the keytool.

      1. To use the default keystore of the JRE, go to the jre\lib\security folder of the Java installation and import the certificate with the keytool command:
      2. keytool -keystore cacerts -importcert -alias ldapServer -file certficate.cer

      3. To use your own keystore file defined in the UC_SYSTEM_SETTINGS variable using the JWP_KEYSTORE_PATH key, go to the defined path and import the certificate with the keytool command:
      4. keytool -keystore <keystore> -importcert -alias ldapServer -file certficate.cer

        When prompted to trust this certificate respond by typing "Y".

        For more information, see JWP_KEYSTORE_PATH.

    2. Add certificates via download.

      1. Another option to install the certificate is the command line parameter -installcert of the Java Work Process.
      2. java -jar ucsrvjp.jar -installcert <host>:<sslport>

        • This assumes that the Java Work Process has write access to the cacerts file of the Java installation.
        • This command detects the path of cacerts, connects to the specified host and port and tries to create an SSL connection.
      3. This command to add a certificate via download will set an optional parameter for the file name of the keystore:
      4. java -jar ucsrvjp.jar -installcert <host>:<sslport> <keystorePath>

      Notes:

      • When the parameter JWP_KEYSTORE_PATH is valid but the file doesn't exist, JWP creates a new keystore file in the same location. For more information, see JWP_KEYSTORE_PATH.
        During this process the user can define an individual password.

      • If a certificate is missing, the message "unable to find valid certification path to requested target" is printed and the missing certificate is downloaded and stored in the cacerts file.

    Starting the JWP

    Use this kind of command to start the JWP via the command line

    java -Xmx2G -jar ucsrvjp.jar -Iucsrv.ini

    The file ucsrvjp.jar is provided in the same directory as the other Automation Engine files. It is used exclusively to start the JWP.

    The JWP can also be started via ServiceManager.

    java -Xmx2G -jar ucsrvjp.jar -svc%port% -Iucsrv.ini

    The -svc parameter should be omitted when starting directly via the command line.

    The parameter -I to specify the INI file is optional. If the parameter is missing, the JWP attempts to find the file "ucsrv.ini" in the current working directory (= directory in which the file "ucsrvjp.jar" is located).

  5. Configure and Start the Java Communication Process (JCP).

    The files needed for JCP are the same as the files provided for JWP in the same directory as all the other Automation Engine files.

    Since the JWP's installation is mandatory and the files necessary for the JCP are the same as those used to install the JWP, there is no need to unpack any files nor to carry out any other installation step.

    Notes:

    • The JCP installation is relevant for the AE REST API as well as for the advanced object search. Therefore, make sure to configure the REST section of the Automation Engine configuration file (ucsrv.ini) accordingly. Otherwise the Automic Automation object advance search will not work. For more information, see Automation Engine.

    • We recommend using HTTPS.

    HTTPS/SSL set up for AE REST API

    In order to use HTTPS you need to set the sslEnabled parameter to 1 and continue with the setup of the following parameters in the Automation Engine configuration file (ucsrv.ini, see Automation Engine):

    • keystore

      This parameter is mandatory and needs to point to the correct target, otherwise the JCP server will terminate.

    • keystorePassword

    • keyPassword

      The keystorePassword and the keyPassword can be encrypted with the UCYBCRYP Utility.

    Adding the certificates

    JCP uses keystore as defined in the Automation Engine configuration file. For additional information as well as information on adding certificates, see https://www.eclipse.org/jetty/documentation/jetty-9/index.html#configuring-ssl.

    Starting the JCP

    Use this kind of command to start the JCP via the command line:

    java -Xmx2G -jar ucsrvjp.jar -Iucsrv.ini -rest

    The file "ucsrvjp.jar" is provided in the same directory as the other Automation Engine files. It is used exclusively to start the JWP and JCP.

    The JCP can also be started via ServiceManager.

    java -Xmx2G -jar ucsrvjp.jar -Iucsrv.ini -svc%port% -rest

    The -svc parameter should be omitted when starting directly via the command line.

    The parameter -I to specify the INI file is optional. If the parameter is missing, the JCP attempts to find the file "ucsrv.ini" in the current working directory (= directory in which the file "ucsrvjp.jar" is located).

    Setting Up Multiple REST API Processes

    The JCP installation is relevant for the AE REST API and for the advanced object search. You can install a single Java communication process (JCP). In this case, all REST requests are sent to this single AE REST API instance and no REST API is available if the Java communication process (JCP) is down.

    You can also set up a system with multiple Java communication processes (JCPs). In this case, two Java communication processes (JCPs) are used in a cluster but only one of both is available at the time.

    Important! When using multiple Java communication processes (JCPs), it is imperative that each one uses its own Automation Engine configuration file (ucsrv.ini, see Automation Engine). If only one INI file is used for more than one Java communication process (JCP), the first one connects successfully while the others terminated upon trying to register the same REST port if both run on the same node. An error message is written to the log file of the JCP stating the reason for termination.

    Setting up a system with multiple Java communication processes (JCPs) can be convenient for balancing and to provide failover capabilities, because the REST requests are sent and distributed only to available Java communication processes (JCPs).

    For more information, see AE REST API - General Info.

Starting Up the System

  1. Start the ServiceManager, see Start Parameters - ServiceManager.

  2. Start the Server Processes (cold start).

    Cold-start the server processes when all installation and configuration step have successfully been completed. Do so in the INI file of the server processes by setting the parameter StartMode= to COLD. Now the processes can start.

  3. Wait until all Agents are reconnected.

  4. Start the clients (Go).

    All clients can be started from the Administration perspective of client 0000. For more information, see Starting and Stopping Clients by using the Application Interface.

Upgrading the Remaining Components

Now you can install and/or replace the remaining components:

Notes:

Examples

Important!

To ensure that jobs call the new Job Messenger, follow the steps below:

  1. Correct the file name of the Job Messenger in the INI file when you upgrade the agent (variable UC_EX_JOB_MD).

  2. When installing the new agent in the same directory as the old one, you must delete the old Job Messenger after the installation process.

  3. Instead of adjusting the INI file during the upgrading process, you can also create a link that points to the new messenger. Use uppercase letters for the old messenger names. For example, for Linux: ln -s ucxjli3m UCXJLI3M.