You set up Remote Systems on central Redwood Servers to promote objects directly to remote systems from the context-menu. Remote systems can be Source, Destination, or Both.

Source - Remote Redwood Server instance from which you receive objects
Destination - Remote Redwood Server instance to which you send objects
Both - Bi-directional remote Redwood Server instance

Typically, you would set up remote systems on dev, test, and production as follows:

dev: test (destination)
test: dev (Source), production (destination)
production: test (Source)

Tabs and Fields

Tab	Field	Description
Remote System	Partition	The partition of the remote system. Partitions allow you to separate objects on a security basis.
Remote System	Name	The name of the remote system, special care needs to be taken for the choice of names when the remote system is of type Source or Both, it must match the name of the declared SystemId of the remote Redwood Server (see below). Source and Both systems can be named *, in which case any remote Redwood Server system can promote to this system (valid credentials are needed). Destination system names accept any Unicode character combination (UTF-8) except characters from the separator and other categories; note that leading and trailing spaces will be trimmed.
Remote System	Description	A description for the remote system; description fields accept free-form text, any printable UTF-8 character combination is allowed; note that depending on the platform/browser, some characters of the symbol and other Unicode tables will not be displayable. Limited to 255 characters.
Remote System	Application	The application for the remote system; applications allow you to group objects in functional packages.
Remote System	Type	The type of remote system. Source: the remote system acts as a source for objects Destination: the remote system acts as a target system for object from the current Redwood Server Both: the remote system can be both a destination and source.
Remote System	Location	URL pointing at the remote system, https://pr1.example.com:53000/redwood for example. (available for Destination and Both systems only)
Remote System	Username	The username with sufficient privileges to either export or import objects. (available for Destination and Both systems only)
Remote System	Pusher Process Definition	Process definition or chain definition that is to be used to send the exported objects to a remote system. (available for Destination and Both systems only)
Remote System	Promote Further Process Definition	Process definition that is used to promote a previously promoted CAR file on to another remote system. (available for Both systems only)
Remote System	Push Acceptor Process Definition	Process definition that is used to validate inbound promotion requests (available for Source and Both systems only)
Remote System	Import Rule Set	Import rule set used to adapt incoming objects to the current system (available for Source and Both systems only)
Remote System	Allow Rule Set Override	Allow inbound promotion requests to specify another import rule set for use (available for Source and Both systems only)
Remote System	Options	Allows you to specify options for the outbound promotion, such as -targetpartition `<partition>`, forcing any outbound promotion requests using this remote system to set the target partition of all objects to `<partition>`. Import Rule Set parameters can also be set using the `-P<name>=<value>` syntax. (available for Destination and Both remote systems only)

Remote System Selection

When a promotion request is received by the promotion module, a search is performed to find a remote system that qualifies for the import. The search uses the originator ID which is defined by the context of the RunMyJobs environment:

https://dublin.runmyjobs.cloud/example-inc/test -> originator ID: example-inc_test
https://rmj.example.com/redwood -> originator ID: redwood

The search is performed in partitions in the following order:

GLOBAL partition.
Source system with the name of the originator ID
Catch-all Source system named *
Target partition of the objects to be imported.
Source system with the name of the originator ID
Catch-all Source system named *

If no remote system is found in these locations and lockdown is enabled, the promotion request will be vetoed and no objects will be imported. The search order allows you to specify GLOBAL import rule sets on remote systems in the GLOBAL partition and partition-specific import rule sets in the target partitions.

Security

To avoid issues, the name of the Source or Both Remote System object must match the remote originator ID license key. When you specify a Source or Both Remote System, incoming objects are scanned for the source system they come from; if the source system matches, the car file is imported, otherwise the import will fail.

On the source system, you optionally specify an alias in the following registry entry:

/configuration/export/name

On target systems, you create Source or Both Remote Systems named after the alias instead of the originator ID license key.

A catch all remote system is allowed in the GLOBAL partition named *.

Import Rule Set Overrides

Special consideration needs to be given to your import rule set strategy. Allowing overrides means that the inbound CAR file can specify its own, potentially

Promotion Workflow

Simple Promotion

When you promote an object, the following steps are performed once you have chosen the remote system:

An export rule set is created to export the object.
If the remote system of type destination has a pusher process definition set, submit it to do the actual work, otherwise use System_Promote.
An outbound promotion request is sent.

On the other end, the destination system, the following happens:

An inbound promotion request is received.
Check if the lockdown registry entry is set:
If it is set, look up the remote system with the name of that matches the originator ID of the remote system.
If found and it has a push acceptor set, submit that process and if it completes, allow the import.
If no source remote system is found or the pusher acceptor process fails, veto the promotion.
Lockdown is not set, so look up the remote system with the name of that matches the originator ID of the remote system.
If found and it has a push acceptor set, submit that process and if it completes, allow the import.
If the pusher acceptor fails, veto the promotion request.
If no source remote system is found, allow the promotion.

Push Acceptor Process Definitions

Push acceptors are use to verify if the CAR file should be imported or not. Push Acceptor process definitions must be attached to Source or Both type remote systems. The name of the remote system must match:

The value of the registry entry /configuration/export/originator ID in the remote system.
The originator ID of the remote Redwood Server.
* will match any remote Redwood Server.

A built-in push acceptor-like chain definition is available; you duplicate it and set the reaction process to Push Acceptor:

System_Import_Archive_WithApproval

Promote Further Process Definitions

Promote further process definitions are defined on a Destination remote system. When you have a Promote Further Pusher defined on a remote system, the remote system will support Promote Further which means that it will be listed in the context-menu of System_Import_Archive processes.

If the remote system of type destination has a promote further pusher process definition set, submit it to do the actual work, otherwise use System_Promote_Further.
An outbound promotion request is sent.

On the other end, the destination system, a regular inbound promotion request is received, see previous section.

Promoting Processes

You promote processes as processes, that is, you do not promote the actual process with its output, for example, but the process definition, the submit frame, time window, lock, event, and queue, if applicable - basically all objects to be able to submit the process definition in the same manner as the process. Process servers and ERP systems are never promoted with the process.

Export Rule Sets

An export rule set is created for each object or group of objects you export.

Controlling Imports

When you attempt to import a CAR file, Redwood Server attempts to locate remote systems that match the name of the source system in the CAR file (located in META-INF\export-info.xml ) and determines if the export rule set is allowed to be overruled. This allows you to create remote systems of type Source that specify whether the import rule set can be overridden, and any push acceptor definition that is to be used, for example.

A catch all remote system of type Source named * can be specified in the GLOBAL partition to veto, for example, any unexpected imports (imports that do not match any of the source remote systems).

Example

Promotion between Development, Test, and Production

You have three environments, production (https://dublin.runmyjobs.cloud/example-inc/prod), development (https://dublin.runmyjobs.cloud/example-inc/dev), and test (https://dublin.runmyjobs.cloud/example-inc/test).

The values of the originator ID are as follows:

development - example-inc_dev
test - example-inc_test
production - example-inc_prod

On the development system, you set up a Remote System of type Destination with the following properties:

Field	Value
Partition	GLOBAL
Name	example-inc_test*
Application	Promotion
Type	Destination
Location	https://dublin.runmyjobs.cloud/example-inc/test
Username	jdoe
Password	***

On the test system, you set up Remote Systems of type Destination and Both with the following properties:

Field	Value
Partition	GLOBAL
Name	example-inc_dev
Application	Promotion
Type	Both
Location	https://dublin.runmyjobs.cloud/example-inc/dev
Username	jdoe
Password	***
Import Rule Set	ChangeObjectProperties

Field	Value
Partition	GLOBAL
Name	example-inc_prod*
Application	Promotion
Type	Destination
Location	https://dublin.runmyjobs.cloud/example-inc/prod
Username	jdoe
Password	***

On the production system, you set up a Remote System of type Source with the following properties:

Field	Value
Partition	GLOBAL
Name	example-inc_test
Application	Promotion
Type	Source
Location
Username
Password
Import Rule Set	ChangeObjectProperties

Destination Remote System names (marked with an asterisk * ) can be freely chosen.

Result

You now promote objects from development to test, test to development and test to production using the context-menu of the object. Note that in this example, an import rule set named ChangeObjectProperties is used to adapt objects to the new environment. You can inspect the imports in Promotion > Imports in the target system.

Using an Alias

You have two Redwood Platform environments, production https://rp1.example.com/prod and development https://dv1.example.com/dev. You promote objects from development to production and have specified Devel as an alias in /configuration/export/name on https://dv1.example.com/qa.