Automic Workload Automation Pre-Upgrade Review Call Questions
search cancel

Automic Workload Automation Pre-Upgrade Review Call Questions

book

Article ID: 222239

calendar_today

Updated On:

Products

CA Automic One Automation CA Automic Workload Automation - Automation Engine

Issue/Introduction

Here is a list of best practice questions to answer in an upgrade plan that Support can review with you.  A couple weeks ahead of an upgrade, please open a case with Support.  You'll be asked for an upgrade plan and this article can be used as a basis for your upgrade plan.  This is based on upgrade plans Support has seen in the past that have the most success.  An upgrade plan is typically a couple of pages long, but sometimes can be detailed down to the smallest detail so that nothing is missed and Support knows what's happening if something goes wrong and troubleshooting is needed.

Please read the upgrade documentation while planning your upgrade as it extensively covers planning for and upgrading.

If upgrading to 21.0 (or 24.x from 12.3 or earlier), one of the largest changes is the implementation of TLS/SSL.  Read an overview of implementation of this here: TLS/SSL Considerations for Automic Automation
If upgrading to 24.X, one of the largest changes is the requirement for the database to be UTF-8.  Read an overview of implementation here: Unicode Considerations for Automic Automation

Please take advantage of our Broadcom Enterprise Software Academy courses that are made available to our customers at no additional cost:

Automic Automation: Upgrading to Version 21

This course helps Automic Automation administrators plan, prepare and execute the upgrade process of their systems. It also describes the steps that are necessary to manually execute the upgrade of all Automic Automation components from 12.3 to version 21.
At the end of this course you will be able to:

  • Define a strategy for the upgrade
  • Prepare thoroughly for the upgrade
  • Execute the upgrade minimizing downtime and avoiding errors
  • At the end of each module, this course provides a checklist of the tasks involved in the process that has been described. You can copy and paste these checklists elsewhere.

Course title: Automic Automation: Upgrading to Version 21

 

Additional titles on BROADCOM'S ENTERPRISE SOFTWARE ACADEMY for v21 PREPARATION

Course title: Automic Automation TLS and Certificates

Course title: Automic Automation Kubernetes Edition (AAKE)

Plus many more including administration guides.

 

Automic Automation: Upgrading to Version 24

The following playlist will help with planning the upgrade to version 24.  This assumes you are already on version 21.0: Automic Automation: Upgrading to Version 24

This playlist will help with understanding 24 as a whole.  It includes three videos on Universal Language Support which is very important as it include a migration in most cases:  Automation Automation Version 24: Overview

Resolution

Table of Contents

Pre-work:

Testing

    • Did you test this in non-production first?
    • Is production the exact same as non-production?  If not, what is difference between the two?
    • Did you run into problems with the non-prod upgrade?  If so, what sorts of problems did you run into?  The workarounds/solutions should be noted.

Backup plan

    • What will you be backing up prior to upgrade?
    • When will you take the backup?

Backout/rollback plan

    • When will you make the decision to back out in case something goes wrong?
    • What steps will be taken to back out of the upgrade?
    • Do you have a workaround in the meantime?


Timeline should include

  • When does the installation or upgrade begin (date and time)?
  • What date/time will you stop components that need to be stopped?
  • For each component:
    • What date/time will do you plan on updating each component?  
    • How long will these take?  
    • When do you expect to be finished with each component?  
    • How long will testing take to be sure it upgraded correctly?
  • When will you make the decision to back out in case something goes wrong?
  • When do you plan on having the upgrade end (date and time)?

Technical

Sizing Requirements

Compatibility

    • Have you checked for incompatibilities between the version you are upgrading from and to?
    • Have you checked the compatibility matrix to be sure all components include the database are compatible with the version you're upgrading to?

TLS/SSL

Components

    • What components are being upgraded?
      • Core components
        • AE
        • Utilities
        • Initialdata
        • AWI
          • If you are upgrading AWI, are you using tomcat or the provided Jetty AWI bundle?  Note that these have different steps for upgrading
        • ServiceManager
        • Service Manager Dialog
        • Are you using the Zero Downtime Upgrade or a manual upgrade?  
          • Please note - do not use ZDU from version 12.2.6 or lower as there are a lot of known issues
          • WARNING: If using ZDU to 21.0, you must have a target version of 21.0.5 HF2 or higher.  More information can be found here and here.
          • ZDU is not possible when upgrading to 24.X from 21.0 or earlier.
      • Agents
        • (which type of agents - OS, RA, etc...)
        • Are you upgrading agents?  From what version/service pack to what version/service pack?
          • Are you using the centralized agent upgrade?  Or manual upgrade?
          • Has each type of agent upgrade been tested?
      • other
        • Are there any 3rd party components being upgrade?  Examples:
          • Java (from, to versions?)
          • Database (from, to type and versions?)
          • OS patches (from, to flavor and versions?)
          • OS in general (from, to flavor and versions?)
    • What steps/commands are you using to upgrade each component?
    • Are you copying a database?  
      • If so, is there enough space on the target server?
    • Is this an upgrade of a current system?  
    • Are you migrating data from one system to another?
    • Is there any pre-work to be done on the system before stopping to upgrade?  (for example are you stopping clients or queues?)
    • In what order will you be stopping running components?
    • In what order will you be starting components back up?
      • What commands will you use to start them up?
      • What user and environment settings are normally used to bring up the processes?  What will be used during and after the upgrade?

Version 21.0 "musts"

Are you updating to version 21.0?  If so, please note the below:

    • Familiarize yourself with "What's New in 21.0" as there are many "gotchas" listed here or explanations of new/changed behavior
      • IMPORTANT: The Java UI was desupported after version 12.1 but still worked in a limited capacity.  With 21.0, it will no longer work at all and the AWI MUST be used.
    • Any component upgraded to 21.x MUST use the ini file for that version; the old ini file will not work - there is no automatic update of ini files from 12.x to 21.x
      • If you have no_archive_check=1 in your ucybdbre.ini file and ucybdbun.ini file, please be sure to set these - some customers have not and it could lead to larger RT tables
    • As a best practice, upgrade java to the latest build - there are some problems with older builds and certificates (specifically with Java 11, be on 11.0.14 or later).
    • 21.0 Java agents (DB_Service, RA agents, PeopleSoft, SAP, etc...) may require two steps for TLS - the cacerts must have the certificate imported; trustedCertFolder= setting must be updated
    • Analytics must also be updated at the same time as the core components
    • If you are upgrading 12.x to 21.0 and use servicemanager to start components, you must create a new entry for the JCP.  The 12.x entry with the flag -rest will start the REST component; -cp is needed for the 21.0 JCP
    • Plugin Manager (Packs section in the Administration perspective) is no longer needed in 21.0; it is automatically included
    • AWI and TLS-enabled Agents (most 21.0 agents) must point to the WS.PORT and not the CP.PORTS entries
    • Non-TLS-enabled Agents (some 21.0 agents and all 12.x components) must point to the CP.PORTS and not the WS.PORT entries
    • Always try to upgrade to the latest servicepack and hotfix - we are constantly improving the software and a lot of high urgency/impact issues are fixed in the latest
    • Agent versions that are out of support are not supported with 21.0
    • If you are using RA Agents, such as Webservice REST/SOAP and others, make sure to perform prior or post upgrade an import of the RA Solution to a Compatible version as the AWI ECC Plugin of some of these old RA Agents versions are no longer compatible (ie. for Webservice SOAP/Rest you need to be on version 4.6.x or superior).
    • If using the 12.3 Application Interface against the 21.0 system, the 12.3.9 Application interface must be used
    • Version 21.0 DB_SERVICE agent no longer uses the ucsrv.ini file and will throw errors if attempted to be started using the same start command as 12.3
    • 21.0 Agents will only attempt to connect once if a JCP is unavailable on startup of the agent.  This is a change in behavior compared to 12.x
    • If using the JCP.PORTS setting in the ucsrv.ini file, you will need at least one port per JCP and REST process running on that node.  For example, if running just one JCP and one REST process on that server, you would need at least two ports defined like JCP.PORTS=2317-2318

Version 24.X "musts"

Are you updating to version 24?  If so, please note the below:

    • Version 24 requires that a database migration to a UTF-8 database happen if not already used
    • If using SQL Server as the backend database, you must turn on the Windows OS Beta setting on any server where ODBC is used (AE and Utility servers)
      • There may be unforeseen problems using the Beta setting on a server with 21.0 processes, so servers should be split.
      • A 21.0 Database can still be on the same server as a 24.x database.  Only the ODBC connections require this setting

If something goes wrong

  • What is an acceptable situation/workaround if something does go wrong?  How long can it stay like that?
  • What is your backout plan for each component?
  • Who from your team needs to be available for troubleshooting?
  • Do you have the support number to call in case something goes wrong?  Severity 1 cases cannot be raised from the website.  Use a new case when running into a new issue.
Powered by Wolken Software