Creating a package using the innovator admin

Hello Samir

First, it is important to understand that packaging in Aras is not simply a matter of exporting every modified item. Aras packages are intended to transport customizations and must respect the existing package structure and dependencies. The official Package Import Export Utilities documentation discusses package dependencies, package definitions, and the need to carefully manage referenced items. Another important concept is PackageDependsOn. Aras supports declaring dependencies between packages, and the import process uses these dependencies to determine import order. If Package A depends on Package B, Package B should be imported first. The documentation also notes that if a referenced package or dependency does not exist in the target database, the import may fail because imported items can contain references to items from the dependent package.

You can find some documentation here:

Package Definition Tool

Package Import Export Utilities

Regarding your errors:

• Foreign key / MORPHAE errors usually indicate that an item is being imported before one of its dependencies exists in the target database.
  -> Sometimes you will need to use a Post Script placed in AmlDeploymentScripts\2-AfterAmlPackagesImport.
  -> When adding a property to a Poly Item, make sure all Item Type in Polysource also have this property in their own AML
• "Sequence contains no matching element in FixPropertyReferencesToSystemProperties" often points to missing or inconsistent references within the package.
  -> As an example, the package may contain a reference to a versionable item where the expected ID/config_id relationship is no longer aligned with the target database. This can happen after multiple revisions or generations.
• "An item with the same key has already been added" can occur when package contents overlap or when the same item is effectively being introduced multiple times through different package elements.
  -> You may be trying to link a Form to an ItemType that already has one (for example, modifying the OOTB Part Form instead of creating a custom Form), or importing the full AML of something that already exists in another package such as Part. Another possibility is importing an ItemType with is_relationship=1 instead of importing the corresponding RelationshipType AML only.

One common mistake is trying to package a complete AML definition for an item that already exists in another package (for example Core or PLM content). When you are modifying an existing out-of-the-box item, you generally should not re-create the entire item with action="add". Instead, the package should contain only the customization required to update the existing item, typically using action="edit" style AML. These customizations are commonly exported into the Fixes portion of a package rather than as a complete redefinition of the original item. Also remember that a Package Element may belong to only one AML package. This is an explicit restriction documented by Aras to avoid import conflicts when the same element is contained in multiple packages with different definitions. This is another reason why repackaging OOTB content can sometimes lead to unexpected import issues.

This is particularly valid for TOC customizations. You may have created a new TOC section, but the deployment actually requires modifying an existing OOTB TOC entry. Look at this example where I have fixes for OOTB items I have modified:

Another important consideration is versionable items. For ItemTypes such as Methods and other versionable objects, the Aras ID can change as new generations are created. When reviewing exported AML, it is sometimes necessary to verify that references point to the correct item and, in some situations, adjust references to the original generation rather than a later generation. Also verify that the exported AML is referencing the correct item. For versionable items, Aras exports and imports using special handling based on config_id, so it is worth reviewing the generated AML carefully before assuming the ID is correct. Failure to do so can lead to installation issues when importing into a different database.

Make sure:

• Create a dedicated Package Definition.
• Only add the customizations you own.
• Carefully review dependencies explicitly (Lists, Forms, Methods, Identities, RelationshipTypes, etc.).
• Avoid re-packaging out-of-the-box content from Core/PLM packages unless you are intentionally delivering a customization to that item.

Don't try to package too much at once. Go step by step. Once the deployment succeeds, add the next change and deploy again. For example, start with Lists and test the deployment. Then add Identities and test again. Next add Permissions, Methods, Forms, and finally ItemTypes and Presentation Configurations. This incremental approach makes it much easier to identify the XML that is causing the failure. When I have this kind of issue, that's the procedure I follow to isolate the AML causing the error.

Don't forget all CommandBar and presentation configuration when adding an Item Type:

Regards

Michael