Here we are  explaining how Appian works as part of an enterprise solution. It includes:

• An overview of the core components of the Appian suite
• How Appian interacts with other software and systems in the enterprise
• How these components work together to provide features for end users, application designers, and administrators

High Level Overview

At a very high level Appian is composed of 6 main software components:

• A front end server hosting the Appian web application
• A set of backend in-memory database engines
• One or more search servers
• One or more relational databases hosting Appian internal and Appian application (business) databases
• A data server to store application patches and user-saved filters
• An internal messaging service that relays messages between different components of Appian

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 all the 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.

Appian requires a relational database such as MySQL, SQL Server, or Oracle to store runtime data for Appian interface features like the News feed as well as additional designer metadata not stored in the Appian engines (data types, record types, etc). Appian can connect to additional “business” databases to access and store business data associated with individual applications.

The data server is a next-generation data persistence layer. It provides better performance, more reliability and increased security for application data. Currently, the data server is used to track the design objects added to the application patches and to store the user-saved filters. Over future several releases, more Appian functionality and capabilities will rely on the data server for data persistence.

Appian Architecture

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.Below we are explaining walk through the Appian architecture to explain what each component does and how they interact as well as links to additional documentation resources

Web/Mobile Client

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 administration 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.

Web Server

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.

Application Server

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.

The application server handles end-user web or mobile client requests that are passed through from the web server (including authentication and authorization for those requests). It retrieves and updates data in the Appian engines and the primary and business databases. It manages documents uploaded by users and generated by processes. It executes business rules, runs the activities defined in process models, and communicates with external systems. It can be extended using plug-ins deployed using the OSGi framework.

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 administration console interface.

Appian Engines

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 and 3 process analytics engines 6 other individual engines and 3 to support legacy portal. Process execution and analytics can each have up to 32 total engines defined, always in paired sets. 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).

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.

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.

Search Server

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.

Relational Database

Appian requires one relational database to be configured as a data source. This database is used to store system metadata like data types and security settings as well as run-time data like News post content.

Additional “secondary” or “business” databases can be used by applications built in Appian to store and retrieve business data specific to those applications. Data from these sources can be used in many places within an application including in processes, on forms, as records, and in reports. Secondary databases may be created as part of an Appian application or may be existing databases that Appian uses.

Database connections are managed using the application server’s JDBC data source connection configuration. These settings specify the database host, credentials, pooling, recovery, and other connection options.

File Storage

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.

Data Server

The data server is a storage layer designed for Appian platform. It is a standalone application which consists of two data stores:

1. A historical store with a single kdb+ database optimized for writes
2. A real-time store with potentially multiple kdb+ databases optimized for reads

In the current version, the data server stores application patches and user-saved filters. In future versions of Appian, more functionalities will rely on the data server as a persistence layer.

Mail Server

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.

Authentication Services

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

Integration Services

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 .Appian also simplifies incoming integration by exposing process models as web services.

Internal Messaging Service

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 Server.