Migrating Objects

To migrate objects:

Click the objects and click Sync to begin the migration process.

The console in the Footer Status bar opens automatically. If errors occurred, the system puts movement on pause and shows the Awaiting Action status in the console.
1. To end the migration process before its completion, click More in the console:
  - Choose Abort from the dropdown list.
  - You can also stop the migration process by selecting More in the console – Resolve – Abort. The task is assigned the Aborted status.
2. To restart the migration process after you have manually updated the objects on the TA side, click More in the console.
  - Choose Retry from the dropdown list.
    
    The system repeats the movement process once again and the task is assigned the In progress status.
  - You can also repeat the migration process by selecting More in the console – Resolve – Retry.
3. To correct the mapping value:
  - Click More in the console.
  - Click Resolve.
  The Interactive Resolution tab displays these columns.
Columns in this tab include:
- Object Name. Displays the object which has dependencies that failed validation.
- Mapping Type. Shows the object type that was validated with errors.
- Original Value. Shows, in read-only mode, the original mapping value. This value was not found in the target environment.
- Mapped Value. Displays dropdown lists you can use to search for and choose the correct mapped value in the target environment.
- The Skip checkbox defines whether the system ignores the objects while resolving errors.
Note: If you check this checkbox next to the object and click Retry, the system ignores this object. The task is assigned In Progress status.

If you check this checkbox next to all of the objects, and click Retry, the migration process ends. The task is assigned Successful status.

Note: Apply allows you to use the selected mapped value for the remaining mapping types.

Choose the desired values from the target environment in the Mapped Value dropdown list.
- To skip these values, check the Skip checkbox.
- To use this mapped value to replace the original value, click Apply.
  
  Note: You can also manually update the objects on the TA side and click Retry, so the movement is successful.
- To remove the value upon movement, click the <<Remove>> option in the Mapped Value dropdown list. Click Retry. Validation begins at the point where the error occurred. The task is assigned In Progress status.
- To stop the movement process, click Abort. Note that the task is assigned Aborted status.
- To navigate to the previously viewed page, click Back.
Double-click a task to view task details.

Note: If the migration process lasts till the midnight (in the timezone TR is running), the system automatically without notifying cleans it up. It means that if there is a task with an Awaiting action status, the status changes to Aborted automatically after midnight.

Overview of Tidal Repository Movement

Movement details for all the object types are displayed below:

Object Types	Mappings Verified by Default	Dependent Objects Moved by Default
DEFINITIONS:
Calendars	Owners	Calendar Child
Resources	Owners, Variables, (Connections and Agent Lists are not required)	-
Events	Owners, Connections, Calendars, (Jobs are required for event-job), (Variables are required for event-variable and event-file)	Actions (if no mapping is specified)
Jobs	Owners, Calendars, Variables, Connections, Agent Lists, Job Groups, Job Classes, Resources, Job Dependencies, Events, Runtime user, Timezone, Tags. Variables for the job’s file dependencies	-
Terminator Jobs	Owners, Calendars, Variables, Job Groups, Job Classes, Job Dependencies, Events, Timezone, Tags, Images	-
Milestone Jobs	Owners, Calendars, Variables, Parent Groups, Job Classes, Job Dependencies, Events, Timezone, Tags, Images	-
Job Classes	Events	-
Variables	Owners	-
Actions	Owners (Jobs are required for action job), Variables, Runtime users, Connections	-
Business Views	Owners	-
Tags	Owners	-
Agent Connections	Runtime User	-
Agent Lists	-	-
Fiscal Calendars	-	-
Time Zones	-	-
Images Repository	-	-
Dashboard Element	Owners, Queues (for the Queue Activity data type only)	-
Queues	Job Name, Job Group, Job Type, Runtime User, Job Owner, Agent Adapter, Agent List	-
SLA Policies	Owners	-
ADMINISTRATION:
Workgroups	Owners, Runtime Users, Connections, Agent Lists, Validation Policies	-
Security Policies	-	-
Authorization Policies	-	-
Validation Policies	Owners	-
Shared Owner Policies	Owners (TA Workgroups)	-
Object Types	This column contains the object types that can be moved between different environments
Mappings verified by default	This column contains all the available mappings for particular object types. By default, Tidal Repository checks these mappings before the movement starts. The system validates that the object (either mapped or not mapped) exists in the destination environment. Before you move objects from one environment to another, determine if there are any explicit mappings that should be defined. Explicit mappings are mappings with different object names (map owner A to owner B). If object names are the same between source and destination environments, mapping is not required
Dependent object moved by default	This column contains all the dependent objects being moved with the parent object by default.

Movement Rules for Main and Dependent Objects

If there are two TA objects that have the same name but the names appear in different cases - uppercase (OBJECT1), lowercase (object1), or mixed case (Object1), Tidal Repository considers the objects as a single object for the purposes of moving them. For example, if a pipeline has two objects (OBJECT1 and object 1, respectively) and these objects are moved, they appear in the destination environment as a single object. This single object overwrites the previously saved object.

When attempting to move an object without a mapping set from a source environment to the destination environment – and the object name is not found in the destination environment – the object is created in the destination environment.

When moving an object with explicit mapping defined from the source environment to the destination environment, and the object with a mapped name is in the destination environment – the object is not updated in the destination environment. Instead, the object moved is linked with the mapped object in the destination environment.

When moving an object with explicit mapping defined from the source environment to the destination environment and the object with the mapped name is not found in the destination environment – the system returns an error.

The exception to this rule is for Connections and Agent List mappings when moving resources. An error is not generated if the wrong mapping for objects is defined or is not defined at all.

Note: These cases are applied for Push (Repository to Destination). For a Pull (Destination to Repository), there are no required mappings that system checks by default.

Once the movement is successful, the check mark is removed for each object that was selected for movement on the Pipeline view. You can refresh the page to ensure that the data has been updated.

Movement Rules for Jobs and Job Groups

Note: By default, those objects that are not changed and match the last modified date of the existing object in the destination environment are not moved. Tidal Repository moves only those objects that have different modification dates.

If you want to move all objects despite the last modified date parameter, add the property last.change.time.filter.on to the application.properties file. This parameter controls whether objects are moved when transferred from the TA.

If set to TRUE: Objects that have already been moved and remain unchanged on the TA side will not be moved again. This prevents redundant transfers.
If set to FALSE: Even if objects have been moved and are unchanged on the TA side, they will be re-moved.

Tidal Repository allows moving:

A parent job group with its job and job group children

A parent job group without a job and job group children

A child job or a child job group without a parent job group from a source environment to a destination environment

When moving a job child or a job group child from a repository to a connection, the mapping of parent job groups must be specified when the parent job groups have different names. No mapping is required when parent job groups have the same name.

When moving a job child or a job group child and a mapping is specified with the <<Remove>> option for the parent job group, the job child/job group child is moved into the root.

When moving a parent job with a child job and the parent job with the same name either exists in target environment or a mapping of job groups is specified, then this child job inherits properties (such as calendar inherits, and agent inherits) from a new parent job.

When moving a job with objects (for example, tags) to the environment that does not have such objects, the job is moved, and the objects are ignored.

When moving a job group with the same name as an existing job group from a repository to a connection, the job group in the connection has the existing child jobs and the new ones from the job group in the repository.

When moving a job with the same name as an existing job to a connection, the existing job is updated.

When moving an object from a repository to a connection where the object type does not exist, this object is ignored during the movement.

These cases apply for movement to a repository only:

When moving a job with the same name (full path) as an existing job, the existing job is replaced with the new job.
When moving a job with the same name (full path) as an existing job group, the job group with its child jobs and all dependencies is replaced with the job.
When moving a job group with the same name (full path) as an existing job, the job is replaced with the job group.
When moving a job group with the same name (full path) as an existing job group, the existing job group with its child jobs and all dependencies is replaced with the new one.