This page explains how Appian works as part of an enterprise solution. It includes:
At a very high level, Appian is composed of six main software components:
The Appian web application serves requests from users' browsers or mobile apps and is primarily responsible for all end user, designer, and administrator web interface features.
The Appian engines contain metadata for most Appian objects created by the designers (groups, process models, rules, constants, knowledge centers, etc.), as well as runtime data created by users or processes (process instances, document metadata, etc). Data stored in the engines is accessed and updated by the web application.
The search server provides additional support for application features like viewing recent user activity in the Admin Console.
The Appian Data Source is a relational database that stores Appian data and metadata, such as News posts, CDT and Record Type definitions, and Admin Console properties. Additional business data sources can be configured to store and access business data from Appian applications.
The data service is Appian's next-generation data persistence layer. It provides better performance, higher reliability, and increased security for application data. Currently, the data service is used to store user-saved filters and serves as the storage layer for record types with data sync enabled.
Appian is an enterprise software platform that includes core components that work with other systems (database server, mail server) to provide capabilities and services to users. The following diagram illustrates the components of a typical Appian installation in greater detail:
All core components of the Appian architecture can be configured to support backup/restore and failover for high availability. Since Appian depends on other systems it is equally important to ensure that all associated components are similarly configured for high availability and recovery.
For more information on Appian's capabilities as they pertain to support tiers, see Customer Support.
The sections below walk through the Appian architecture to explain what each component does and how they interact, as well as links to additional documentation resources.
Appian's end user application interface is supported on all major web browsers and native mobile apps are available for the most popular platforms. The design interface, which is used to build applications, and the system Admin Console are also 100% web-based.
All web and mobile clients access Appian using HTTP/S. HTTPS is recommended for production installations. User-uploaded content and third-party extensions are hosted from two independent domains to prevent unintentional or insecure interaction with Appian interfaces. Minimal web browser configuration is required and Appian does not use browser extensions or plugins. Internal-facing Appian sites typically require the use of mobile VPN tools to enable mobile access from commercial cellular networks.
As with most web applications, Appian installations should use a web server to handle client requests before passing traffic to the application server.
A web server can be used to handle static requests (images, css, etc.) which enables that content to be cached by client browsers for improved performance. Multiple web servers can be used with a load balancer. When using HTTPS, a web server can remove the SSL overhead from the application server. Some deployments may also use an SSL accelerator (often combined with a load balancer) before traffic reaches the web server to further optimize HTTPS performance.
Requests for non-static content are passed through from the web server to the application server. The connection configuration between these components depends on which web and application server platforms are used. For example:
Apache web server uses mod_jk to connect to Appian.
IIS web server uses the ISAPI Redirector DLL to connect to Appian.
These methods of communication are not Appian-specific but do require Appian-specific configurations to control which types of content are served by each component and other settings.
An application server is a multi-threaded execution environment for web applications and provides built-in support for connecting to a wide range of related system components. Appian requires Java 8 or higher.
The application server coordinates most of the interaction between system components and is responsible for a significant portion of Appian's functionality. Specifically, the application server:
Because the application server is involved in such a significant amount of activity, it is a central source of logging and other information about system usage, health, and performance. It also has a wide range of configuration options, most of which are managed in the custom.properties file or the Admin Console.
The Appian engines are in-memory, real-time databases based on KDB and the K language. The engines provide extremely fast storage and retrieval of data and also contain low level logic for high volume operations like security and group membership checks.
A default Appian installation has 15 engines: 3 process execution engines, 3 process analytics engines, 6 other individual engines, and 3 to support legacy portal. Each engine serves a unique role in the Appian architecture.
The execution and analytics engine come in pairs and are expandable up to 32 pairs of engines:
Process Execution: Manages process execution and data for associated process models. Also referred to as exec, PX.
Process Analytics: Stores all relevant information that may be used in a report on a process. Also referred to as analytics, PA.
Additional execution and analytics engines can be used to load balance high process execution and/or reporting volume across more engines and more engine servers (in a distributed environment).
The following six engines play a significant and active role in current features:
Content: Stores metadata and security settings for documents and their organizational structures (communities, knowledge centers, and folders). The actual document content is stored on the file system, not in the engine. Also referred to as collaboration, collab, CO.
Collaboration Statistics: Contains statistics on document usage and storage. Also referred to as collab-stat, CS.
Portal Notifications: Stores information about system notification settings. Also referred to as notif, notifications, NO.
Email Notifications: Responsible for generating and sending notifications via email. Also referred to as notif-email, NE.
Personalization: Stores information about users, groups, group membership, and group types. Also referred to as groups, PE.
Process Design: Stores all information that pertains to the design of the process models within the application. Also referred to as design, PD.
The following engines support older features in the Apps Portal interface:
Portal: Stores all information about pages in the Apps Portal interface. Also referred to as PO.
Channels: Stores information about the portlet types that are displayed on portal pages in the Apps Portal interface. Also referred to as CH.
Forums: Stores all of the topics and messages posted to discussion forums in the Apps Portal interface. News content in the Tempo interface is not stored in this engine. Also referred to as discussion forums, DF.
The search server contains an ElasticSearch server and aggregates data from the rest of the application to support features like tracking historical performance, viewing recent user activity, and analyzing design-time impacts/dependencies. The search server runs as a stand alone Java application and multiple search servers can be configured to allow for both data redundancy and high availability.
The Appian Data Source is a relational database that stores internal Appian data and metadata and is required to run Appian. The same relational database that is used as the Appian Data Source can be used as a business data source. Appian also allows for additional business data sources to be configured, providing the ability for database isolation across Appian applications if desired.
The Appian Data Source and business data sources must be configured with a supported database.
The application server and Appian engines are installed on and store run-time content on the file system, although they store data in independent directories and do not use the file system to share data with each other. Shared storage (Windows or NFS) is required when running a distributed environment with multiple application servers or multiple engines different servers.
The application server stores run-time content in the directories under <APPIAN_HOME>/_admin:
accdocs1, accdocs2, accdocsX: Contain documents uploaded by users and generated by processes.
logs: Contains all application server logs.
mini: Contains data displayed in web content channels in the Apps Portal interface.
models: Contains XML files associated with Appian process models.
process_notes: Contains data for the process and task notes feature available in the Apps Portal interface.
shared: Contains the site-wide keystore used for securing passwords and the encryption and secure credential store services.
The Appian engines store run-time content in the directories under <APPIAN_HOME>/server:
../gw1, ../gw2, ../gwX: Contain .kdb files that persist in-memory engine state and transactions.
archived-processes: Contains .l files representing process instances that have been archived by the process execution engines.
logs: Contains all Appian engine logs.
msg: Contains message content for discussion forums in the Apps Portal interface.
Default storage locations can be changed using configuration settings and maintenance scripts.
The data service is a novel storage layer designed from the ground up for Appian. It is a fault-tolerant distributed service that stores application data and metadata, consisting of several components:
Writes to the data service also depend on the availability of the Internal Messaging Service. Reads do not have any dependency on the Internal Messaging Service.
Appian requires an external SMTP server to send outgoing email including system notifications and email messages sent by process instances. SMTP configuration supports common security features like SSL/TLS and server authentication.
Appian can also be configured to receive email over POP3 or IMAP/S. The application server polls the mail server and routes each incoming message to either start a new process or continue an existing process flow from an event node.
Environments with Appian RPA enabled use a specific server to orchestrate or queue robotic task executions. This RPA server communicates with RPA agents on customer resources and the application server.
You can only use Appian Process Mining 6.0+ in Appian Cloud.
Appian's default authentication uses a username/password login form for web browser clients and HTTP Basic for web API clients. User credentials are validated against Appian's internal account data in the personalization engine. The default configuration also includes features like "remember me" authentication and password complexity/expiration controls.
Other authentication protocols and methods including LDAP/Active Directory and SAML can be configured in the Admin Console.
As an enterprise solution Appian often integrates with external systems in order to display information to users, move data between systems, make decisions in business processes, and more. All of these integration capabilities are managed by the application server and can be extended using OSGi plug-ins.
Appian also has several built-in connectors and connected systems that enable rapid integration with CMIS content management systems, Microsoft Dynamics, Salesforce, SAP, Siebel, and SharePoint. The Appian for SharePoint module provides additional support for exposing Appian data inside SharePoint.
In addition Appian can connect using more general purpose integration methods like JMS, file transfer protocols, and multiple out-of-the-box web services options that can read and write data using process model smart services (SOAP, REST) or from interfaces like a record or report (see Scripting Functions). Appian also simplifies incoming integration by exposing process models as web services.
The Internal Messaging Service is responsible for relaying data between different components of Appian's architecture. It is implemented using Apache Kafka, which is an open source distributed messaging system with publish-subscribe semantics, and Apache Zookeeper, which coordinates leader election within the Kafka cluster.
Currently the Internal Messaging Service is used as a transaction log for the engines and the data service.
Enterprise Architecture Overview
