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 RunMyJobs server to unzip the redwood-platform.zip file and mount or copy the DataRootDirectory from the old central RunMyJobs server.
  • If you are using the same OS family (Windows, UNIX), Redwood recommends using the same path on both the source and target servers.
  • If you are migrating from Windows to UNIX (or vice-versa), or you cannot keep the same path on the target server, you must update table jcs_jobfile1 to point to the new path. This must be done in the native database tooling (for example, sqlplus for Oracle).
• The new central RunMyJobs server must be a supported platform with a supported JVM installed.
• The redwood-platform.zip file for version 2023.3.0 must be available on the new central RunMyJobs server. If you are migrating from an older version, Redwood does not recommend updating the schema in the old database directly, because you might need to abort or postpone the migration if problems are detected.
  • If you are migrating from version 9.1.5 or higher, the admin server version 2023.2.0 will be able to update the schema.
  • If you are migrating from version 9.0.22 through 9.1.4, you will need a redwood-platform.zip file for version 9.1.5 as well as the one for version 2023.3.0. Note that 9.1.5 requires Java 8, so that also needs to be available on the new server.
  • If you are migrating from a version lower than 9.0.22, you will need redwood-platform.zip files for versions 9.0.22, 9.1.5, and 2023.3.0. Note that 9.0.22 requires Java 8, so that also needs to be available on the new server.
• Network connectivity must be available between the new central RunMyJobs server and the new database server (database port) and all Platform Agents (Platform Agent port). If the Platform Agents and/or the database server use TLS, the certificate(s) must be trusted by the JVM.
• If you want 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 this workflow in full and make sure you have everything necessary, including having the required technical parties (System Administration, DBA, Redwood Support) available prior to starting the procedure.

1. Prepare the installation files on the new server. Make sure you have a supported JVM installed on the target RunMyJobs server. Specify any required environment variables and system properties.
2. 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 necessary. If you are migrating from one OS family to another (Windows to UNIX or vice-versa), you must 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.
3. Stop the old central server and perform a backup of the database. If the hostname of the central server needs to change, make sure 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.
4. Prepare the database. If you are switching database servers, see Database Prerequisites and do one of these things:
   • If your old server is on SAP NetWeaver, see SAP NetWeaver to Redwood Platform Migration.
   • 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.
   • If you are switching database servers, see DB2, SQL Server, Oracle, PostgreSQL.
5. Drop obsolete privilege grants.
6. Copy or mount the DataRootDirectory on the new host if it points to a network drive or SAN.
7. If the mount point or drive letter for the DataRootDirectory path was changed, update the table jcs_jobfile1 to point to the new location.
8. If the central server hostname has changed and 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).
9. Start the central RunMyJobs server.
10. If you changed the central Redwood server's hostname, install the license.
11. 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 2023.3.0, you copy the database to a temporary database accessible by the admin server and upgrade 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 must get the Sybase JDBC driver instead of the SAP HANA driver. Note that in the case of a migration, you will not install the database because it is already there. If you are asked to upgrade the database schema, make sure you have a backup of the database before you do so.
3. Proceed to the Migrating the Database with the Admin Server section below.

DB2, SQL Server, Oracle, PostgreSQL

You have a choice between two options:

• Migrating the database using database-specific tooling. This is faster, but requires that both source and target databases are of the same flavor (for example, both are DB2)
• Using the admin server. This is slower and requires a connection from the new server to the old database. The admin server is database flavor independent.

If you are using database-specific tooling, ask your DBA to copy the schema containing the jcs_ tables to the new database server, then proceed to Migrating the Central Redwood Server.

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.

Either way, when you are finished, 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 2023.3.0 if it is not already running,
2. Connect to the source database.
3. Go to DB Tools > Export.
4. Leave the Pattern field empty.
5. Specify an existing output directory on the central RunMyJobs server in the Output Directory field (for example, ../temp).
6. In a browser, navigate to https://<server>:10185/scheduler-admin/login/logout.jsp to log out of the source database.
7. Log in to the target database. Install the database if instructed to do so.
8. Navigate to DB Tools > Clear and enter .* into the Pattern field to truncate the database tables before the import.
9. Navigate to DB Tools > Import and enter 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.

10. If you want to force the Start On Startup flag to unset on all Process Servers in order to prevent them to become active once the system boots up, execute the following database statement:

    update JCS_PROCSERVER0 set A_ONSTART = 'f' where A_SEARCHNAME not in ('SYSTEM')

    Note: For information about performing database updates, see Updating the Database from the Admin Server.

11. If you want to force all Queues to be closed to prevent Processes from starting once the system boots up, execute the following database statement:

    update JCS_QUEUE0 set A_HELD = 't' where A_SEARCHNAME not in ('SYSTEM_MAINTENANCE')

    Note: For information about performing database updates, see Updating the Database from the Admin Server.

12. To log out of the target database, use a browser to navigate to https://<server>:10185/scheduler-admin/login/logout.jsp.
13. If you have not mounted/copied the DataRootDirectory to the same path, see Updating the jcs_jobfile1 Table.
14. Stop the admin server and start the central RunMyJobs server (server1).

Migrating the Central RunMyJobs Server

If you used database-specific tooling to migrate the database, you must still make sure the database is up-to-date.

1. Start the admin server and connect to the database.
2. Upgrade the database schema if required.
3. Make sure you have either mounted/copied the DataRootDirectory to the same path, or updated the jcs_jobfile1 table.
4. Stop the admin server.
5. Start the central Redwood server (server1).

Upgrading the Database Schema

Because the database schema is not up-to-date, and because best practices dictate that you should not alter a source system when you migrate, you must copy the database to a temporary database and update that temporary database. If the source and target database flavors (for example, Oracle) are the same, the temporary database can become the target database for the migration.

1. Use native database tooling to copy 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, and then click Connect and Install/Update.
   1. Wait for the schema evaluation to complete.
   2. Click Upgrade and wait for the upgrade to complete.
   3. Stop the admin server.
   4. Proceed to the 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,and then click choose Connect and Install/Update.
   1. Wait for the schema evaluation to complete.
   2. Click Upgrade and wait for the upgrade to complete.
   3. Stop the admin server.
4. Start the admin server version 2023.3.0, connect it to the temporary database, and then click Connect and Install/Update.
   1. Wait for the schema evaluation to complete.
   2. Click Upgrade and wait for the upgrade to complete.
   3. Stop the admin server.

Removing Obsolete Grants

Assume that an error like the following 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) [?:?] 

Note: This is a sample error stack for JDEdwardsSystem. The error stack may mention DynamicsAxSystem, GMQuery, GMQueryRepository, or GMRepository instead.

Before you upgrade to 9.0.22, you must remove obsolete grants. To do so, you can use the following SQL. Adapt this code to use the correct database name and store it in a file on the central RunMyJobs server. Use the admin-server Database Tooling (DB Tools > Execute SQL) to execute the file. 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, then click 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')); 

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. The SQL to run is shown below.

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;

Example SQL

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;

Note: For information about performing database updates, see Updating the Database from the Admin Server.

Updating the Database from the Admin Server

If a native database client is not available, you can use the Admin Server to perform a direct database query or update. To do so:

1. Create a file with the desired SQL, depending on your database flavor, and copy it to the server hosting the Admin Server.
2. Start the Admin Server version 2023.3.0 if it is not already running.
3. Connect to the source database.
4. Go to DB Tools > Execute SQL.
5. In the SQL File field, specify the full path to the SQL file from step 1.
6. Click Execute.
7. To log out of the target database, use a browser to navigate to https://<server>:10185/scheduler-admin/login/logout.jsp.

See Also

• Database Tools in the Admin Server