Deployment and Configuration Options

Introduction

Decisions can be installed in myriad configurations to support different types of applications within the bounds of an enterprise’s unique profile. The following guide is intended to help users understand and set up some of the different configuration options based on the way that a company uses the Decisions platform.

Basic Installation

In the most straightforward installation, the Decisions platform is installed on an Application Server and connected to a SQL Server Database in the same environment.

Multi-Tenant Installation 

In a Multi-Tenant installation, the Decisions platform is installed on a single Primary (Control) Server and interacts with a Database. From this Server, additional instances are broken out into separate individual instances and Databases.

Application Server Clustering

When multiple Application Servers are being used with Decisions they are most commonly used with a Load Balancer. The Load Balancer acts as a primary point of contact so that all of the Application Servers look the exact same to any end-user. The Load Balancer internally routes data to each of the servers in the Cluster based on criteria configured at the Load Balancer.

Installation

When installing with a Load Balancer, all of the Decisions installations should use the exact same Portal URL, and it should be the URL that end users will use to connect to the Portal through the Load Balancer.

Using Multiple Application Servers

Decisions can scale by adding additional Application Servers to the environment to help with the load of users performing tasks in the Decisions Portal, or to help with the processing of Rules and Flows being invoked by another system. This configuration uses multiple installations of the Decisions platforms running on different servers that are all talking to the same Database. This configuration of hardware is supported by Decisions Clustering capability. In a Decisions Cluster, all of the Decisions platform installations are aware of one another and can communicate to keep data in sync between the servers.

The diagram below demonstrates two groups using multiple Application Servers. If using different user types in a manner that allows segmentation of users and assignment to access different servers, multiple Decisions Application Servers can be used without the aid of a Load Balancer.

Installation

When installing in this configuration, provide the same Database Connection String to each server during installation.
Each server should be installed with a different Portal URL specified in the installer.

Two Node Cluster

---

---

Two Servers with Optional Load Balancer For Backend Heavy Environments

In a Backend heavy environment, users may utilize a two Server setup with an optional Load Balancer. In this configuration, the first Server fields all web requests from its Group of users, and the second Server is set up as a Job/Scheduled Job Server. In this setup, the Scheduled Job Server is always on and configured to receive all the heavy workload/Batch Processing, but does not receive any requests.
In turn in the event of the first Server's failure, an optional Load Balancer may be used to direct web request traffic to the Job Server while the first server is being recovered.

SQL Clustering

In every Decisions installation, the database is a critical technical component without which Decisions cannot function. This leads many enterprise customers to install the Decisions Database into an existing SQL Cluster environment as shown displayed in the diagram below.  

When interacting with a SQL cluster Decisions is configured in the normal manner. The fact that the Database is being provided by multiple servers is transparent to Decisions and no special considerations must be made during installation and configuration.

SQL Failover

When using a database, even with a SQL Cluster, users have a single point of failure for their Decisions applications: the connection to the database. Decisions provides a way to configure a secondary database connection that is used for a Failover scenario. SQL Server can be configured to use SQL Replication which duplicates database data to an additional logical installation of SQL Server.

Disaster Recovery

In order to deal with Disaster Recovery, simply combine the concepts outlined in this document as shown in in the diagram below. Installing Decisions Application Servers in different locations is not difficult, nor is routing traffic to the individual sites. The most important aspect of a Disaster Recovery configuration is making sure that the database is available to the Failover Application Server. In order to accomplish this, Decisions recommends using SQL Replication.