Troubleshoot Deployment Issues

Overview

During a direct deployment or manual deployment, you may encounter errors that are often referred to under the umbrella term, deployment errors. For example, an error may occur when the deploying user is not an administrator of the object.

When an error occurs, Appian gathers and displays information on any problems after all objects in the package have been processed. This information is available in the Deploy view and the deployment log.

You can do one of the following:

• Resolve the cause of the problem as identified in the log and try again.
• Retry with only those objects that failed due to the issue identified. We recommend this approach if the package is especially large.

Deployment log

Appian generates a deployment log whenever you deploy an application or package in an Appian environment.

To access this log, click the Log link while viewing the deployment details. The log itself is titled Deployment Log, but the link label differs depending on the deployment type, as follows:

Deployment Type	Link Label
Direct deployment	Deployment Log
Manual export	Export Log
Manual import	Import Log

The deployment log details the stages of the deployment—such as the sending and receiving of the deployment request, executing database scripts, and importing the objects—and indicates whether the tasks succeeded. The log also includes any errors that occur during deployment.

This log is organized into the sections listed in the table below. The deployment type determines which sections are present in an individual log.

Section	Deployment Log	Import Log	Export Log
Request Export	No	No	Yes
Exporting Deployment Package	Yes	No	Yes
Request Deployment	Yes	Yes	No
Review Deployment	Yes	No	No
Plug-in Deployment	Yes	No	No
Executing Database Scripts	Yes	No	No
Importing Deployment Package	Yes	Yes	No
Initiating Portal Publishing	Yes	Yes	No
Initiating Post-Deployment Process	Yes	No	No
Posting Deployment Status	Yes	No	Yes

Section: Request Export

Lists details of the user's manual export request, then lists actions the source environment took to queue and initiate the manual export.

Section: Exporting Deployment Package

Lists actions the source environment took in response to a user's request to either export the package manually or initiate the direct deployment. If objects in the deployment had missing precedents, this section includes a list of those missing objects.

Section: Request Deployment

Lists details of the deployment request received by the target environment, then lists actions the target environment took in response to the request.

For direct deployments, this section contains information about the source environment.

For manual imports, this section lists identifying details about the manual request.

Section: Review Deployment

Lists actions the target environment took to review the deployment package.

Section: Plug-in Deployment

Lists actions the target environment took to install or update plug-ins from the deployment package in the target environment.

Section: Executing Database Scripts

Lists actions the target environment took to deploy database scripts from the deployment package in the target environment.

Section: Importing Deployment Package

Lists actions the target environment took while importing design objects and application settings from the deployment package into the target environment. The actions the target environment took on each object depends on the object's comparison status.

This section includes the following subsections:

• Success: Lists package items that were successfully created or updated during import.
• Not Updated: Lists package items that were included in the deployment package but were not imported. This list can include objects that contained no updates and objects with a Protected status.
• Imported Objects with Conflicts: Lists package items with a Conflict Detected status that overwrote existing objects in the target environment during import.
• Version Synchronized: Lists package items that were imported to synchronize the version histories. The items had different version histories but were otherwise identical.

Section: Initiating Portal Publishing

Lists actions the target environment took to publish portal objects imported from the deployment package.

Section: Initiating Post-Deployment Process

Lists actions the target environment took to run a post-deployment process in the target environment.

Section: Posting Deployment Status

Lists actions the target environment took to update the source environment on the status of the deployment.

Deployment errors

Deployment errors can include any of the following.

Database script errors

The target environment executes database scripts before deploying any other items from a deployment package. If the system encounters an error while executing a script, the deployment will completely stop with a Failed status. This means that the system did not run any subsequent scripts or deploy any objects from the package.

Keep the following in mind when troubleshooting a database script error:

• Depending on which database script failed and when, the database in your environment may be in a partially updated state.
• The scripts in a package execute in the order you configured when adding them to the package. If there are dependencies between scripts, make sure they appear in the correct order in the package.
• The execution order for database scrips is especially important when deploying multiple packages at once. To avoid errors and inaccuracies, scripts across packages must execute in the correct order. By default, execution order is determined based on which was last modified. However, you can manually reorder scripts to set the order that's ideal for your deployment.
• When deploying multiple packages at once, database scripts can span multiple packages. If one of the database scripts fail, identifying which package introduced the failing script may require reviewing the deployment log's package metadata.

Object errors

The deployment does not stop when errors are encountered on specific objects.

However, a problem during the import of an object may cause the import of related objects to also fail. For example, a failure to create a group type during an import would cause the import of any groups of that type to also fail. Appian does not attempt to import these groups in this case.

If a group creation fails during import, and the group exists in role maps for other objects—or is a member of another group—the other objects (or groups) will fail to import due to the missing precedent.

Version mismatch errors

In deployments with multiple packages, the deployment fails if two or more packages contain the same design object in different versions.

For example, if package A contains version 1 of a record type and package B contains version 2 of the same record type, the deployment cannot resolve which version to use. To avoid this, ensure that the same version of each design object is used across all selected packages before deploying.

Record type SQL reference name conflicts

When you create a synced record type, Appian generates a default SQL reference name. When you deploy the record type, the deployment updates the SQL reference name in the target environment to match the source environment. If the SQL reference name is already in use by a different record type in the target environment, the deployment completes with import errors and the record type is not imported.

When you use compare and deploy, Appian warns you if the SQL reference name is already in use by a different record type in the target environment. To avoid this error, resolve the conflict before deploying by changing the SQL reference name in either the source or target environment

Example error

The following example illustrates the log entries that may be generated when an object reference is not included in the package, and is not present in the target environment.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

In this instance, an imported process model listed an individual user for the assignment of an activity. As a best practice, Appian recommends using groups for assignments instead. Otherwise, ensure that the target environment has a user with the same username, prior to importing the application.

Feedback