Migrate Models and Extensions
You can migrate models from one environment to another, for example, from a test environment to production, using Eagle's Migration Wizard or the direct client to target application server migration approach that Data Mart offers.
This is referred to as Data Mart migration. For information on migrating models using the Migration Wizard, refer to Use Migration Wizard with Data Mart.
Unlike the Migration Wizard, Data Mart migration is a single-step process. The Migration Wizard involves export of an .egl file from the origin environment and import of that file into the destination environment. For Data Mart migration, model configuration information is sent from origin to destination immediately during your online session.
As in any migration operation, it is strongly recommended that you never make changes to a production environment that will be affected by a planned future migration. This practice helps you avoid the chance of your environments falling out of synchronization.
Check Migrated Components
Before you migrate Data Mart models, your destination environment must have all of the PACE metadata that you used to build those models in the origin environment:
Field attributes (Field Identifier must match between origin and destination environments)
Regular dictionaries (name must match)
Performance dictionaries (name must match)
Range rules (name must match)
The best way to ensure these conditions is to use Eagle's Migration Wizard to migrate this metadata.
Exceptions when Migrating Model Elements
Nearly all elements of a model are migrated, with the following exceptions:
PACE attempts to migrate the list of identifiers for entities you have selected as eligible to populate your Data Mart model. However, if an entity exists in the origin but not the destination, then the Entity ID, but not its Entity Name, appears in the Funds (Entities) tab of the destination. You should manually delete such entities from the tab in the destination environment.
If you have added extensions to your model, you must manually create your origin extensions in the destination environment.Â
Settings in the Configuration link are not migrated. They must be recreated manually in the destination.
You must manually recreate any filters used in your models.
Schedules are not migrated, but it may be appropriate for them to differ between environments.
Field selections using Selective Fields functionality are not migrated, and should be recreated post-migration.
About Migrating Data Mart Field IDs
Data Mart does not permit a particular Data Mart field, as identified by its Data Mart Field ID (for example, DF_1234) to be associated with more than one field attribute, as identified by its Field Identifier (for example, MARKET VALUE – SUPERUSERS).
When you select a field for a Data Mart model, Data Mart provides you with a default Field ID that incorporates the field attribute ID number of your chosen field. Eagle recommends that you override the default and assign a more meaningful Data Mart Field ID.
Any time you migrate a Data Mart model, the field attributes of all of the model's fields must already be created in the destination environment. Their field attribute ID numbers most likely do not match those of the same fields in the origin environment, since PACE assigns these numbers automatically on a next-instance basis.
When Data Mart migrates a field within a model, its Field ID in the origin carries over to the destination, even though the field attribute ID number in the Data Mart Field ID probably does not match the field's field attribute ID number in the destination environment. This might appear confusing in the destination.
If you override Data Mart Field IDs to create unique meaningful values that are not related to their field attribute IDs, you can avoid this confusion.
Migrate a Model
If you are migrating a model with extensions, see Migrate a Model with Extensions. If you are migrating a model on a system with a firewall, see Migrate a Model with Firewall.
Migrating a model requires an additional step and additional considerations if the model has extensions.
To migrate a model:
In the Manage Mart window, click the Migration link and select Migrate Now (Pre 9.0 Method).
NOTE:Â The other options in this dropdown list do not apply to the Data Mart Migration approach.
You see the Data Mart Migration dialog box with the Login tab enabled.In the Destination PACE Application Server box, enter the destination application server.
This is the environment's Machine ID.In the PACE Application Server Port No box, enter the application server port field.
This is the PACE Communication Port.In the User box, enter your user name.
In the Password box, enter your password.
You must have user access to both environments to migrate models.In the Protocol section, select how you want to log in to the destination webserver. Options include:
- Eagle. If you log in to the destination webserver through the Eagle Communications protocol, click the Eagle button.
- Http/Https. If you log in to the destination webserver through the http or the https protocols, click the Http/Https button.Click Next to continue.
You see the Web Address and Type fields appear on the Login tab.Fill in the Web Address field with the full URL which you used to log into the destination.
This is the part of the URL you already used to log into the destination, up to and including "epace-cgi".Â
For example, if the full login URL is:http://ketu:8989/epace-cgi/eglcgilg?Action=Default
, you need to enter:http://ketu:8989/epace-cgi
ÂUnder Type, click either Windows or Unix to indicate the operating system of the webserver machine.
Click Next.
You see the Model Selection tab.Select the check boxes of each model that you want to migrate, and click Next.
The system checks whether all required field attributes, dictionaries, and rules exist in the destination environment. If they do not exist, the system produces an appropriate error message for each missing item.
This error indicates that the Cost field attribute is missing in the destination environment. Use the Migration Wizard to add the missing element to the destination.
After responding to any errors, re-run the Data Mart migration. Following this, you should receive a Validation Passed message.
Once all field attributes are present in the destination environment, the migration proceeds and a success message appears. You can immediately see the results in the destination environment.
Migrate a Model with Firewalls
If there is a firewall separating the ePACE client and the target ePACE Application Server, your system manager must set up a firewall rule on the server where the ePACE Application Server is hosted that will permit access from the ePACE client that is initializing the migration. This rule would appear as follows:
permit tcp host
[insert ePACE Client IP address] host
[insert target ePACE Application Server IP address] eq
[insert ePACE Application Server Communication Port number]
For example:
permit tcp host 10.60.123.45 host 10.60.678.90 eq 7001
Migrate a Model with Extensions
Migration of a model to another environment requires an additional step and additional considerations when the model has extensions. Prior to migrating a model with extensions, you must manually add the extensions in the destination environment using the Data Mart Table Extensions dialog box.
Click Extensions in the Manage Mart window. The Data Mart Table Extensions dialog box appears.
Ideally, all of the identifying fields you use to create an extension should match between environments, but PACE requires that the following two fields match:
Name. This is an assignable ID code for the extension. PACE gives you a default value for it, but if it does not default to the same value as in the origin environment, you must override it so that the two values match.
Table Name. This is the name of the table in the Mart schema that is created by addition of the extension.
It is acceptable, but not recommended, for the Description field to differ between environments. Descriptions in each environment are not affected by migration.
When you do migrate the model, the assignment of its fields to extensions match between the origin and destination environments. For this reason, it is important not to make any field assignments in the destination that do not match those in the origin, because they are overwritten by migration and result in false information about extension assignments in the destination. In fact, no "migratable" changes like extension assignments should ever be made to the destination environment except by migration.
Following the first migration of a field in an extension, the destination model's Fields tab shows the extension assignment of that field as not being grayed out. This is because the field has not yet been populated. Even though the assignment can physically be changed at this point, it should not be. Once the field is populated, the assignment is grayed out and is no longer subject to change.