Inspect Package

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.

Source and Target Environments

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

Inspect Environments

Object Comparison Statuses

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:

  • Changed:
    • This object was modified in the source environment and exists on the target environment.
    • This is the typical status you should expect when you make changes in a lower environment (e.g. Development) and deploy them to a higher environment (e.g. Test).
    • When you import, the object's definition will be updated in the target environment. The Last Modified information will be updated and the importing user will be set as the designer of any imported process models with this status.
  • Conflict Detected:
    • This object was modified in the source environment and separately in the target environment.
    • This is the typical status you should expect when you make changes in a lower environment (e.g. Development) and a user made changes in the higher environment (e.g. Test) separately.
    • Make sure you address all objects with conflicts before importing your package. Otherwise, when you import, the object's definition will overwrite the definition in the target environment. 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.
  • New:
    • This object was created in the source environment, but does not exist on the target environment.
    • You will commonly see this status as you are building new functionality.
    • When you import, the object will be created in the target environment. 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.
  • Not Changed:
    • This object was NOT modified in the source environment and exists on the target environment.
    • This status will typically appear when you export full applications, rather than patches that only contain your changes.
    • When you import, the object's definition will not be updated in the target environment because there are no updates to make. The Last Modified information will remain the same as it was pre-import and no change will be made to the designer of any process models with this status.

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.

  • Status Unavailable:
    • This object exists on the target environment, but the system doesn't have enough information to determine whether there's a conflict, the object was changed, or the object was not changed.
    • This status will apply to packages exported from a version of Appian (e.g. 17.2) where the inspection status was not supported for that object type.
    • When you import, the object's definition will be updated in the target environment. The Last Modified information will be updated and the importing user will be set as the designer of any imported process models with this status.

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.

How to Inspect a Package

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.

Inspect Package before Export

Comparing an application across environments allows you to create a patch and inspect it before export.

To inspect a package before export:

  1. Create a patch while comparing your application across environments.
  2. Inspect your patch in the Inspect Patch step of the wizard.

Note: It's important to inspect your package again on import to make sure that environment specific objects have not changed.

Inspect Package before Import

You should always inspect a package before completing the import to check for warnings, conflicts, or missing precendents.

To inspect a package on import:

  1. Click one of the following buttons in your target environment, depending on your package type:
    1. Import Application for full application packages in Appian Designer
    2. Import Patch for patch packages in the application
    3. Import for admin setting packages and related application or patch packages in the Administration Console
  2. Upload your package zip file and related import customization file (if applicable).
  3. Click Inspect and review the inspection results.

Conflict Detection

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.

compare conflict detected

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.

Inspect Application

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.

Addressing Objects With Conflicts

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:

  1. If you are comparing objects across environments, view the differences for the object with the Conflict Detected status by clicking the status link.
  2. If you are inspecting before import, examine the Last Modified in This Environment information for clues about who might have made a change before you. If possible, talk to the user who made the change in order to understand what changes they made and why. Also consider which environments these changes have been made in, e.g. are there running instances to consider in Production?
  3. Depending on the results of this investigation, do one of the following:
    1. Proceed and overwrite the changes in the target environment.
    2. Export the object from the target environment and import it into the source environment, overwriting changes in the source environment. Build and export an updated package from the source environment.
    3. Manually merge the changes in the source environment and then build and export an updated package. Note: The objects will still appear in the Conflict Detected status, but the manual merge means you won't be overwriting changes.

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.

Inspecting Data Types from Web Services

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.

FEEDBACK