Certain configuration steps are required for configuring your maintenance scripts after you install the application. You can also optionally modify a number of different parameters and settings used to better suit your applications. This page details both. Consult the table on the Custom Configurations page to determine whether restarting the application server is required in order for the configuration change to take effect.
The following post-installation configuration steps are required on every system.
Use a job-scheduler, like cron or a Windows Scheduled Task, to clean up your old engine files, logs, and process archive files.
Cleanup Checkpointed Appian Engine Files
The Appian Engine Servers write all transactions to disk and persist all data on disk. The Appian Engine Servers also retain an image of their data in RAM for processing. These files on disk are rolled over (checkpointed) to clear the transaction log and reduce the startup time required for an engine. Use the cleanup script to remove aging .kdb files. If you do not implement the cleanup script for the engine files, you will eventually utilize excessive disk space.
1 <APPIAN_HOME>/services/bin/cleanupArchives.sh --keep 3
Cleanup Appian Log Files
Appian logs important system events and sends alerts for errors. These settings are configurable.
If left unmanaged, log files can consume too much disk space. These files must be cleaned up at regular intervals.
Appian log files are rolled over as needed. The cleanup script is used to move aging log files to a backup location and delete them. Be sure to create the directory at
/<BACKUP_SERVER>/logs before running the script.
1 <APPIAN_HOME>/server/_scripts/cleanup.sh logs -target /BACKUP_SERVER>/logs –keep 3
See also: Data Maintenance
Cleanup Process Archives
Appian processes are used for reporting. The process archives must be configured according to your historical reporting needs. Balance your reporting needs against the need to limit the size of your Execution Engines.
1 <APPIAN_HOME>/server/_scripts/cleanup.sh processes -target /<BACKUP_SERVER>/ap –keep 100
By default, completed and canceled processes are automatically archived after 7 days. This setting is configurable depending on your policy on process archiving and available system resources. Use the cleanup script to move process archives to a backup location if you need to conserve disk space. Be sure to create the directory at
/<BACKUP_SERVER>/ap before running the script.
See also: Managing Process Archives.
Whether you have a single server or a load-balanced configuration with multiple server hosts, your end-users should use a single URL to access your Appian installation. Appian needs to know the site's URL in order to construct links. Appian breaks down the site URL into the following properties, which can be set in your
By default your site will use HTTPS for the
SCHEME. HTTPS is required for production systems. If you wish to run a non-production site over HTTP instead of HTTPS, set the following property in custom.properties. This property also controls whether or not the
secure flag will be set on cookies.
SERVER_AND_PORT property to specify the fully qualified domain name of the site's URL.
The default port numbers are
SCHEME is set to
SCHEME is set to
HTTPS. No port number setting is needed for these ports.
SERVER_AND_PORT property controls the site URL accessed by end-users, but for security purposes certain types of content are served from two different URLs:
Use the following properties to specify the fully qualified domain name of each of these URLs in custom.properties:
DYNAMIC_SERVER_AND_PORTmust each use a different domain. These must be different domains, not just separate subdomains.
.co.uk). For sites using an internal domain structure that is not based on a standard top-level domain, set the property
conf.suite.DISABLE_STRICT_DOMAIN_SECURITY=true. This configuration only applies when using a non-standard top-level domains.
Example when using a standard top-level domain like
1 2 3 conf.suite.SERVER_AND_PORT=www.example.com:8080 conf.suite.STATIC_SERVER_AND_PORT=www.example-static.com:8080 conf.suite.DYNAMIC_SERVER_AND_PORT=www.example-dynamic.com:8080
Example when using a non-standard top-level domain like
1 2 3 4 conf.suite.SERVER_AND_PORT=www.example.corp:8080 conf.suite.STATIC_SERVER_AND_PORT=www.example-static.corp:8080 conf.suite.DYNAMIC_SERVER_AND_PORT=www.example-dynamic.corp:8080 conf.suite.DISABLE_STRICT_DOMAIN_SECURITY=true
SERVER_AND_PORT, the default port numbers are
SCHEME is set to
SCHEME is set to
HTTPS. No port number setting is needed for these ports.
Why do I need to register separate domains for these URLs?
Separate domain hosting is a recognized practice for securing user-uploaded files and third-party web content. Google rolled out the
googleusercontent.com domain in 2012, while GitHub announced their
githubusercontent.com domain in 2014 for the same purpose.
For more information about top-level domains and how they are used to restrict certain browser behaviors, see the Public Suffix List maintained by Mozilla.
Exclude the following files from your server’s anti-virus software:
Locking these files or otherwise interfering with them while the system is running, as is common with anti-virus software, is known to lead to system instability.
Restrict port access to the Appian engines using a custom security token.
See also: Appian Engine Connection Restrictions.
Restrict port access to the data server using a custom security token.
Run the password script, located in the
services/bin/ directory to set a password for the service manager. This password protects against unintended administrative actions, like requesting that an engine checkpoint or shut down. In a distributed installation, this script should be run on every server that is configured to host an Appian engine, Kafka, or Zookeeper.
See also: Password Script
On 64-bit systems, modify the
server.conf.processcommon.MAX_EXEC_ENGINE_LOAD_METRIC property value in the
custom.properties file to a minimum value of 120 or higher.
See also: Configuring the Process Engine Servers.
The following optional changes can be made to your installation. Example settings are described in the Appian
custom.properties.example file found in the
appian-topology.xml.example file in
<APPIAN_HOME>/conf/ and in the configure script repository has the default topology, which configures all engines and the search server on the same machine, using the default ports. Configuring the Appian topology to something other than the default is required for any installation that does not have all components of the architecture deployed to the same machine. In order to do so:
appian-topology.xml.<your_environment>file in your configure script repository and comment out the default topology XML block in the example.
Appian does not recommend modifying the Application Context. It requires making changes to shipped files that could slow down a future upgrade process.
The default application context is
suite. You can change this to a different name by setting the following property in
You cannot set the application context to use more than one level of directories.
After modifying the application context value in
custom.properties, you also need to rename the following file to have the same name you just set in the
The amount of Java heap space available to the application can be tuned by modifying the following properties in
1 2 #conf.appserver.minHeapSize=2048m #conf.appserver.maxHeapSize=2048m
By default both values are set to 2048 MB.
The logo is configured in the Appian Administration Console.
The name is configured in the Appian Administration Console.
The ability to modify the final retry interval has been deprecated.
The copyright holder listed in the footer is controlled by the following property:
1 resources.appian.ap.application.appian.ap.appianName=Appian Corporation
The years listed for the copyright in the footer are controlled by the following property:
You can specify the
From email address listed when the system sends an alert or a password reset email, using the following properties:
1 2 conf.mailhandler.ntf_sndr_addr= conf.mailhandler.ntf_sndr_name=
The default value for the sender address is
appian-alerts@<domain> and the default email display name is set to the value of the Site Name field in the Branding page in the Administration Console.
<domain> portion of the email address is determined in the following manner:
conf.mailhandler.email.domainis the value of that property in custom.properties.
domain.tldis the domain name and top-level domain of the server if the server has a fully qualified domain name.
hostnameis the server running the application server (if there are multiple applications servers, this results in a different name for each).
appian-alerts@REPLACEME.comif all of the above fail.
See also: Appian Administration Console
Whether documents can be downloaded with the Content-Disposition header set to "inline" by using
inline=true as a request parameter is controlled by the following setting:
This property must be set to true in order to do the following:
When set to false (the default) the user is prompted to download the document instead of viewing it inline, even if
inline=true is passed in the request.
All Integration objects that are created from Connected System plug-ins are executed in a threadpool. You can adjust the number of threads in the threadpool using the following setting:
The system does not limit the overall number of activities that can be started in a process, with or without activity-chaining.
The following restrictions are, however, placed on activities that are executed in your processes:
CHAINED_EXECUTION_NODE_LIMIT property lists the maximum number of unattended node instances (that do not have forms to be completed) that can be executed between two activity-chained forms. This value is controlled by updating the following in
The default limit is
50. The maximum value is 100. No more than 100 unattended node instances can be present in between two attended nodes that form a chain. This property cannot be disabled.
CAUTION: Long activity chains - greater than 50 node instances OR 5 seconds between attended activities - are strongly discouraged because they have both an adverse effect on the performance of the system at scale and the experience of the user.
If there are more unattended node instances in a chain than the
CHAINED_EXECUTION_NODE_LIMIT, the chain is broken. Once a chain is broken, the next attended task appears in the assigned user's task inbox.
To resume a broken chain, users can complete the task from their inbox. Clicking Next in the task resumes the activity-chain. Keep in mind that after a chain is broken, you cannot step back into attended tasks that were part of the chain before it was broken.
We recommend testing changes to these settings with the largest expected cases in a test environment. Then run the sizing scripts to understand the implications for your production systems.
See also: Using the Sizing Script
To prevent accidental mass notifications, if a notification is generated for more than a certain number of recipients, the system sends a WARN message to the application server log and does not send the email, mobile push notification, or portal alert notification to the recipients.
This recipient limit is controlled by the following property in
The default value is
100. The maximum is considered unlimited with a value of
2147483647. Values less than
1 or negative numbers are considered
0 and restrict any notifications from being sent.
This setting does not, however, affect the Send Email Smart Service. If a user configures the smart service to send an email to a recipient list that exceeds the
MAX_RECIPIENTS value, the smart service still sends the email.
The maximum report row property shown below controls the upper limit of items in a report that can be loaded into application server memory and the last page that can be retrieved for a report. This impacts how a report is displayed, printed, or exported to Microsoft Excel.
The default value is
The last page that can be displayed in a report is also calculated based on this property. The calculation multiplies the number of analytics engines (of which there are three in a standard configuration) by the number of rows per page specified for the report. The property value is then divided by this result to determine which report page is the last one that can be displayed.
This property also affects report Java APIs called with a batch size of
-1 (to return all rows). A setting of 30000 represents a calculated maximum of 10000 rows that can be returned by report Java APIs.
Users on the iOS or Android Appian mobile apps have the ability to complete actions even when they are not connected to the internet.
In order to make actions available offline, the offline mobile feature must be enabled on the environment and the designer must designate actions to be available offline.
When offline mobile is enabled, data may be stored on mobile devices to support offline use. Encryption of data stored on devices relies on the mobile operating system's native encryption capabilities.
The offline mobile feature is enabled by default. If you would like to disable it, you may do so on the Mobile page of the Appian Administration Console page.
You can configure the password policies for your site in the Appian Administration Console
The plug-in polling interval is the maximum number of seconds that elapse before loading a new plug-in after it is placed in the
<APPIAN_HOME>/_admin/plugins directory. Setting the interval to 0 causes hot-deployment to be disabled. With hot-deployment disabled, loading a new plug-in requires a restart of the application server.
The following maximum export rows property is no longer used.
See the section below for a replacement configuration option.
The maximum amount of time in seconds that a query waits for a response from the database before timing out is configured using the following property:
The query timeout limit only specifies the maximum amount of time the application waits for a response from the database. It does not signify that the query will definitely be killed by the database in 10 seconds. Once the kill command is issued to the database by the application, Appian cannot control how long it takes for the database to kill the query. Also, there are certain conditions in which the total query time for a query made by Appian will exceed 10 seconds. This is because multiple database queries could constitute a single Appian query, and the database could respond within 10 seconds for each of those database queries. The total Appian query time will exceed 10 seconds in such a scenaraio. Additionally, this timeout configuration is not applicable to the Query Database Smart Service.
The amount of memory in bytes that will be consumed in the application server for a single query before the query is halted is configured using the following property:
1048576bytes (1 MB).
NOTE: Before changing this value, consider using the query paging parameter to return less data (or return data in batches) and therefore avoid the limit. Also, consider whether the entire set of data that is being returned is actually needed. If not, use the query expression functions to select which fields to return.
See also: Querying Data From an RDBMS
The maximum number of expected concurrent query executions multiplied by the query memory limit size must not exceed and should be considerably lower than the low-water mark of available free memory on the application server. Use the performance and usage logs to provide a context to your estimates. When increasing this value, apply a corresponding increase to the maximum memory heap size of JVM for the application server.
See also: Monitoring Performance and Usage
By default, a user must provide their username and password once every two weeks for each browser on which they access Appian. The user can opt out by clearing the Remember Me checkbox on the Appian login screen. System Administrators can modify the authentication validity period and disable the capability site-wide through configuration.
This feature is configured in the Appian Administration Console
See also: Remember Me Authentication
Each analytics engine generates process reports using the process data that it receives from its associated execution engine and distributing the calculations across available analytics engines for maximum throughput.
In general, process reports should take no longer than 500 milliseconds to display.
It is important that you build your reports so that they execute within the allotted time frame, so that incremental updates from the execution engines are not delayed.
See also: Report Performance for information regarding how you can optimize your report design.
Avoid raising the timeout threshold, except as a temporary measure. Appian, in general, recommends against raising it at all. If necessary, consider raising it in a testing environment first to verify support for the increased timeout with the expected peak load.
Process Analytics Engine Timeout Setting
Within each analytics engine, a report times out completely after 2 seconds (2000 milliseconds), which is the default value.
This value is controlled by the following property in
MAXIMUM_REPORT_MS) is configured for all analytics engines. It is not possible to raise or lower the value for an individual process analytics engine.
Through the Internationalization Settings, you can select a Primary Time Zone for the site. The only options that appear in the list on the Internationalization Settings page of the System Administrator console are those based on the selected language.
To override this default list of recommended time zones, you can add a list for a new locale to the custom.properties file in the following format:
1 conf.timezones.locales.[locale_code]=[List of time zones]
The locale code is in [language]_[COUNTRY CODE] format. The list of available timezones can be found here: Java's java.util.TimeZone.
For example, if you want to configure the list to contain only Pacific, Mountain, and Central times in America (en_US), add this line to the custom.properties file:
See also: Internationalization Settings
By default, users who have been idle for 65 minutes are logged out by the system. You can change this timeout period in the Appian Administration Console.
Administrators concerned about license compliance can configure a soft limit on user accounts by entering a value for the following property. There is no default value.
When the user account limit is configured, a message displays on the People tab of the Designer interface if more users are registered than the limit allows. Beyond the message there is no other effect, nor is there any effect if the value is not set.
You can adjust the number of seconds to wait to establish a connection with a web service host using the following setting:
You can adjust the number of seconds to wait for a response to a request, once a connection is established, using the following setting:
You can specify the number of redirect responses (HTTP 304) the web service activity accepts.
On This Page