This page is about general rules about deploying packages and object-specific rules in Appian.
To learn more about preparing deployment packages, see this page.
To learn more about deploying packages to target environments, see this page.
Appian supports direct deployment, external deployment, and export/import for the objects listed below.
For the images displayed in the subsections below, the following key applies:
In Appian, you can deploy an entire application to a target environment, either directly, using programmatic APIs, or using manual export/import.
When you deploy the entire application, the deployed package includes:
For example, a process model and a site might be associated with an application named Expense Tracking. If you deploy the entire Expense Tracking application, the deployed package includes the process model object and the site object.
If an application already exists in a target environment, deploying the application into that environment overwrites the application configurations and the set of associated objects.
You can deploy both published and unpublished applications. On deployment, the state of an application is the same as it was when deployed or exported.
In Appian, a document (or file) resides in a folder, which resides in a Knowledge Center, which resides in a Community, which might reside within another Community. A document export includes the document, the document properties, and a reference to its parent object (such as the folder where the document resides). A Document, Folder, Knowledge Center, or Community might also be associated with a forum.
The image above illustrates the relationships between Document Management objects. Items displayed in red indicate required objects. Dashed lines indicate object references. Objects and references fully contained within an object's border indicate items that are automatically included within an object when it is exported.
The objects in the hierarchy must each be selected for inclusion in your application. An export of a document does not include the actual parent object of the document, only the awareness of the parent object. Imports fail if the necessary parent object is not present.
If a document already exists on the server that you are importing onto, a new version of the document is created. For documents and document containers, any existing object properties are overwritten by an import.
When exporting a content container (such as a Community, Knowledge Center, or Folder) only the selected container is exported. The contents are not exported.
If you do not have the necessary user rights to add or update the object being imported, then the import fails. For example, if an import package contains a folder that resides under a given Knowledge Center, the user importing the folder must have the right to create a folder in that Knowledge Center.
The ZIP file of Knowledge Center or Folder downloaded from the Document Management interface using the Download toolbar action is not importable from the Applications view. Instead, perform a bulk upload from the Documents tab.
See also: Folder and Document Management
If you've created Document Management objects using Appian's Java API, be aware that the
system flag is no longer used. It is ignored when importing documents and document containers.
Group application objects can be exported then imported into another environment.
All properties of group objects are exported except for users listed as members in the group object. On export, group objects do not retain references to individual users listed in the members tab of the group, but do retain references to member groups in this tab. The administrators tab will export references to both users and groups.
All manual imports - packages, applications, and administrator console settings - occur asynchronously. This means that Appian queues your import as a background process, allowing you to continue development in Appian Designer while the system processes the import. You can review the status of your import from within the deployments view. Additionally, an email is sent when the import is complete.
Importing new or modified group objects requires that the user have sufficient privileges in the destination environment to create or modify groups.
When importing a group object, references to users or groups that do not exist in the destination environment are discarded.
To preserve the integrity of group properties and relationships, it's best to export all related group and group type objects together.
When importing a group object into an environment where a group with the same UUID already exists, all properties of the inbound object overwrite the properties in the destination object except for group membership (users and member groups listed in the members tab); the inbound object and the destination object member lists are merged.
This means references to users and member groups in the destination object cannot be deleted as a result of importing an object without those references.
A group object may fail to import when:
Group types allow you to specify attributes (required or optional) for each group of that type. Required attributes must be input when each new group (of the type) is created. It is possible for these attributes to vary from environment to environment for the same group type. If the list of attributes of an imported group does not match the list of attributes of the group type in the destination environment - and the import package does not include a corresponding group type - the imported group's list of attributes is updated to match the group type in the destination environment. All groups of a group type must have the same set of attributes.
Exporting a group type packages its properties (the list of attributes and attribute values associated with all groups in the group type) into a zip file for import on another environment.
When an import package includes a group and its group type - but the list of attributes of the group do not match the destination environment - the import package attributes are applied to the destination environment. The group type is imported first, followed by the group.
If you exclude the group type from the export package, and an imported group's attributes do not match those of the existing group, the result of the import preserves the values of the attributes in the destination environment.
On import, if the same group type exists on the target server (identified by UUID), all group type properties and its list of attributes are overwritten by the imported group type, except the values of the attributes. Attribute values are not overwritten on import. You cannot update the default values of group type attributes.
If a group type with an existing name (but different UUID) is imported, the import of the group type fails. Group type names must be unique within one installation (instance) of Appian.
The names of system group types cannot be updated.
If two or more attributes of a group type have the same name, only the first attribute is added to the group type. Group type attributes must have unique names.
Process models and process model folders can be exported for import onto another server. Process instances are not exported.
Process Model Folders
A process model folder export includes the folder's properties and user rights. The contents of a process model folder (any subfolders or process models) must be selected individually for export as well, and are not exported automatically with the folder.
The My Models folder only exists on the server when it is used for the first time. This occurs when a subfolder is created within it, when a process model is placed in it (or if the folder is renamed for any reason). Only after the folder has been used is it exportable. For the sake of import and export, the My Models folder is treated as any other process model folder, and is created at the root level (in the left navigation of the Processes view) when imported.
API DEVELOPERS ONLY: The ProcessModelFolder
isSpecial attributes are not exported. On import, the
type attribute is set to
TYPE_COMMUNITY, if the folder has no parent. Process model folders that have a parent folder inherit the type of the parent folder.
A process model resides in a process model folder. A process model export includes its properties (name, description, etc), definition (process flow), user rights, a reference to the process model folder where it resides, and a reference to any custom dashboards. A process model can include references to many other object types. A referenced object must be present in the destination environment - or you must include it in the application package - to successfully import the process model.
When exporting a process model, the latest published version is exported (if published).
On import, process models are published as a new version.
If a process model contains a Send Message event that specifies another process model for its destination configuration, and if the model generally targets a process model, rather than a specific Receive Message event in the process model, the process model (with the Send Message event) can be imported - but not published.
If a process model contains a smart service that stores passwords, such as the Query Database and Call Web Service smart services, the passwords are not exported.
If a process model contains an Escalation Task that uses rules and/or constants in an expression for the task recipient, the rules and/or constants are not exported.
When an import package contains a custom data type (data type) with the same name and namespace as a data type that already exists in the destination environment, all objects excluding running processes will be updated to use the imported definition of the data type. Additionally, any dependent objects in the import package will reference the new version on import. Data types in the import package that are detected as Not Changed on inspection will not be updated unless they depend on a data type that is updated.
When importing a package containing data types, the data types complete import first and then the rest of the design objects in the package import. If one data type fails to import, the other data types in the package and their dependent objects will also fail to import, in order to preserve the integrity of the data structure.
Note: Since data type references in the package are updated on import, ensure that all objects are referencing the latest versions of all data types on export. If outdated references are exported, unexpected behavior changes or errors can occur at runtime because references were updated on import. There could be a brief window of time when the data types in the package have imported but the updated design objects that depend on those data types have not yet imported, therefore it is recommended that you always make compatible changes to the data type.
Data type metadata is not imported. Imported data types take the following properties:
XSD Importis listed as its Source.
There are special considerations when dealing with data types that are created from WSDLs configured in Call Web Service smart services or webservicequery() functions. If the data types are not included in the application, they will be created on the target environment at the time of import by calling the WSDL using the following process:
This can increase import time and could lead to data type structure mismatches if the WSDL has changed.
Best Practice: Always include data types created from WSDLs in the application created in the development environment before exporting it.
See also: Call Web Service Smart Service and webservicequery()
Data stores can be added to your application packages for export and import.
Exporting Data Stores
When exporting a data store, the data source JNDI name is also exported.
Importing Data Stores
Expected Results when Importing Published Data Stores:
The following results occur when importing an application package that contains a published data store.
|Data Store Version on Destination System||Result when Publishing Succeeds||Result if Publishing Fails|
|None||A new published version is created.||
|Draft||A new published version is created. The draft version is discarded.|
|Published, without a subsequent draft version.||A new published version is created.||
|Published, with a new draft version.||A new published version is created. The destination environment draft is discarded.|
Expected Results when Importing Draft Data Stores:
The following results occur when importing an application package that contains a draft (unpublished) data store.
|Data Store Version on Destination System||Result on Import|
|None||A new draft version is created.|
|Draft||The draft in the destination environment is overwritten by the draft in the application package.|
|Published, without a subsequent draft version.||A new draft is created; the published version is not affected.|
|Published, with draft||The draft version in place is overwritten using the draft in the application package.|
Reports are managed as documents for export and import. References are retained by reports after export and import, except for certain contexts. Supported references are listed when using the Missing Precedents tool in the Appian Designer.
See also: Missing Precedents
The following references are retained on import when included in an application package.
Reports exported prior to Appian 6.0.2 do not include these references. Export the report again using an upgraded version of Appian to enable the references.
When a report definition specifies a process instance context, the context will not be preserved after the report is exported. (Individual process instances cannot be exported or imported.) The report context must be reconfigured after import. This does not impact reports without a context, or those that take a run-time context (from a dashboard when shown in a Report Channel, or by prompting the user to select a context).
Rules folders, rules, and constants can be exported and imported onto another server.
The Rules folder export includes its properties, user rights and a reference to any parent folder. The contents of a rules folder (subfolders, rules, and constants) are not exported automatically. The rule folder must be included in your application in order to import a rule or constant.
A rule or constant export includes its properties, definitions, user rights, and a reference to its parent folder. A rule definition can reference other rules and constants. A constant can reference most other object types. When exporting a rule or constant, the latest version is exported. On import, a new version of the rule or constant is created.
Duplicate names for rules and constants are not allowed. On import, if the name of the importing rule or constant matches an existing rule or constant (with a different UUID) or any interface, integration, or function, the import fails.
Constants have the option of being configured so that their value is not overwritten when the object is imported. When exporting environment specific constants, their values are not included in the object's exported XML file. Instead, the value of an environment specific constant can be preconfigured via an import customization file that will be set during the import.
The rules that govern how environment specific constants behave when imported are as follows:
For general guidance and best practices for creating, managing, and maintaining import customization files, see Managing Import Customization Files.
A connected system export includes its properties, user rights, and a reference to its system logo.
Duplicate names for connected systems are not allowed. On import, if the name of the importing connected system matches an existing connected system (with a different UUID) the import fails.
For environment-specific values, see the page for each connected system.
If you are deploying data source connected system objects to other environments, review the Data Source Connected System page for additional steps that you may need to take.
An integration export includes its properties, definition, user rights, and a reference to its parent folder. An integration definition can reference rules and constants. When exporting an integration, the latest version is exported. On import, a new version of the integration is created.
Duplicate names for integrations are not allowed. On import, if the name of the importing integration matches an existing integration (with a different UUID) or any interface, rule, constant, or function, the import fails.
The following integration fields automatically support environment specific values:
When exporting environment specific integration fields, their values are not included in the object's exported XML file. Instead, the value of an environment specific field can be preconfigured via an import customization file that will be set during the import.
The rules that govern how environment-specific integration fields behave when imported are as follows:
For general guidance and best practices for creating, managing, and maintaining import customization files, see Managing Import Customization Files.
When exporting feeds, the feed properties and user rights are included.
System objects are created automatically by Appian, and can be included in your application packages for export. Examples of system objects include system reports, the System Knowledge Center, and other objects such as the default process dashboard page.
System objects can be exported and imported. Each system object is given a predefined UUID (also called a system UUID) with the format
SYSTEM_<OBJECT-TYPE>_<OBJECT-NAME> that is the same on each installation of Appian. This means that on import, the corresponding system object on the target server is updated.
The following system objects are not listed as application precedents when scanning an application using the Missing Precedents tool.
If you modify one of these system objects, and you want to include it in your application, you can select it in the same manner as other objects of that same category.
See also: Application View
On This Page