Inspect Package

Before importing an application, a patch application, or Administration Console settings, you should inspect and evaluate the package contents. As it is not possible to undo an import, you can use inspection to avoid partially deploying your package when there is an import problem. 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

image:inspect_environments.png

How to Inspect a Package

Inspection identifies objects with missing dependencies, data stores that don't match the schema on the target system, 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.

To inspect a package:

  1. Click one of the following buttons in your target environment, depending on your package type:
    1. Import Application in Appian Designer
    2. Import Patch in Application Designer
    3. Import in the Administration Console
  2. Upload your package zip file and related import customization file (if applicable)
  3. Click Inspect

Interpreting Package Inspection Results

After you click Inspect, 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.

image:inspect_application.png

Change Statuses

Objects with no detected import problems appear in the Success section. For these items, inspection performs additional analysis to generate a Change Status, which describes how the object in the package compares to what exists in the target environment and, therefore, what type of change the import will make. The available change statuses have the following unique characteristics:

Change Status Object Exists in Target Environment Object Will Be Imported
Conflict Detected Yes Yes
Changed Yes Yes
New No Yes
Not Changed Yes No
Unknown Yes Yes

More details about the change statuses are available below:

  • Conflict Detected:
    • This object was modified in the source environment AND separately on the target environment.
    • When you see this status, you should pause your deployment and investigate the changes.
    • When you click Import, the definition in the package will overwrite whatever is in the target environment. Since the changes in the target environment 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.
  • 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 click 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.
  • 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 click 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 click 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.

  • Unknown:
    • 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 pre-17.3 versions of Appian and objects for which the change status analysis is unavailable. Change status analysis is not yet available for the following objects types:
      • Connected System
      • Data Store
      • Data Type (Note: the Not Changed status is available, see Deploying Data Types)
      • Feed
      • Group and Group Type
      • Process Model and Process Model Folder
      • Report
      • Web API
    • When you click 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 change 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.

Addressing Objects With Conflicts

When you encounter the status Conflict Detected on inspect, you should proceed carefully since there is a chance your import will overwrite someone's work. When you see an unexpected conflict:

  1. Take note of the object(s) and cancel the import.
  2. Search for each affected object in the target environment. Examine the Last Modified information for clues about who might have made a change before you.
  3. Talk to the other person who edited in order to understand what changes they made and why.
  4. Look at the object definition in the target environment and compare it to the source environment. Consider which environments these changes have been made in, e.g. are there running instances to consider in Production?
  5. Depending on the results of this investigation, do one of the following:
    1. Import the package as-is 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 Change Status will still show as Conflict Detected, but the manual merge means you won't be overwriting changes.

To avoid false conflicts, export your application from your development environment after upgrading to 17.3+ and import it to higher environments. This will set a baseline for your changes.

Inspecting Data Types from Web Services

Data types that are normally created from a WSDL during import cannot be created by the package inspection process. Instead, missing data type dependencies of the Call Web Service Smart Service or webservicequery() function are listed as problems during package inspection. This does not occur when the data types are already present on the target system or included in your package.

For this reason, it's a best practice to include dependent data types created from WSDLs in your application or patch package before exporting it.

FEEDBACK