A custom data type (CDT) is a designer-defined data structure that represents a logical grouping of related data, such as Employee and Contract. CDTs can be used to read from and write to a database table, to store information within a process, or to define inputs or outputs of a web service or Appian plug-in.
All CDTs can be downloaded and imported as XML Schema Definition (XSD) files. For information about XSDs, see the Supported XSD Elements and JPA Annotations page.
The life cycle of a CDT depends on where the authoritative data structure for your application is designed. See the diagram below for a high-level overview of the most common data type life cycle patterns.
The table below describes the properties for data types.
|Name|| Names must start with a letter or an underscore, and may contain only letters, numbers, hyphens, periods, and underscores, e.g.,
|Namespace|| Formatted as a URI, e.g.,
|Description||Displayed in data type pickers in the process modeler|
|Last Modified||Updated when the data type is created, and every time that the data type is modified|
|Source|| Indicates how the data type was created or last modified:
|Field Names||Field names are case sensitive, and must be unique within one data type|
|Field Types||Fields can be of the following types: primitive, custom. Other Appian types are not available.|
Note: When using multiple application servers, the data type visibility is only updated in the cache of the application server you are logged into. The cache of any other application server is updated upon the next restart. To avoid restarting your application servers, log into each application server individually as this updates the data type visibility in each application server's cache.
Users in the designer role can create data types in the following ways:
@Tableannotation, the new data type will also map to the Employee table. If the CDT will be used to read data from or write data to a database table, Appian can generate the database table for you.
CDTs are identified by their combined name and namespace. When creating new data types from scratch, an existing CDT (duplicating), or a database table, the name and namespace must be unique. If you create a CDT by importing an XSD file or through a WSDL or Appian plug-in, the name and namespace do not have to be unique. This allows you to update existing CDTs in the system through these methods without having to delete them first.
Note: If you think that you could be accidentally replacing a deleted data type by using the same name and namespace, run impact analysis on the data type after creation to see if any objects depend on a previously deleted data type with the same name and namespace.
Custom data types are edited in different ways based on how they were created, how they are configured, and what they are used for. The following table links to reference information for each scenario.
|Method or Usage||How to Edit|
|Mapped to a database table||See here if making changes in the database first or here if using Appian to update the table|
|Generated by WSDL||See the update section on the Call Web Service Smart Service page|
|Generated by Appian plug-in||See the edit section on the Custom Data Types from Java Object page|
|Imported with multiple types from an XSD||After making the desired edits in the XSD file, navigate to the application. From there, click "New", then "Import XSD."|
Before updating a data type, do the following:
The name and namespace of the data type cannot be changed as they form the data type's universally unique identifier (UUID). Deleted types can be replaced from the application when creating a type from scratch or duplicating an existing type.
After updating the data type, a new version is created unless the only change is to the data type description or its visibility in data type pickers. When a new version of a data type is created, all objects (excluding running processes) immediately begin using the new version of the data type.
Deploying a new version of a plug-in data type will only replace the existing active data type if the plug-in version number is greater than the currently deployed plug-in version.
Data stores that include the updated data type will also immediately begin using the new version. This means that data stores can be negatively affected even if you only add fields, unlike rules and interfaces. To ensure that you do not accidentally invalidate a dependent data store's mapping to the database, you will receive a warning dialog when you attempt to update data types through the following means:
Back-end data type updates (importing an XSD in a patch or application and updating data types through an Appian plug-in) provide logs detailing the effect on dependent data stores, rather than a warning dialog.
If a deleted data type is updated by creating a new data type with the same name and namespace, you will NOT receive a warning about dependent data stores. The data store will immediately begin using the new data type structure, but the underlying database schema will not be automatically updated (even if the Automatically update database schema option is enabled).
When a data type is deleted, it is retained in the system so that objects can continue to function correctly even if referenced data types are deleted. Deleted types, however, will no longer appear in the Appian Designer or as choices in type pickers.
Upon deleting a data type, references to that data type will have a version number appended in the form of a caret (^) + version number. For example:
Objects that use a deleted data type can be exported and on import, will attempt to reference the most recent version of the data type. If the most recent version of the data type is deleted, import of the dependent object will still succeed. If no data type exists on the destination environment, import of the dependent object will fail.
Appian recommends that you use the Outdated Type References Metrics Log to find all objects that reference deleted data types and remove those references.
There are some configurations for CDTs that cannot be accessed through the data type designer. If you need to modify those configurations, you can download the XSD for the data type and re-import it to create a new version of the data type.
To download the XSD file for a data type, click Download XSD in the settings menu of the data type designer. The following types cannot be downloaded as XSD:
Once you have made the necessary changes to the file, click Create New Version from XSD in the settings menu and upload the new version of the XSD.
When deploying data type edits to a production environment, all design objects will be updated to use the latest version of the data type when it is imported. Dependents of data types only need to be included in the import package if you have made changes to their definitions.
When a package containing data types is imported, only data types that have been changed or depend on a data type that has been changed will be updated.
See also: Deploying Data Types
For details on how data type data are cast, see Casting Custom Data
Variables of simple custom types that extend other simple custom types can be saved into each other because they both extend from a simple system type (like Text).
Variables of custom types that extend other custom types often cannot be successfully used to save data into each other, because of the mismatch of fields. At runtime, any fields of a derived data type that are not present in the parent data type cannot be mapped. If the parent data type is an abstract custom type with no fields, no data can be saved into it. Therefore, it is best to avoid abstract data types and extending data types.
A data type does not have individual security settings. Only users in the designer role can perform any action on a data type.
The following actions can be completed by each user type in the designer role:
|Actions||System Administrator||Basic User|