← Upgrading Redwood PlatformUninstalling Redwood Server →

on-site-related topic Migrating Redwood Platform

Before you start the migration of the central Redwood Server system, you have to complete the following steps:

Prerequisites

  • Privileges on the new central Redwood server to unzip the redwood-platform.zip and mount or copy the DataRootDirectory from the old central Redwood server.
    • If you are using the same OS family (Windows, UNIX) it is recommended to keep the same path on the source and target servers.
    • If you are migrating from Windows to UNIX (or vice-versa) or cannot keep the same path on the target server, you will have to update table jcs_jobfile1 to point to the new path - this has to be done in the native database tooling, for example, sqlplus for Oracle.
  • New central Redwood server must be a supported platform with a supported JVM installed.
  • The redwood-platform.zip version 9.2.10 must be readily available on the new central Redwood server. If you are migrating from an older version, it is not recommended to update the schema in the old database directly as you might need to abort or postpone the migration, for example, if problems are detected that cannot be addressed immediately.
    • If you are migrating from version 9.1.5 or higher, the admin server version 9.2.10 will be able to update the schema.
    • If you are migrating from version 9.0.22 up until 9.1.4, you will need a redwood-platform.zip for version 9.1.5 as well as the one for version 9.2.10. Note that 9.1.5 requires Java 8, so that also needs to be available in the new server.
    • If you are migrating from a version lower than 9.0.22, for example 9.0.21, you will need redwood-platform.zip for versions 9.0.22, 9.1.5, and 9.2.10. Note that 9.0.22 requires Java 8, so that also needs to be available in the new server.
  • Network connectivity from the new central Redwood server to the new database server (database port) and all platform agents (platform agent port) must work; if platform agents and/or the database server use TLS, the certificate(s) must be trusted by the JVM.
  • If you wish to migrate the database using the admin server, the new server must be able to connect to the source database to migrate.

Workflow

Please read the workflow in full and ensure that you know exactly what is expected of you. Ensure you have the required technical parties (System Administration, DBA, Redwood Support) at your disposal prior to starting the procedure to keep downtime at a minimum.

  1. Prepare the installation files on the new server. See Preparing the Installation Files. Ensure you have a supported JVM installed on the target central Redwood server. Specify any required environment variables/system properties, copy the <install_dir>/j2ee/cluster/server1/bin/setvars.{sh,bat} and <install_dir>/j2ee/cluster/adminserver1/bin/setvars.{sh,bat} files from the old system to the new system and adapt them to the target system, if required. If you are migrating from one OS family to another (Windows to UNIX or vice-versa), you have have to create a platform-specific setvars file (setvars.sh or setvars.bat) with all required settings. When you migrate from an older version, this must be done for all <install_dir>/j2ee/cluster/adminserver1/bin/setvars.{sh,bat} files from the redwood-platform.zip files you need for the migration, note that if you migrate from version 9.1.5 or lower, you will need a JAVA 8 JVM; see Prerequisites.
  2. Stop the old central server and perform a backup of the database. If the hostname of the central server is to change, ensure Redwood is made aware of the timing of your migration plans, deactivate the license prior to stopping the server and provide Redwood with the deactivation key. Redwood will provide you with a new license upon request.
  3. Prepare the database, see Database Prerequisites if you are switching database servers and perform either of the following:
    1. If your old server is on SAP NetWeaver, see SAP NetWeaver to Redwood Platform Migration.
    2. If you are going to use the same database on the same database server, simply copy the XML file in <install_dir>/j2ee/cluster/server1/conf/Catalina/localhost/redwood.xml from the old server to the new server.
    3. If you are switching database servers, see DB2, SQL Server, Oracle, PostgreSQL.
  4. Drop obsolete privilege grants, see (#).
  5. You copy or mount the DataRootDirectory on the new host if it was a network drive or SAN.
  6. If the DataRootDirectory path was changed (mount point, drive letter), which is not recommended, update table jcs_jobfile1 to point to the new location. See Updating the jcs_jobfile1 table.
  7. If the central server hostname has changed:
    1. If your platform agents were locked to the old server, update the address_acl configuration file on each of them with the new URL or rename it.
  8. Start the central Redwood server, install the license if you changed the central Redwood server's hostname.
  9. If you changed the path of the DataRootDirectory, submit System_SetSystemDataRootDirectory as soon as possible to update the DataRootDirectory for System process server.

SAP NetWeaver to Redwood Platform Migration

SAP Hana or Sybase

If you have SAP HANA or Sybase ASE as underlying database, follow this procedure:

  1. If you are upgrading from a version lower than 9.2.10, you copy the database to a temporary database accessible by the admin server and follow Upgrading the Database Schema.
  2. Retrieve the JDBC database driver for your database and connect to the database. See SAP Hana for instructions for SAP HANA, the same applies for Sybase, you have to get the Sybase JDBC dirver instead of the SAP HANA driver, note that in the case of a migration, you will not install the database as it is already there. If you are asked to upgrade the database schema, ensure you have a backup of the database and do so.
  3. Proceed to the Migrating the Database with the Admin Server section below.

DB2, SQL Server, Oracle, PostgreSQL

  1. You have the choice between migrating the database using db-specific tooling, faster but requires that both source and target databases are of the same flavor (for example both are DB2), and using the admin server which is slower and requires a connection from the new server to the old database; the admin server is database flavor independent.
  2. If you are using database-specific tooling, ask your DBA to copy the schema containing the jcs_ tables to the new database server and proceed to Migrating the Central Redwood Server.
  3. If you are not using database-specific tooling, start the admin server and connect to the source database to migrate, if you need to upgrade the database schema, ensure you have a backup of the database and do so.
  4. Proceed to the Migrating the Database with the Admin Server section below.

Migrating the Database with the Admin Server

  1. Start the admin server version 9.2.10 if it is not already running, connect to the source database.
  2. Go to DB Tools > Export and fill jcs.* into the Pattern field and an existing output directory on the central Redwood server in the Output Directory field, for example../temp. Note that, depending on the size of the database, this can take a considerable amount of time and use significant disk space.
  3. Use your browser to navigate to https://<server>:10185/scheduler-admin/login/logout.jsp to log out of the source database.
  4. Log in to the target database, install the database if instructed to do so.
  5. Navigate to DB Tools > Clear and fill.* into the Pattern field to truncate the database tables before the import.
  6. Navigate to DB Tools > Import and fill the path to the directory where the export was performed, for example,../temp. Depending on the size of the exported database, this can take a significant amount of time.
  7. Use your browser to navigate to https://<server>:10185/scheduler-admin/login/logout.jsp to log out of the target database.
  8. If you have not mounted/copied the DataRootDirectory to the same path, see Updating the jcs_jobfile1 table.
  9. You may now stop the admin server and start the central Redwood server (server1).

Migrating the Central Redwood Server

If you used database-specific tooling to migrate the database, you still have to ensure the database is up-to-date.

  1. Start the admin server and connect to the database, upgrade the database schema if required.
  2. Ensure you have either mounted/copied the DataRootDirectory to the same path or update the jcs_jobfile1, see Updating the jcs_jobfile1 table.
  3. Stop the admin server and start the central Redwood server (server1).

Upgrading the Database Schema

Since the database schema is not up-to-date and as a good practice you do not alter a source system when you migrate, you copy the database to a temporary database and update that, if the source and target database flavors (for example Oracle) are the same, the temporary database can be the target database for the migration.

  1. Use native database tooling to make a copy of the source database into the temporary database.
  2. If you are migrating from version 9.0.21 or lower, start the admin server version 9.0.22, connect it to the temporary database, choose Connect and Install/Update.
    1. Wait for the schema evaluation to complete, choose Upgrade, wait for the upgrade to complete.
    2. Stop the admin server.
    3. You now have 9.0.22, proceed to instructions for 9.1.4 or lower.
  3. If you are migrating from version 9.1.4, start the admin server version 9.1.5, connect it to the temporary database, choose Connect and Install/Update.
    1. Wait for the schema evaluation to complete, choose Upgrade, wait for the upgrade to complete.
    2. Stop the admin server.
  4. Start the admin server version 9.2.10, connect it to the temporary database, choose Connect and Install/Update.
    1. Wait for the schema evaluation to complete, choose Upgrade, wait for the upgrade to complete.
    2. Stop the admin server.
  5. Database schema upgrade is complete.

Removing Obsolete Grants

The following error was reported during upgrades:

FATAL 2023-06-16 11:36:35.661 EDT [Redwood Background Startup] - com.redwood.scheduler.lifecycle.impl.DefaultComponentLifecycleManager - Not all components started successfully; stopping what was started.
java.lang.IllegalArgumentException: Unknown concrete object type: JDEdwardsSystem
at com.redwood.scheduler.model.security.ModelSecurityAttributes.getSecurityAttributes(ModelSecurityAttributes.java:884) ~[api-impl.jar:?]
at com.redwood.scheduler.model.method.impl.ObjectDefinitionMethodImpl.getSecurityAttributesInt(ObjectDefinitionMethodImpl.java:95) ~[api-impl.jar:?]
at com.redwood.scheduler.model.ObjectDefinitionImpl.getSecurityAttributes(ObjectDefinitionImpl.java:1068) ~[api-impl.jar:?]
at com.redwood.scheduler.model.method.impl.SubjectPrivilegeGrantMethodImpl.getSecurityAttributes(SubjectPrivilegeGrantMethodImpl.java:364) ~[api-impl.jar:?]
at com.redwood.scheduler.model.method.impl.SubjectObjectTypePrivilegeGrantMethodImpl.getAllPrivilegesInt(SubjectObjectTypePrivilegeGrantMethodImpl.java:181) ~[api-impl.jar:?]
at com.redwood.scheduler.model.SubjectPrivilegeGrantImpl.getAllPrivileges(SubjectPrivilegeGrantImpl.java:700) ~[api-impl.jar:?]
at com.redwood.scheduler.model.SchedulerSessionFactoryImpl.generateNormalUserContext(SchedulerSessionFactoryImpl.java:599) ~[api-impl.jar:?]
at com.redwood.scheduler.model.SchedulerSessionFactoryImpl.createUserContext(SchedulerSessionFactoryImpl.java:503) ~[api-impl.jar:?]
at com.redwood.scheduler.model.SchedulerSessionFactoryImpl.getOrCreateUserContext(SchedulerSessionFactoryImpl.java:444) ~[api-impl.jar:?]
at com.redwood.scheduler.model.SchedulerSessionFactoryImpl.getSchedulerSession(SchedulerSessionFactoryImpl.java:367) ~[api-impl.jar:?]
at com.redwood.scheduler.model.SchedulerSessionFactoryImpl.getSchedulerSession(SchedulerSessionFactoryImpl.java:635) ~[api-impl.jar:?]
at com.redwood.scheduler.model.imprt.CronacleArchiveReader.scanArchive(CronacleArchiveReader.java:153) ~[export.jar:?]
at com.redwood.scheduler.model.imprt.CronacleArchiveReader.importAll(CronacleArchiveReader.java:132) ~[export.jar:?]
at com.redwood.scheduler.model.imprt.CronacleArchiveReader.importAll(CronacleArchiveReader.java:118) ~[export.jar:?]
at com.redwood.scheduler.db.epoch.continuous.ContinuousSAPInitializersCode.createSpoolRetrievalJobDefinition(ContinuousSAPInitializersCode.java:100) ~[db-init.jar:?]
at com.redwood.scheduler.db.epoch.continuous.ContinuousInitializer.execute(ContinuousInitializer.java:106) ~[db-init.jar:?]
at com.redwood.scheduler.db.epoch.continuous.ContinuousInitializers.initialize(ContinuousInitializers.java:149) ~[db-init.jar:?]
at com.redwood.scheduler.db.epoch.continuous.ContinuousInitializer.performInitialization(ContinuousInitializer.java:82) ~[db-init.jar:?]
at com.redwood.scheduler.db.epoch.BaseInitializer.initializeDatabase(BaseInitializer.java:79) ~[db-init.jar:?]
at com.redwood.scheduler.db.DatabaseInitializer$InitializerUnitOfWork.performWork(DatabaseInitializer.java:189) ~[db-init.jar:?]
at com.redwood.scheduler.db.DatabaseInitializer.initializeEpochs(DatabaseInitializer.java:1155) ~[db-init.jar:?]
at com.redwood.scheduler.db.DatabaseInitializer.initializeDatabase(DatabaseInitializer.java:737) ~[db-init.jar:?]
at com.redwood.scheduler.db.DatabaseInitializer.start(DatabaseInitializer.java:261) ~[db-init.jar:?]
at com.redwood.scheduler.lifecycle.impl.StartComponentVisitor.visit(StartComponentVisitor.java:34) ~[cl-impl.jar:?]
at com.redwood.scheduler.lifecycle.impl.DefaultComponentLifecycleManager.visitAllComponents(DefaultComponentLifecycleManager.java:109) ~[cl-impl.jar:?]
at com.redwood.scheduler.lifecycle.impl.DefaultComponentLifecycleManager.startComponents(DefaultComponentLifecycleManager.java:214) ~[cl-impl.jar:?]
at com.redwood.scheduler.lifecycle.impl.DefaultComponentLifecycleManager.startComponents(DefaultComponentLifecycleManager.java:177) ~[cl-impl.jar:?]
at com.redwood.scheduler.lifecycle.impl.DefaultStartup.start(DefaultStartup.java:180) ~[cl-impl.jar:?]
at com.redwood.scheduler.lifecycle.impl.DefaultStartup.lambda$0(DefaultStartup.java:158) ~[cl-impl.jar:?]
at java.lang.Thread.run(Thread.java:829) [?:?]

Example error stack for JDEdwardsSystem, the error stack can also mention DynamicsAxSystem, GMQuery, GMQueryRepository, or GMRepository, instead.

Before you upgrade to 9.0.22, you have to remove obsolete grants; use the following SQL. You adapt the code with the database name and store it in a file on the central server, you use the admin-server Database Tooling (DB Tools > Execute SQL) to execute the file. You either provide the full path to the file or store it in <install_directory>/j2ee/cluster/adminserver1 and specify./<file_name> in the SQL File field; choose Execute.

DELETE FROM JCS_TYPPRIVGRANT0
WHERE JCS_TYPPRIVGRANT0.F_OBJECTTYPE IN
(select JCS_OBJDEF0.A_UNIQUEID
  from JCS_OBJDEF0
  where JCS_OBJDEF0.A_OBJECTNAME
    in ('DynamicsAxSystem', 'JDEdwardsSystem', 'GMQuery', 'GMQueryRepository', 'GMRepository'));

SQL query to delete obsolete grants, if any exist.

Updating the jcs_jobfile1 table

Although it is recommended to always have the same path to DataRootDirectory, it can happen that this is not an option, for example, when you switch OS family from UNIX to Windows, for example. When you need to change the path to DataRootDirectory, ensure the database is upgraded. You can either use a native database client to run the SQL query or create an SQL file and use the admin server.

If a native database client is not available, you can use the admin server to update the jcs_jobfile1 table.

  1. Create a file with the below SQL, depending on your database flavor and copy it to the server hosting the admin server.
  2. Use the admin server to connect to the target database if you are not already connected.
  3. Navigate to DB Tools > Execute SQL, specify the full path to the SQL file in the SQL File field and choose Execute.
  4. Use your browser to navigate to https://<server>:10185/scheduler-admin/login/logout.jsp to log out of the target database.

SQL Server

use <database_name>
update table [dbo].[JCS_JOBFILE1]
set a_name = replace(a_name, '<old_path>', '<new_path>');
go

DB2, Oracle, PostgreSQL

update table jcs_jobfile1
set a_name = replace(a_name, '<old_path>', '<new_path>');
commit;

Examples

SQL Server
use redwood
update table [dbo].[JCS_JOBFILE1]
set a_name = replace(a_name, 'c:\redwood', 'd:\redwood');
go
Other Supported Databases
update table jcs_jobfile1
set a_name = replace(a_name, 'c:\redwood', 'd:\redwood');
commit;

See Also

Database Tools in the Admin Server

onsiteTopic

← Upgrading Redwood PlatformUninstalling Redwood Server →