I'm trying to create a package using Innovator Admin to capture a set of changes I've made to an Aras instance. The changes include custom ItemTypes, RelationshipTypes, Forms, Sequences, and various other modifications.
My current approach is using the "Recently Modified" filter with "Modified By = Innovator Admin" and selecting everything that comes up. I then follow a rough dependency order when building the package (ItemTypes before Properties, Properties before Forms etc).
However when I try to install the package to a fresh database I get errors. The main ones I've run into are:
System.InvalidOperationException: Sequence contains no matching element in FixPropertyReferencesToSystemProperties
An item with the same key has already been added for certain RelationshipTypes
Foreign key constraint failures on the MORPHAE table when a referenced ItemType hasn't been installed yet
A couple of specific questions:
Is there a correct and reliable export order for package items in Innovator Admin?
Are Properties bundled automatically with their parent ItemType on export, or do they need to be added explicitly?
Is there a better way to capture all changes made in a given period, ideally something more reliable than the Recently Modified filter?
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.
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.
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:
