Post-Install Configurations

Overview

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.

Required configurations

The following post-installation configuration steps are required on every system.

Configure the disk cleanup

Use a job-scheduler, like cron, to clean up your old engine files, logs, and process archive files:

• Clean up 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.
• Clean up 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. You can:
  • Archive processes to conserve RAM.
  • Move archives to a backup location to conserve disk space.
  • Delete process archives after the data they contain is no longer of use to your organization.

Configure your site URL

Whether you have a standalone instance of Appian or a load-balanced configuration with multiple replicas, your end-users should use a single URL to access your Appian installation. Appian needs to know this URL in order to construct links.

To specify this URL, use the following spec field in Appian CR configuration file:

1
2
spec:
  url: <URL>

where <URL> specifies the scheme, fully-qualified domain name, and, optionally, port used to access Appian.

For example:

1
2
spec:
  url: https://appian.example.com

or

1
2
spec:
  url: http://appian.example.com:32767

Usage considerations:

• The default domain validation assumes your site uses a standard top-level domain (like .com or .co.uk). If your site uses an internal domain structure that is not based on a standard top-level domain, you must also set the following .spec.customProperties field:

  1
  conf.suite.DISABLE_STRICT_DOMAIN_SECURITY: "true"
  

• A warning will be logged on startup if these properties not configured properly.

Configure your static and dynamic content URLs

In addition to the site URL, Appian uses the following URLs to serve certain types of content for security purposes:

• Static content URL: Used for hosting user-provided content like documents.
• Dynamic content URL: Used for hosting third-party extensions.

These URLs are not required to start Appian, but some features (like the Document Viewer) will not work without them properly configured.

To specify these URLs, use the following spec.webapp fields in the Appian CR configuration file:

1
2
3
4
spec:
  webapp:
    staticUrl: <URL>
    dynamicUrl: <URL>

where <URL> is the scheme, fully-qualified domain name, and, optionally, port, of the URL to use for static or dynamic content.

Usage considerations:

• Both static content and dynamic content URLs must reference the same Appian instance as the site URL.

• For security reasons, the site URL, static content URL, and dynamic content URL must each use a different domain. These must be different domains, not just separate subdomains.

• The default domain validation assumes your site uses a standard top-level domain (like .com or .co.uk). If your site uses an internal domain structure that is not based on a standard top-level domain, you must also set the following .spec.customProperties field:

1
conf.suite.DISABLE_STRICT_DOMAIN_SECURITY: "true"

• When setting this property, you only need to add a port if the port you're using differs from the defaults. The default port numbers are :80 if the scheme is set to HTTP and :443 if the scheme is set to HTTPS.

• A warning will be logged on startup if these values are not configured properly.

Example when using a standard top-level domain like .com or .co.uk:

1
2
3
4
5
spec:
   webapp:
     url: https://www.example.com:8080
     staticUrl: https://www.example-static.com:8080
     dynamicUrl: https://www.example-dynamic.com:8080

Example when using a non-standard top-level domain like .corp:

1
2
3
4
5
6
7
spec:
   webapp:
     url: www.example.corp:8080
     staticUrl: www.example-static.corp:8080
     dynamicUrl: www.example-dynamic.corp:8080
  customProperties:
      conf.suite.DISABLE_STRICT_DOMAIN_SECURITY: "true"

Exclude files from antivirus scanning

Exclude the following from your Kubernetes cluster's antivirus software:

• Appian engine files (*.kdb)
• Files in Kafka and Zookeeper pods
• Files and directories in the Data Server pod

Locking these files or otherwise interfering with them while the system is running, as is common with antivirus software, is known to lead to system instability.

Raise the cap on maximum engine size on 64-bit operating systems

On 64-bit systems, modify the server.conf.processcommon.MAX_EXEC_ENGINE_LOAD_METRIC custom property in the Appian CR configuration file to a minimum value of 120 or higher.

See also: Configuring the Process Engine Servers.

Set up mail server and notifications

Setting up a mail server enables Appian to send and receive emails.

See: Mail Server Setup, Notifications

Optional configurations

The following optional changes can be made to your installation.

Appian topology

The spec field in the Appian CR configuration file contains an example topology that configures all engines, the search server, the Internal Messaging Service, and the data service, using the default ports. Self-managed customers can modify the configuration file to align with the Appian topology that they want to use.

See also: Topology Changes

Application context

The default application context is suite. You can change this to a different name by setting the webapp.applicationContext field in the Appian CR configuration file.

For example:

1
2
3
spec:
  webapp:
    applicationContext: "index"

You cannot set the application context to use more than one level of directories.

Application server heap

The amount of Java heap space available to the application can be tuned using a custom property in the Appian CR configuration file:

1
conf.appserver.maxHeapSize: "2048m"

By default, the value is set to 2048 MB.

Application logo

The logo is configured in the Admin Console.

Application name

The name is configured in the Admin Console.

Disable Anthropic models

Some organizations must stop using Anthropic models to meet regulatory or organizational requirements. You can disable all Anthropic models at the site level so that generative AI features use another model provider instead. Disabling Anthropic models turns off every Anthropic model.

Before you disable Anthropic models, prepare your environment so that generative AI features keep working:

1. Enable another model provider on your environment. To see the available generative AI models, see AI Services.
2. Migrate your existing AI Skills to the enabled model provider and regression-test them. All other generative AI features switch to the enabled model provider automatically once you disable Anthropic models.

To disable Anthropic models, set the following custom property in the Appian CR configuration file:

1
conf.aiplatform.autoDisabledModelProviders: "anthropic"

Footer values

You can use custom properties to specify the values listed in the display footer of the Appian environment, as follows:

For example:

1
2
resources.appian.ap.application.appian.ap.appianName: "Appian Corporation"
resources.appian.ap.application.appian.ap.copyrightYear: "2003-2014"

Inline document display

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:

1
conf.content.download.inline: "false"

This field must be set to true in order to do the following:

• Use PDF forms as task forms.
• Display the contents of a file stored in Documents inline on a page in the web page channel.
• Display a document inline in a separate window.

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.

Integrations

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 custom property:

1
conf.integrations.threadPoolSize: "30"

• The default value is 30 (thirty threads).

Internationalization

In the Internationalization page of the Admin Console, specify the primary locale, primary time zone, and primary calendar for your self-managed environment.

Maximum activity instances

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:

• A limit for the number of times a single activity can be started.
• A limit for how many activities without forms can be placed between two activity-chained tasks, which display navigation buttons that link each task in the chain.

Single activity limits

You can execute any activity multiple times in the same process flow by using the Multiple Node Instances (MNI) functionality.

The server.conf.processcommon.MAX_NODE_INSTANCES field in the Appian CR configuration file limits the total number of times that the same activity can be launched within a process. The default limit is 1000. The maximum is 150000.

Activity-chain limits

The CHAINED_EXECUTION_NODE_LIMIT field 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 Appian CR configuration file:

1
server.conf.exec.CHAINED_EXECUTION_NODE_LIMIT: "<number of node instances>"

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 field 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

Maximum notification recipients

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 field in the Appian CR configuration file:

1
conf.notifications.MAX_RECIPIENTS: "<number>"

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 E-Mail 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.

See also: Notifications and Application Server Log File

Maximum report rows

The maximum report row field 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.

1
resources.appian.analytics.application.maxreportrows: "<rows>"

The default value is 30000.

In certain cases, this value can be raised to return more rows for a report. Before making such a change, we recommend testing the increased value in an environment that includes the same (or comparable) data sets to determine whether your available JVM memory allocation is sufficient.

The last page that can be displayed in a report is also calculated based on this field. 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 field value is then divided by this result to determine which report page is the last one that can be displayed.

• Report rows that fall outside the last page of the report cannot be displayed.
• A setting of 30000 represents a calculated maximum of 10000 rows that can be exported or printed in a standard configuration. The value specified for this field is divided by the number of analytics engines in your instance (of which there are 3 in a standard topology).

This field 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.

Enabling offline access

Offline access allows users on the Appian Mobile or Appian for Windows app to complete actions without an internet connection. This requires storing data locally on the device. For Appian Mobile, the mobile operating system natively encrypts this data. Appian for Windows encrypts data at rest using Windows encryption APIs.

Offline access is enabled by default. To disable it, go to System > Mobile in the Admin Console. For instructions on configuring offline experiences, see Enable Offline.

Opaque URLs

To provide consistency and an enhanced level of security, Appian uses opaque URLs to construct custom links in your applications.

However, if your environment contains Appian apps that are running 20.2 or earlier, you may have developed applications that construct custom links with numeric IDs. If so, you must configure the following custom properties to ensure backwards compatibility for both opaque and non-opaque task and document URLs:

1
2
conf.tasks.accessibleById: "true"
conf.content.download.byId: "true"

Password policies

You can configure the password policies for your site in the Admin Console

Plug-in polling

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.

1
conf.plugins.poll-interval: "60"

See also: Appian Plug-ins

Query limits to external databases

By default, a query will wait up to 10 seconds for a response from an external database before timing out.

You can configure the maximum amount of time that the query should wait for a response using the following custom property:

1
conf.data.query.timeout: "10"

By default, 5242880 bytes (5 MB) of memory will be consumed in the application server for a single query before the query is halted.

You can configure the amount of memory that will be consumed in the application server for a single query before the query is halted using the following field:

1
conf.data.query.memory.limit: "5242880"

If these solutions still do not meet the requirements of the use case, consider the number of concurrent queries that are expected in the system and the amount of free memory available on the application server.

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

Remember Me authentication

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 Admin Console.

See also: Remember Me Authentication

Repeat limits

The repeat() function takes an input and returns a list with the input repeated a specified number of times. To prevent excessive utilization of system resources, you can limit the number of times this function repeats the input.

For self-managed installations, this value is controlled by the following custom property in the Appian CR configuration file:

1
server.conf.processcommon.MAX_REPEATS: "<number of repeats>"

By default, the function is limited to 50,000 repeats.

Report timeout settings

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 for self-managed installations

Within each analytics engine, a report times out completely after 2 seconds (2000 milliseconds), which is the default value.

For self-managed installations, this value is controlled by the following field in the Appian CR configuration file:

1
server.conf.processcommon.MAXIMUM_REPORT_MS: "<milliseconds>"

• The maximum report milliseconds field (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.
• The timeout value cannot be raised above 15 seconds (15000 milliseconds).
• Restart all Appian Process Analytics servers for the change to take effect.

Session timeout 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 Admin Console.

Transport layer security

If you are in the process of upgrading your connected systems, you can override the Transport Layer Security (TLS) default to enable TLS 1.0 and above by adding the following field to the Appian CR configuration file:

1
ssl.legacy_tls_enabled: "true"

If the field is not found in the file, the default value will be false and you do not need to manually add it.

See System Requirements for more information.

Time zone options

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 Appian CR configuration file in the following format:

1
conf.timezones.locales.<locale_code>: "<list of time zones>"

Note:

• The locale_code element 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 Appian CR configuration file:

1
conf.timezones.locales.en_US: "America/Los_Angeles,America/Denver,America/Chicago"

See also: Internationalization Settings

User account limit

Administrators concerned about license compliance can configure a soft limit on user accounts by entering a value for the following field. There is no default value.

1
conf.suite.USER_ACCOUNT_LIMIT: "<number of users>"

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.

Web service connections

See Web Services.

Feedback