About Promotion

In RunMyJobs, "promoting" an object means exporting the object's definition in the form of a CAR file, then importing that CAR file in another instance of RunMyJobs.

The reason this is called "promoting" is because the Promotion Module is designed around best practices for developing RunMyJobs configurations. According to Redwood best practices, one should have separate RunMyJobs instances for development, testing, and production (in this documentation, these are named "Dev," "Test," and "Prod"). You do initial development in the "Dev" instance, and then when objects are ready for testing, you promote them to the "Test" environment. Once testing is complete and the objects are ready to be deployed, you promote them to the "Prod" instance.

There are three main ways to promote objects from one RunMyJobs instance to another.

  • Export and import. This method involves manually exporting objects into a CAR file and then manually importing that CAR file into a different RunMyJobs instance. This method is also commonly used for backup and for loading new software packages. For more information, see Exporting Objects and Importing Objects.

  • Simple promotion. This method involves right-clicking on an object you want to promote to another system and choosing Promote to system or Edit Further then promote. For a hands-on introduction to simple promotion, see the Promotion JumpStart Guide.

  • Promotion via the System_Promote process. This involves creating an Export Rule Set, which determines which objects you want to promote.

In RunMyJobs SaaS, promotion must be performed by a System User.

Note: The Promotion group in the navigation bar includes the Import Third Party Scheduler Data option. This option is provided for Redwood Product Consultants to import data from third-party scheduling solutions. For more information, contact your Redwood representative.

Note: The Promotion Module requires the Module.ImportExportlicense key.

Remote System Objects

Whichever method you use, you must use at least one Remote System object.

A Remote System object is an object in one RunMyJobs instance that servers as a pointer to a different RunMyJobs instance. There are three types of Remote System object:

  • A Destination Remote System object specifies the URL, Username, and Password of the RunMyJobs instance you are pushing to.

  • A Source Remote System object represents the RunMyJobs instance you are pushing from. The reasons for using a source Remote System object are discussed later.

  • A Both Remote System object can serve as both a destination and a source.

In an environment where you develop in a "Dev" RunMyJobs instance, test in a "Test" RunMyJobs instance, and go live in a "Prod" RunMyJobs instance, the assumption is as follows:

  • "Dev" is a Source Remote System object.

  • "Test" is a Both Remote System object, because it receives objects from "Dev" and export objects to "Prod."

  • "Prod" is a Destination Remote System object.

Remote System Naming

For a Remote System object to work, it must be named properly. When RunMyJobs receives a promotion request, it looks in its database for a matching source Remote System object. To make this comparison, it uses the incoming request's Originator ID.

An Originator ID is a string that identifies a particular RunMyJobs instance. The Originator ID consists of the portion of a RunMyJobs instance URL after the domain, but with underscores instead of forward slashes. For example, if a RunMyJob instance's URL is https://domain.runmyjobs.cloud/example-inc/test, its Originator ID is example-inc_test.

Assume a "Test" RunMyJobs instance receives a promotion request from https://domain.com/myrmj/dev. The destination RunMyJobs looks for a source Remote System object that meets one of the following criteria. The search is performed in the following order.

  1. RunMyJobs looks for a name with a matching Originator ID (in this case, myrmj_dev).

  2. RunMyJobs looks for a matching name with a wildcard asterisk (*). For example: myrmj_*.

  3. RunMyJobs looks for a name that consists only of an asterisk (*). This is a "catch-all" source Remote System, and it will consider promotions from any other source RunMyJobs instance that does not have a more-specific match.

Note: if you set the LockDown registry entry (/configuration/import/LockDown), any inbound promotion request must have a corresponding Source or Both remote system for it to be considered. If you do NOT set the LockDown registry entry, the name * will match any remote RunMyJobs instance.

Simple Promotion

The diagram below shows a simple promotion setup, where the objects are promoted via their context menu.

For a diagram that includes a Source Remote System object, see Promotion Reaction Process Definitions.

Note: When promoting an object, you can specify a destination Remote System object either immediately after promoting the object from the context menu or when submitting a System_Promote Process Definition.

Export Rule Sets

When you promote something from one RunMyJobs instance to another, you're typically promoting more than one object at a time, so you might want to use the System_Promote Process Definition. This Process Definition relies on Export Rule Sets to determine which objects get promoted. An Export Rule Set contains one or more of the following things:

  • Export List: This is simply a list of objects that should be promoted.

  • Export Rule Set: An export rule is a set of search criteria that define which objects should be promoted. An Export Rule Set can contain more than one export rule.

The diagram below shows a promotion setup where the objects to be promoted are selected with the System_Promote Process Definition and an Export Rule Set.

Promoting Processes

When you promote processes, you do not promote the actual process with its output. Rather, you promote the Process Definition, the Submit Frame, Time Window, lock, event, and Queue, if applicable - basically, all objects needed to be able to submit the Process Definition.

Note: Process Servers and ERP systems are never promoted with a process.

Configuration

You can customize the Promotion Module using the following configuration entries in the registry:

  • /configuration/import/RunAsUser: The subject to use for the import process. If this is not set, the owner of the System_Import_Archive Process Definition will be used.
  • /configuration/import/LockDown: If this is set to true, only specific source systems are allowed.
  • /configuration/export/name: A custom Originator ID that will be used to match Source or BothRemote System object in the target system.

You can set the first two registry entries manually or with the System_Import_Settings Process Definition. The third registry entry above can only be set manually.

Process Definitions

The Promotion module uses the following Process Definitions.

  • System_APP_Install: Installs signed CAR files.
  • System_APP_Uninstall: Uninstalls signed CAR files.
  • System_Export_Application: Exports an application.
  • System_Export_RuleSet: Exports objects as defined in an Export Rule Set.
  • System_Import_Archive: Imports definitions from a CAR file.
  • System_Import_Archive_WithApproval: Imports definitions from CAR file once approval has been obtained via an Operator Message.
  • System_Import_JarFile: Imports JAR files into a library.
  • System_Import_Settings: Defines import settings used by the System_Import_Archive Process Definition.
  • System_Import_SystemCarFiles: Imports system CAR files.
  • System_Import_ThirdParty_Plugin: Initiates the import of data from third parties into RunMyJobs.
  • System_Promote: Promotes CAR files to remote systems.
  • System_Promote_Further: Promotes a recently imported CAR file to another remote system.

Promotion Module SAP CTS Integration

You can integrate Redwood Server promotion into your SAP CTS+ landscape by installing a set of scripts on your SAP system. For more information, see Integrating Redwood Server Promotion into SAP CTS and Pusher Process Definition for SAP CTS+ Integration.