While the class libraries described above contain the generated code, the manual rule implementations, the interfaces, and indeed all the bits and pieces necessary to migrate 1 business object, the Portal component is charged with the task of migrating all business objects by calling the engine interfaces provided, one object at a time.
In addition, the Portal Operations is responsible for the housekeeping necessary to store all migration results, intermediary results as well as all events occurring during migration, and finally all audit information collected during the migration. It is the responsibility of the Portal to keep track of this information, even when the migration is iterated repeatedly and events and even items may appear, reappear and disappear.
The complete runtime and execution component consists of two main parts:
The runtime runs in a server setup and executes all the data migration processing. The runtime runs jobs on a server, performing a multitude of different tasks.
The most directly relevant jobs are for instance: Load Source Data, Perform Export Step, Perform Transformation and Target Step etc. But there are many different job types that in combination make up all functions necessary to run a data migration iteration from start to finish.
The Portal Operation connects to the server-based Director runtime and enables a user to orchestrate the data migration and initiate and monitor jobs as required.
While the collaboration and workflow around the mapping and the generated code take place locally on a personal machine, once the engine libraries have been deployed in the server environment of the Runtime, the rest of the framework execution flow takes place in the Runtime environment and is managed using the Portal Operations.
While the Runtime is executing migration jobs, the user monitoring the job execution may view the events raised by the migration engine as they happen. In this way, it is possible to react quickly in case of serious and invalidating events.
Normally, in a data migration setup of any significant size, the Runtime will run on one or more dedicated servers. However, in a tiny setup, it is perfectly possible to establish and execute the Runtime on a local machine as well.
A complete setup will leverage the full execution facilities of the runtime environment including the ability to concurrently iterate over separate data migration projects.
In this full-scale scenario, the Runtime can execute several, isolated migration projects on one or more dedicated servers in so-called Tracks. One server may host multiple tracks, and the Runtime can handle multiple servers – each with multiple tracks.