Deployment and Configuration Options
- 13 Nov 2024
- 4 Minutes to read
- Print
- DarkLight
Deployment and Configuration Options
- Updated on 13 Nov 2024
- 4 Minutes to read
- Print
- DarkLight
Article summary
Did you find this summary helpful?
Thank you for your feedback
Overview
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 platform.
Warning for Cloud-Based Users
If the Decisions is used as a Service from the Cloud-Based offering, then the contents of this guide may not be applicable.
Decisions maintain all of the following configuration options and capabilities in Decisions' data center to ensure availability, backup, and security.
Decisions maintain all of the following configuration options and capabilities in Decisions' data center to ensure availability, backup, and security.
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
WebSocket Connectivity Issue?
When using a Load Balancer/Application Gateway/Proxy, WebSocket support must be enabled on the
[PortalBaseURL]/events path.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.
Sticky Bit
When using a Load Balancer with Decisions, it is important that a "Sticky bit" is used.
This means that a particular user's session interacts with the same server within the Cluster for the duration of the session.
This means that a particular user's session interacts with the same server within the Cluster for the duration of the session.
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 be scaled 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.
Warning on Use Case
Note that the previously stated scenario is uncommon. Load Balancers are needed In most cases where multiple Application Servers are used for user interactions.
.png)
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 by the installer.
Two Node Cluster
Alternate Two Node Cluster Configuration
The following diagram represents a two-node cluster. This Cluster consists of two separate Groups with two separate Decisions servers running against the same database.
This configuration provides high scalability but low availability. In this instance, Group 1 shares its workload with the Scheduled Job Server, while Group 2's workload is passed onto the second Decisions Server.
This configuration provides high scalability but low availability. In this instance, Group 1 shares its workload with the Scheduled Job Server, while Group 2's workload is passed onto the second Decisions Server.
.png)
Two Servers with Optional Load Balancer For Backend Heavy Environments
.png)
In a Backend 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.
About Diagram
The diagram below demonstrates a two-server configuration with one server configured as the Job Server and an optional Load Balancer used to redirect requests to the Job Server in the event of the first server's failure.
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.
SQL Clustering Resources
For a basic introduction to SQL Clustering, see Introducing SQL Server Big Data Clusters.
For further information on Clustering, contact a Microsoft-certified professional.
For further information on Clustering, contact a Microsoft-certified professional.
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.
.png)
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 provide 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.
The diagram below displays how an environment with a replicated SQL Installation would look.
Additional Information
For more information on SQL Replication, see Configure replication with Always On availability groups.
Disaster Recovery
Note on Supported Replication Methods
Note that presently, Decisions only supports Transaction Replication and cannot use Merge Replication.
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.
SQL Replication Resources
.png)
For further information on Installation, visit the Decisions Forum.
Was this article helpful?
