ADx Architecture

ADx can be configured in many different ways. Each of the basic setups mentioned below covers different requirements.

This document provides setup and configuration examples - the actual configuration depends on specific requirements.

The ADx deployment is responsible for providing the UI and API related to documents, including operations such as create content, get content, search contents, and more. For details, check ADx REST API documentation.

The TF Conversion deployment is responsible for providing services related to converting documents, such as merge pdfs, split pdf, office to pdf, and more . For details, check Available Conversion Jobs.

Single Node Architecture Diagram - Setup 1

Setup 1 is intended to be used for POC, demo and development (against ADx API) purposes. All instances are on a single node. All data is stored in a single database and the file system is a single mount point. There is no focus on performance, scalability, fail-safety or backup strategies. The setup provides all the APIs available from ADx and TF conversion.

Separate Single Node Architecture Diagram - Setup 2

Setup 2 is intended to be used for development and testing purposes. ADx and Conversion are separated on single nodes. The communication (internal as well as external) is done via optional load balancers. The databases are separated (e.g. to use TF conversion for multiple ADx deployments or being flexible for developer teams to clean up their instances if necessary) as well as the file system. Since it is not intended for production there is no focus on scalability, fail-safety or backup strategies. The separation of ADx and TF conversion separates the CPU-intense conversion from the ADx repositories to size the nodes appropriately. The setup provides all the APIs available from ADx and TF conversion.

Separate Clustered Nodes Architecture Diagram - Setup 3

Setup 3 is intended to be used for production purposes as well as for the latest test stage. ADx and Conversion are separated on cluster nodes. The communication (internal as well as external) is done via load balancers. Each system All databases and file system are designed to achieve maximum value of separation, for optimal performance, scalability, fail-safety, backup strategies and responsibilities.

Communication Flow - Sequence Diagrams

Create Content

Create Repository

Node Requirements

The node requirements are meant to be per node. In case of cluster usage the requirements are multiplied. The nodes itself can be either VMs or bare metal. Take in consideration that also the underlying operational system needs a certain amount of memory.

Node requirements - ADx

*shared on one node

Node requirements - TF conversion

*shared on one node

Backup

The backup recommendations are grouped into 5 categories. These recommendations are valid for database as well as for file system data.

Operating system settings

• Number of concurrently open file descriptors:

• Random generator: Since servers have low entropy use a service is necessary in enrich it.

• Command line tools:

Load Balancer

There are no special requirements for the load balancer. Neither the algorithm nor the session handling (sticky or not) has any special requirements. Since e.g. a conversion health check is synchronous for obvious reasons it is recommended to have a session timeout ≥ 10min.

Firewall settings

On each node (ADx/Conversion) the configured ports (see installation details) need to be opened:

• The external communication (https for security reasons) which provides the API to users, developers, and other systems must be available via the load balancers (or node in case there is no load balancer).
• Internally, the nodes need to open the ports for messaging in case of a clustered setup. Multicast must be allowed in case of automatic service discovery (optional).

Java requirements

Java Version: OpenJDK or Oracle JDK 11

Java in general supports more than 32GB heap size for one JVM but it needs to be considered that above 32GB Java uses 64bit references, which uses more memory by itself. When deciding to exceed the 32GB boundary, consider that is is necessary to increase the memory dramatically to have a similar heap available. In practice, this means that when increasing the memory above 32GB it is necessary to go over 40GB. See http://java-performance.info/over-32g-heap-java/ for a detailed explanation.

To avoid heap resizing during uptime of the servers which leads to performance issues -Xmx and -Xms should be equal.

Based on the available memory settings chosen in the setup configuration above make sure that the operating system does not needs to cache because of memory limitations. The rest should then be assigned to ADx, TF conversion and Messaging.

Java settings - ADx

Java settings - TF conversion

Runtime

The runtime of ADx and TF conversion is Apache Tomcat (http://tomcat.apache.org/).

Runtime - ADx

Runtime - TF Conversion

Mount Points

Since sizing of documents cannot be predicted it is recommended to have a file system with dynamic grow capabilities (e.g. XFS or ZFS)

Mount Points - ADx

*if used, shared between ADx nodes

Mount Points - TF conversion

*if used, shared between TF conversion nodes

Databases

Databases store the metadata and information for the different systems. ADx, for example, needs a database to store information about a document getting checked out, the name of the document or its history. This information goes into the database. Similar principle applies to Conversion. In addition the system databases are used for storing user information, sessions, locks, and so on. A relational database can handle this quite well - therefore it is used.

Database Sharing

It's possible to share databases in the configurations described below.

Database - ADx

ADx needs one SQL database for system-related data (such as sessions, user accounts or repository configuration).

ADx also needs SQL databases for each repository. For tribefire repository two databases are necessary - cache and content. For external repositories (e.g. Documentum, CMIS) one database is necessary - cache.

SQL Database - ADx

SQL Database - ADx - PostgreSQL

System database:

*or the default configuration of DEFAULT_DB - the sum of the maximum connections of each connection pool is the required number of connections from the database

Cache database:

Content database:

SQL Database - ADx - Oracle

System database:

*or the default configuration of DEFAULT_DB - the sum of the maximum connections of each connection pool is the required number of connections from the database

Cache database:

Content database:

SQL Database - ADx - MSSQL

System database:

*or the default configuration of DEFAULT_DB - the sum of the maximum connections of each connection pool is the required number of connections from the database

Cache database:

Content database:

Database - TF conversion

TF conversion needs the following databases:

• One SQL database for system-related data (such as sessions or user accounts).
• One SQL database for storing the job information.

In addition, a proprietary database is used on all nodes. This database holds the configuration of TF conversion.

SQL Database - TF conversion

SQL Database - TF conversion - PostgreSQL

System database:

*or the default configuration of DEFAULT_DB - the sum of the maximum connections of each connection pool is the required number of connections from the database

Conversion Job database:

If CONV_STORAGE_TYPE=db then the conversion files will be stored in database. This needs to be considered in case of sizing/caching configuration of the database.

SQL Database - TF conversion - Oracle

System database:

*or the default configuration of DEFAULT_DB - the sum of the maximum connections of each connection pool is the required number of connections from the database

Conversion Job database:

If CONV_STORAGE_TYPE=db then the conversion files will be stored in database. This needs to be considered in case of sizing/caching configuration of the database.

SQL Database - TF conversion - MSSQL

System database:

*or the default configuration of DEFAULT_DB - the sum of the maximum connections of each connection pool is the required number of connections from the database

Conversion Job database:

If CONV_STORAGE_TYPE=db then the conversion files will be stored in database. This needs to be considered in case of sizing/caching configuration of the database.