How do you resolve “Unresolved Elements”?

A “2Pack” is a compressed XML file used for data import and data export of objects. This feature makes it easier  to replicate the said objects from one environment to another.   The process of importing a “2Pack” is called “Packing In” while the process of exporting a “2Pack” is called “Packing Out”.  This feature avoids recreating objects like windows, process, data  or tables from scratch.  

However, packing in and out can be challenging at times. It is difficult to correct a wrongly packed in “2Pack” in a system.  Thus, you must always have a deployment process before deploying anything to the Production environment.  “2Packs” must be tested in a development or sand environment before applying changes to a production system.  It is also advisable to have a backup of a Production environment in case you need to restore your latest environment.

The most common error message associated with “2Packs” is the message “Unresolved Elements”.  Do not panic when you encounter this message as I did the first time it happened to me! This message is simply telling you to review all the objects in your “2Pack”.  Are the objects you packed-out complete? Do you have missing dependencies? For example, you may have packed out a Window with a required customized Dynamic Validation and/or Info Window which was not included in the “2Pack” and is not available in the destination environment.  Are you packing in an object that already exists in the new environment? For example, you may have packed-in a field called “ABC_Field” that already exists in the new environment.

Where do you start to fix the “Unresolved Elements” issue?  The answer is – the log file. This file is your best friend to resolve “2Pack” issues.  You need to open the log file*, search for “Unresolved Elements” and determine the issue.  Specifically, you need to go through all the list to understand the issue. See example below:  

Do you see it?  Do you see the issue? You need to look at the actionable keywords.  In the above, the underlined and italicized keywords are pointing to a specific story.  First, a window field represented by  AD_Field_ID = 1085  failed to insert/update. Second, the field failed to insert/update because there is an issue with the Validation Rule i.e. AD_Val_Rule_ID.  Third, we need to resolve the  UUID in AD_Val_Rule_UU=’febdcc60-7727-4565-9c4c-38bb40fe14d1′ to fix the issue.  Once you understand the issue, the hard part is solving the issue. You may need to go through several solutions before you can congratulate yourself with a cup of cappuccino. 

In my experience, the most common cause when inserting a field similar to the situation above is – the same Validation Rule already exists in the destination environment.  Sometimes, it is just a matter of updating the AD_Val_Rule_UU of the destination environment to match the AD_Val_Rule_UU of the source environment in order to resolve the issue.  The solution to an issue may depend on the specific problem at the time. 

A “2Pack” is a powerful iDempiere feature that can make life easier to re-create objects.  However, hiccups may occur from time to time.  When it does happen, developers will always have the log file to help them resolve the issue.

If you are interested in learning more about “2Packs”: see these links : 

https://wiki.idempiere.org/en/Developing_Plug-Ins_-_2Pack_-_Pack_In/Out.

https://wiki.idempiere.org/en/NF1.0_2Pack_Revamped

https://groups.google.com/g/idempiere/c/MjEWI8MeESY/m/qEw24q6ZAAAJ

* in case you don’t know – logs are in /opt/idempiere-server/log or open via the OSGI console