Managing Transfer Routes



Transfer routes define the locations that object versions can be moved or copied between. They also specify exactly what happens to the object at both the from location and the to location.

For more information, see the article on transfer routes.

You can manage transfer routes by navigating in the folders panel to Setup -> Transfer Routes. If any transfer routes are already set up, these should be listed in the main panel.

Adding and Modifying Transfer Routes


1. Double-click on the transfer route you want to edit, or choose File -> New from the menu bar to create a new transfer route.

2. Fill in the fields on the dialog.

These fields are found on the Main Details tab:

Function code
Specifies which function code this transfer route will take. This is a drop-down combo box which means that a user can define their own function code. This needs to conform to the valid naming conventions.

Note: When defining your own transfer route a caption should normally be set in the adjacent field. This caption applies to all routes using the function code. If a caption is not set, the function code will not appear in the drop-down list in the transfer dialog, so no routes using the function will be available for selection.

Note: When defining your own function code, be aware that certain codes and code prefixes have special meanings.


From location
The starting point of the transfer route, i.e. the location that the object version should be transferred from. Can be referenced in 'Dependencies', 'Activations' and 'New master location' as %FROM. Wildcard routes use %ANY.

To location
The end point of the transfer route, i.e. the location that the object version should be transferred to. Can be referenced in 'Dependencies', 'Activations' and 'New master location' as %TO. Wildcard routes use %ANY.

Access rights
Specifies the access rights for this transfer.

Dependencies
A list of requirements for the transfer, including locations, location lists (with the '@' prefix) and dependency functions. For example, if a location is listed here an object will not be able to move along the transfer route unless it is active at that location. The %FROM and %TO logicals are accepted. Negative dependencies can be used. An implicit %FROM dependency applies unless overridden by '%FROM or equivalent. For more information, see the article on syntaxes.

Activations
Specifies locations at which the object version will be activated ('+' prefix) or deactivated ('-' prefix) when it moves along the transfer route. The %FROM and %TO logicals are accepted, and +%TO is typically present here. For more information, see the article on syntaxes.

New master location
The location at which to find the master copy of the object version after the transfer. Not every route specifies a new master. If it does so then the transfer will also activate the object at that location if necessary, but an explicit activation is preferable. It is the system manager's responsibility to ensure that the workflow will have physically placed the object's component(s) into the storage associated with the new master location.

Copy/move
Specifies whether or not the object's component(s) should remain at the 'From location'. A Move-type transfer route will delete the object's component(s) from the origin location, and the object will no longer be active there. Note that it is rarely appropriate to use a Move-type route from a location that maps to L-format storage, since this will erase components from that repository. Instead, a route 'removing' an object from such a location will typically be Copy-type but with a -%FROM deactivation.

Create new version?
Specifies whether or not the object version should be incremented as it is transferred. Typically only done on checkout routes.

Transfer message
The message that is written to the audit trail when the transfer completes. This can include the symbolic names, e.g %FROM, %TO. See below for a full list of available symbolic names.

Message category
The category of message created when the transfer completes.

Skipped category
The category of message created when the transfer is skipped.

Error category
The category of message created when the transfer returns an error.

Notes
More detailed information about the transfer route.

These fields are found on the Advanced tab:

Enforce normal version sequencing rules?
By default this is selected, ensuring that an earlier version cannot overwrite a later version at a single-version location. For routes that need to allow reinstatement of an earlier version, clear this checkbox.

Backup function code
Function code for an optional route that will be used to back up a version of an object immediately prior to its displacement by the transfer of a different version.

Backup location
Optional location to which a to-be-displaced object version should be transferred. Avoid backing up to a location that maps to the same L-format storage as the master location of your objects, otherwise the backup will overwrite this.

Symbolic names available for use in transfer message text:

%Function
Function code of the transfer route.

%FROM
Location from which the transfer originates.

%TO
Location to which the transfer goes.

%Type
"Moved" or "Copied".

%Action
"Added", "Transferred", "Re-transferred" or "Deleted".

%Ancestor
Full name of the object from which the transfer originated.

%AncestorVersion
Version number of the object from which the transfer originated.

%ObjVer
Full name of the destination object.

%ByChReq
If transfer was initiated from a single change request, the change request. Otherwise, empty string.


See Also: Transfer Routes, Transfers