These options are displayed when you select Advanced Settings on the Import dialog box. Select Import Settings to access the basic import options.

Specify New Owner

Select or enter the name of the new owner of the imported model elements. The name of the new owner must be a qualified name with a dot separator. For example, where the new owner is salesSegment.cashSaleIspec, the model elements are imported under the cashSaleIspec element of the segment salesSegment. Alternatively, click browse to display the Select Owner Element navigator. Browse to and select the element you want to become the parent of the import and click OK.

On Element Clash

Conflicts occurs if an element being imported has:

Select one of the following options to specify how to deal with conflicts that might arise:

Ask – Select this option to display the Conflict Resolution dialog box each time a conflict is encountered. You can use this dialog box to deal with conflicts on a case by case basis.

Replace – When a conflict occurs, this option replaces the existing element with the one from the interchange file. Any element at the same level in the model, that were not in the interchange file are removed. Where, the element being imported is not in the existing model, but has the same name as an existing element within that namespace, the element from the file is renamed and an error is reported.

Skip – Select this option to retain the existing element in the model and ignore the incoming element.

Substitute – Select this option to replace the values of the existing element in the database with those in the interchange file. Any elements at the same level in the model that were not in the interchange file will remain. Where the element being imported is not in the existing model, but has the same name as an existing element within that namespace, the element is renamed and an error is reported.

Override Language Conflict

The "Override Language Conflict" provides alternative options to deal with language conflicts.

Conflicts occurs if a model being imported has a conflict in the:

Select one of the following options to specify the method  to deal with conflicts that might arise:

Ask – Select this option to display the Override Language Conflict dialog box each time a language conflict is encountered. You can use this dialog box to deal with conflicts on a case by case basis.

Update Model – Select this option to overwrite the existing language with the incoming language when a language conflict is encountered.

Keep Existing – Select this option to ignore the incoming language and retain the existing language in the Model when a language is encountered.

Abort – Select this option to abort the import when a language conflict is encountered.

Additional Options

Create New Identifiers – In the model, each element has a globally unique identifier. Selecting this option gives each of the elements being imported a new globally unique identifier. The import maintains the structure defined in the model file.

Attempt Import in Exclusive Mode – Select this option to attempt to enter exclusive mode in the database. If successful, no other user can access the database and the database remains locked until the import is complete. This can improve the performance of the import.

The switch to exclusive mode fails if any other user is logged into the database. A message displays and you can select to continue or cancel the import.

Version Controlled

The “Version Controlled” option applies only to LCIF files not for AB Suite .model files.

Migration Granularity

Elements in AB Suite are able to be versioned individually or collectively in a single file. LCIFImport allows for the granularity of the version control files generated to be specified. The following are the two available options:

Components – All Non-Primitive objects sets into their own separate version control file.

Segment Members – All elements owned by with the Model, or the Business Segment, (plus profiles) sets into their own separate version control file.

Baseline Migration Database

This option allows you to baseline the Migration Database prior to the import of full EAE extract file(s) such that performing an export by using Changes Since Last Migration Database Baseline would only export elements changed by that import.

Automatically Enlarge Small Controls

EAE allowed users to create controls that are smaller than the minimum size for AB Suite. Controls that are too small might not display correctly in AB Suite Runtime. The AB Suite Import provides a new option "Automatically Enlarge Small Controls" in Advanced Setting Page of the Importer Main Form.

This option allows you to specify whether small controls should be resized automatically. This option is applicable to import of an EAE MDL Files. By default, this option is not selected. If this option is not selected, the controls could be imported with the size as specified in the LCIF Extracted File. Controls that are too small might not display correctly in AB Suite. If this option is selected, the small controls enlarge automatically to AB Suite minimum size. The enlarged controls might overlap to surrounding controls.

Migrate Display Item Sizes AS Seen In

EAE Developer synchronizes the sizes of display items to fit the desired text thereby taking into account the font properties. It is however possible to create display items that are smaller in appearance than the required size. This situation arises when the display item is getting its font from the segment. If the font on the segment is changed, EAE does not automatically update the size of all the labels that rely on this font. If the EAE segment is extracted after such a change, the .mdl file contains incorrect sizes for display items.

Until now, AB Suite migrator was importing display items with the size specified in the .mdl file. To address the issues with labels being out of sync, AB Suite Import Wizard has the extra option to import display items with the size defined in the .mdl or calculate a new size.

To choose between EAE Developer and EAE MDL File, the AB Suite Import provides an option in advanced settings of Importer Main Form

Configurations To Include

All the configuration related options are applicable only when importing a .model file.

All – Select this option to create configurations in the incoming model file, if they do not exist in the database. It is applicable only when importing a .model file.

Existing – This option is set as default to import the configurations existing in the database.

None – Select this option to ignore all the configurations in the incoming .model file. This option is disabled when importing the model file to a new database.

Import Only Configurations

Select this option to import only configurations and ignore all other elements in the incoming model file. It is applicable only when importing a .model file. By default, configurations are just updated if they already exist in the database during import.

LDL+ Migration Settings

Previously, during migration, the StoreOrSend() method was added to all the ispecs. This method contained logic to test the value of system Attributes like GLB.DESTINATION, GLB.DESTHOST, and so on, and then perform a Store() or a Send() on the ispec based on these values. Correspondingly, commands like AUTO; WRITE and AUTO; WRITE&CLEAR were migrated as a call to the method StoreOrSend().

This could result in unnecessary performance overhead for systems that do not use the external HUB feature. To handle this, an LDL+ migration option has been provided within the Import utility to control this behavior (in Import, select "Advanced Settings" and press "LDL+ Migration Settings" button).

The following are the available options:

Default() – Select this option to migrate all AUTO; WRITE (and AUTO; WRITE&CLEAR) commands as Ispec.Store() or Ispec.Send() or Ispec.StoreOrSend() depending on the ispec properties (for example, IsExternal, HasPresentation).

As Ispec.Send() – Select this option to migrate all AUTO; WRITE (and AUTO; WRITE&CLEAR) commands as a simple call to Send().

As Ispec.Store() – Select this option to migrate all AUTO; WRITE (and AUTO; WRITE&CLEAR) commands as a simple call to Store() rather than the more complex logic to handle the different behaviour for Store() and Send(). This has the dual benefit of the logic being migrated as simpler code (easier to read) and it performs better.

File Specifying ispecs to be migrated as Store() or Send() – Select this option to further fine grain control over the migration at an individual ispec level. Here the user can select a text file that contains a separate list of ispecs that have to be migrated as Store() and ispecs that have to be migrated as Send(). For example,

Consider a model containing six ispecs – ISPC1, ISPC2, ISPC3, ISPC4, ISPC5 and ISPC6. We want to control the migration such that AUTO.WRITE; for ISPC4 and ISPC3 needs to migrate as ISPC4.Store() and ISPC3.Store() respectively. Similarly we want to migrate AUTO.WRITE; for ISPC1 and ISPC5 as ISPC1.Send() and ISPC3.Send(). Hence, the file format is as follows:

[Ispecs As Store]

:List of ispecs for which AUTO.WRITE; (and AUTO.WRITE&CLEAR) are to be migrated as Ispec.Store()

ISPC4

ISPC3

[Ispecs As Send]

:List of ispecs for which AUTO.WRITE; (and AUTO.WRITE&CLEAR) are to be migrated as Ispec.Send()

ISPC1

ISPC5

The remaining ispecs in the system (ISPC2 and ISPC6) is migrated with the default behaviour.