Running Flyway Manually

If you are not doing a completely new installation, you must run Flyway in upgrade mode. Running in upgrade mode also applies to minor maintenance releases of WFM such as an upgrade from WFM version 6.2.1.0 to 6.2.1.1. Details about how to run in upgrade mode are detailed in this section.

Note: Prior to running Flyway, for new installations you will see records for maintenance releases in the WFM version table, even if you are not currently on that version. For example, after completing a new 6.2.1.0 installation, you will see a 6.2.1.x record in the WFM version table even if you have not run Flyway to move to the patch level of 6.2.1.x. You must still run Flyway to move to version 6.2.1.x.

To run Flyway and migrate your WFM database:

  1. You must ensure that the WFM_PRE_CLASSPATH environment variable exists and is pointing to the JDBC jar files you are using for your WFM deployment. This variable is normally already set during an installation of WFM. For example, in a Windows environment it may be set like this:
    WFM_PRE_CLASSPATH=C:\<Path_to_JDBC_Driver>\sqljdbc42.jar
  2. Flyway files are located in both the WBDatabase-<version>-Fixpack-<date>.zip file and the WBUpgrade-<version>-Fixpack-<date>.zip file which are part of your WFM artifacts. Once you extract these files using your preferred utility as part of your installation or upgrade, you will see a flyway directory.
  3. In the flyway/config directory of the extracted files, you must update the flyway.properties file with specific values from your deployment and other values recommended by Infor. You can use the preferred text editor on your operating system to make these updates.
  4. You must update all of the placeholder values in the flyway.properties file denoted by square brackets: [placeholder value]

    • migration.dbtype=[flyway_db_type] - Specify one of SQLSERVER, ORACLE, or DB2. For example:

      migration.dbtype=SQLSERVER

    • populate_qadata=[populate_qadata] - You must set this value to false. For example:

      populate_qadata=false

    • populate_testdata=[populate_testdata] - You must set this value to false. For example:

      populate_testdata=false

    • workbrain.db.driver=[flyway_driver] - Specify your database driver. For example:

      workbrain.db.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver

    • workbrain.db.name=[flyway_dbname] - Your WFM database name. For example:

      workbrain.db.name=DBNAME

    • workbrain.db.instance=[flyway_url] - Your database instance name. For example:

      workbrain.db.instance=jdbc:sqlserver://SQLSERVERINST:1433;databaseName=DBNAME

    • workbrain.db.username=[flyway_username] - Your database user name. For example:

      workbrain.db.username=workbrain

    • workbrain.db.password=[flyway_password] - Your database password. For example:

      workbrain.db.password=workbrain

    • workbrain.db.schema=[flyway_schema] - Your database schema. For example:

      workbrain.db.schema=dbo

      Note: For some databases such as Oracle, this value can be case-sensitive.
    • workbrain.db.server=[flyway_server] - Your database server name. For example:

      workbrain.db.server=localhost

    • workbrain.db.port=[flyway_dbport] - Your database port. For example:

      workbrain.db.port=1433

    • Using the same technique, you must now also specify values for these properties of the WFM archive database:

      • workbrain.archive.db.name=[flyway_archive_dbname]
      • workbrain.archive.db.instance=[flyway_archive_url]
      • workbrain.archive.db.username=[flyway_archive_username]
      • workbrain.archive.db.password=[flyway_archive_password]
      • workbrain.archive.db.schema=[flyway_archive_schema]
      • workbrain.archive.db.server=[flyway_archive_server]
      • workbrain.archive.db.port=[flyway_archive_dbport]

    • migration.runas=INSTALL - If you are upgrading (minor maintenance releases and major upgrades) and NOT doing a fresh installation, you must change the default value of INSTALL to this setting:

      migration.runas=UPGRADE

      For a new, fresh installation of WFM, do not make any changes and keep this default setting:

      migration.runas=INSTALL

    • migration.protectCustomData=true - This property must be used with the same value across all upgrades. Failure to do so may lead to an upgrade failure during Flyway execution.

    • migration.outOfOrder=[false or true] - If you are upgrading from or to a maintenance release from a major release (for example, 6.2.1.x --> 6.2.2.0 or 6.2.2.0 --> 6.2.2.x), or you are upgrading between maintenance releases (for example, 6.2.1.8 --> 6.2.1.16), you must specify a value of true for this property.

      If you are upgrading between major releases (for example, 6.2.1.0 --> 6.2.3.0), you must use the default setting of false. This is the only scenario in which this property should be set to false.

    • migration.baselineVersion=6.2.1.0 - Do not change this value under any circumstances. This value must remain as is.

  5. Navigate back to the root directory and execute run_flyway.bat (Windows) or run_flyway.sh (Linux/UNIX) depending on platform being used. You may need to use the chmod command to add executable permissions to run_flyway.sh.

    There is a log folder in the root Flyway directory along with all Flyway artifacts. The wbflyway.log file in this directory contains all logging information during Flyway execution. It can be modified by changing this line in the log4j.properties file:

    log4j.appender.R.File=logs/wbflyway.log
  6. After executing the Flyway script, you will now see a series of messages in the command window. If there are no errors in the command window, you can check if there is a SCHEMA_VERSION table created and populated in your WFM database. This table contains an audit log of all the changes that have been applied to your database and if this table is created and populated, then your database migration is successful.
    Note: If you need assistance with troubleshooting a Flyway migration failure and need more information on the opional values in the flyway.properties file, see Troubleshooting Flyway migration failures.
  7. As an important post-Flyway execution step, you must review the configurable fields in WFM that may require an update after Flyway execution has completed. This information is outlined in Upgrades and WFM Configurable Fields. This topic will help you to determine if any of the configurable fields in your WFM deployment are affected and require an update.