AML Packages

The first step in understanding the use of the Package Import Export Utilities is to understand the structure of package AML files on disk and the corresponding manifest file.

The File Structure

The folder structure of a core package can be defined by careful use of the Package Definition name. Let’s use the core Dashboard package as an example. Note that the fully qualified package name of this Package Definitions is com.aras.innovator.dashboard. When exported, this package is exported to a hierarchal structure as such:

Innovator/

Imports/

Com/

Aras/

Innovator/

Dashboard/

Any new packages are treated as such and allow for the export of packages in this manner.

Non-core packages do not use this same rule for export even though the solution packages have a fully qualified name. I.e., this name is not translated into a directory hierarchy of com\aras\... Instead, the three solution packages always export to the predefined folders:

Solutions/

PLM/

Import/

Project/

Import/

QP/

Import/

The Manifest File

The manifest file contains information about what packages can be processed by the utilities, dependencies between packages, and where to find the package AML files.

Here is an example of a manifest file:

</package>

</package>

</imports>

The package tag

The package tag can have the following attributes:

name: a unique, fully qualified name of a package.
path: a path to the directory that contains the package AML files.

Note: A path to the package AML files could be either absolute or relative; in the case of a relative path, it is relative to the location of a manifest file itself.

For all non-core packages, this path is the path to the directory where the folders for the different AML types are stored. From our example in the previous The File Structure section, if the manifest file for the com.aras.innovator.solution.PLM package is placed in the Solutions folder, the path to the PLM solution AML points to the \PLM\Import folder where the \ItemType, \Form, etc. folders are.

A path relative to the location of the manifest file itself is used, and the package tag would be written so:

</imports>

For core packages (admin, core, dashboards, and preferences), the path to package AML files is calculated based on the specific package name. For core packages, the ‘.’ in the fully qualified name of a core package is replaced with a ‘\’ when calculating the file path based on these specific package names. From our example in the previous The File Structure section, if the manifest file for the com.aras.innovator.dashboards package is placed in the \Innovator\Imports folder, then the package tag would be written so:

</imports>

The dependson tag

This tag contains the information about packages that the package defined in the package tag depends on. This also populates the Package Depends On Relationship of the Package Definition Item in the database. This information is used for creating in the database dependencies between packages. If the package referenced in the dependson tag is one of packages imported in the import session, then it is loaded prior to the package that depends on it; otherwise, it’s assumed that the package referenced by the dependson tag already exists in the target database.

Note: If it does not, the import might fail because an imported package might contain references to some items from the dependson package.

Multilingual Packages

The Aras Innovator platform includes a “Multilingual String” datatype that enables users to view and edit specific properties in the supported language of their choice. These multilingual properties may be managed with the Import and Export Utilities.

By default, exported packages contain only the English values for multilingual properties.

<AML>

<allow_private_permission>1</allow_private_permission>

...

<is_versionable>0</is_versionable>

<label>Field</label>

<label_plural>Fields</label_plural>

<large_icon>../images/Properties.svg</large_icon>

...

However, packages may optionally be exported with multilingual property values for additional languages. The following example shows the same package item with French, German, and Japanese values in addition to the default English. Each multilingual property will be represented with a tag for each language value present in the database.

<AML>

<allow_private_permission>1</allow_private_permission>

...

<is_versionable>0</is_versionable>

<label xml:lang="en">Field</label>

<i18n:label xml:lang="fr">Champ</i18n:label>

<i18n:label xml:lang="de">Feld</i18n:label>

<i18n:label xml:lang="ja">フィールド</i18n:label>

<label_plural xml:lang="en">Fields</label_plural>

<i18n:label_plural xml:lang="fr">Champs</i18n:label_plural>

<i18n:label_plural xml:lang="de">Felder</i18n:label_plural>

<i18n:label_plural xml:lang="ja">フィールド</i18n:label_plural>

<large_icon>../images/Properties.svg</large_icon>

...

Note: Multilingual property tags are indicated using the standard internationalization or “i18n” language codes.