This page explains how import inspection can help you avoid partial or problematic deployments. Before importing an application, a patch, or Administration Console settings, you should inspect and evaluate the package contents. No objects are created or updated during inspection.
In this article, the source environment is the environment from which the package was exported and the target environment is the environment where the inspection and import is taking place. Some common deployment path examples include:
| Source Environment, deploys to… | Target Environment |
|---|---|
| Development | Test |
| Development 1 | Development 2 |
| Break Fix / Hotfix | Development |
| Test | Production |
The object comparison status describes the difference between a source and target environment or a package and target environment. It indicates how the object will behave on import. See the table below for more details:
| Status | Object Exists in Target Environment | Object Will Be Imported |
|---|---|---|
| Changed | Yes | Yes |
| Conflict Detected | Yes | Yes |
| New | No | Yes |
| Not Changed | Yes | No |
| Status Unavailable | Yes | Yes |
More details about the statuses are available below:
If you need to force an import for objects with a Not Changed status, add the FORCE_UPDATE import-specific setting to your import customization file. See Managing Import Customization Files for a use case with more information on when and how to force an update.
These statuses are helpful for detecting conflicts when deploying from a Break Fix environment back to Development or between multiple Development environments. In a typical Development-Test-Production deployment progression, the statuses will allow a quick gut-check to confirm that the correct objects are being created and updated.
Inspection identifies objects with missing dependencies, data stores that don't match the schema on the target environment, and package corruption (invalid XML); it does not catch all possible errors, such as incorrect permissions or insufficiently unique names. Since you can't undo an import, it's a best practice to inspect your packages before deployment to catch any detectable package issues.
There are two ways to inspect packages in Appian: before exporting your package or before importing your package.
Comparing an application across environments allows you to create a patch and inspect it before export.
To inspect a package before export:
Note: It's important to inspect your package again on import to make sure that environment specific objects have not changed.
You should always inspect a package before completing the import to check for warnings, conflicts, or missing precendents.
To inspect a package on import:
Conflicts occur when an object is modified in the target environment and modified separately in the source environment. Objects with the status of Conflict Detected will be displayed when comparing an application across environments or when inspecting before import. This check is helpful when deploying from a Break Fix environment back to Development or among multiple Development environments. When you see this status, you should pause your deployment and investigate the changes.
It is a best practice to inspect before export AND upon import to ensure that no changes have been made between the time of export and import. To detect conflicts before export, compare your application across environments and check the application configuration status or the object list. You can click on the status link in the object list to view the differences between environments.
For more information about comparing applications across environments, see this page.
When you inspect upon import, you will be presented with your package inspection results. At the top, there is a summary of how many items in your package have problems or warnings, how many will be created or updated by import, and how many will be skipped. Underneath this summary message is detailed information about the projected import status of each of the objects in your package. The objects with conflicts detected appear in their own section, along with information about when they were last modified in the target environment.
When you click Import Package, the definition in the package will overwrite whatever is in the target environment. Since the changes in the target environment that caused the conflict are not guaranteed to be in the package, there is a risk of losing work! The Last Modified information will be captured and the importing user will be set as the designer of any imported process models with this status.
When you encounter the status Conflict Detected, you should proceed carefully since there is a chance of overwriting someone's work. When you see an unexpected conflict:
To avoid false conflicts, export your application from your development environment after upgrading from a pre-17.3 version and import it to each higher environment. This will set a baseline for your changes.
It's a best practice to include data types created from WSDLs in your application or patch package before exporting it.
If those data types are not included in your package AND they don't already exist on the target environment, they'll be listed as problems in the inspection results. Data types that are normally created by the Call Web Service Smart Service or webservicequery() function during import cannot be created by the package inspection process.
