Introduction

Decisions can be installed in myriad configurations to support different types of applications within the bounds of an enterprise’s unique profile.  This guide is intended to help you understand and setup some of the different configuration options based on the way that your company will be using the Decisions platform. 

Note: If you are using the Decisions platform as a service from our cloud based offering then the contents of this guide do not apply to you.  Decisions maintains all of these configuration options and capabilities in our data center installations 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.

 

Figure 1 – Basic Installation

 

 

 

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 workflows being invoked by another system.  In this configuration you need to use 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.

 

In Figure 2 you’ll see multiple Decisions application servers.  If you have different user types in a manner that lets you segment users and assign them access to different servers you can use multiple Decisions application servers without having to have a load balancer.  This is a very uncommon scenario and in most cases where multiple application servers are being used for user interactions you will need a load balancer.

 

 

Figure 2 – Multiple Servers in Simple Configuration

 

Installation

When installing in this configuration you 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 as in Figure 3 – Portal URL Screen in Installer.

 

 

Figure 3 – Portal URL Screen in Installer

 

 

 

Application Server Clustering

When multiple application servers are being used with Decisions they are most commonly used with a load balancer as shown in Figure 4 – Multiple App Servers 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. 

Note: When using a load balancer with Decisions it is important that “Sticky bit” is used meaning that a particular user’s session interacts with the same server within the cluster for the duration of the session.

 

 

Figure 4 – Multiple App Servers with a 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.  This configuration happens during installation on the screen shown in Figure 3 – Portal URL Screen in Installer. 

 

Background Processing with Decisions Enterprise

 

Work Queues

Background processing is handled in Decisions by putting work into queues and having Decisions servers work on tasks in those queues.  If you have the Decisions Enterprise module installed then you have complete control over how the queues behave in your environment. 

There are two main Decisions features that make use of work queues:

1. Scheduled Jobs (This includes systematic scheduled jobs like task reminders)
2. Background workflows (otherwise known as Async workflows or “Fire and Forget” in older releases)

Whenever one of these features is leveraged their work task is stored in a queue.  Decisions has one queue, the Default Queue, when installed.  To configure additional queues you must be an administrator and navigate to: /System/Jobs and Events/Work Queue Types as shown in Figure 5 – Adding and Editing Work Queues.

 

Figure 5 – Adding and Editing Work Queues

Once you have added multiple queues, you can specify which servers in your Decisions cluster are allowed to work on each of the queues of work.  This allows you to dictate what kinds of background processing each of the servers may be responsible for.  This is commonly used to create a ‘background processing’ machine which isn’t connected to the load balancer and is not used for user interaction but works very hard on queued tasks and batch processes.  Selecting the queues a server is allowed to pull work from is done in /System/Administration/Servers.  You select a server, and select ‘Edit Server.’  This will present you with the dialog shown in Figure 6 – Specifying Queues for a Server.

 

 

Figure 6 – Specifying Queues for a Server

 

 

Worker Profiles

In addition to constraining servers to work on specific queues you can also designate different worker profiles that govern how each server in the cluster addresses work that is stored in the queues.  Worker profiles are maintained and edited at /System/Jobs and Events/Work Queue Workers as shown in Figure 7 – Configuring a Worker Profile.

 

 

Figure 7 – Configuring a Worker Profile

The dialog shown above has several settings.  These settings control the detailed behavior for any Decisions server that is assigned to this profile. 

      1.       WorkQueueProfileName: The name of the profile.  This should be something meaningful so that you know which servers should be assigned to that profile. 

      2.       CheckTimespanWhenActive: This is the amount of time that will pass between checks for new work in the queue when the worker is already active and has been processing work from the queue.

      3.       CheckTimespanWhenInactive: This is the amount of time that will pass between checks for new work in the queue when the application server hasn’t had any work to work on lately. 

      4.       PickupItemsOlderThan: This setting specifies the minimum age of a task in the queue that this worker profile is allowed to pick up and work on.  The purpose of this setting is to allow you to have servers that do not normally work on background processes to get involved only when the work queue is getting backed up and the servers that address work more aggressively are taking too long to get to tasks in the queue. 

      5.       WorkerThreads: This is the number of threads that the Decisions platform will be allowed to commit to background processing.  The right value for this number depends on your hardware and the type of processing that you are doing. 

 

 

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 in Figure 8 – Adding a SQL Server Cluster.  A basic introduction to SQL clustering can be found here: http://technet.microsoft.com/en-us/library/ms189134.aspx.

 

For more information on SQL Clustering please 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. 

 

 

 

Figure 8 – Adding a SQL Server Cluster

 

SQL Failover

When using a database, even with a SQL cluster you have a single point of failure for your Decisions applications: the connection to the database.  Decisions provides a way to configure a secondary database connection that is used for a failover scenario.  You configure SQL Server to use replication which duplicates database data to an additional logical installation of SQL server.  More information about SQL Replication can be found here: http://technet.microsoft.com/en-us/library/ms151847.aspx

A Decisions environment with a replicated SQL installation may look simple as in Figure 9 – App Server with a Failover Cluster Configured.

 

Figure 9 – App Server with a Failover Cluster Configured

 

 

 

Configuring the Failover Database

When creating the publication for replication, you must enable the following settings on all tables.

Copy nonclustered indexes = true
Copy user triggers = true

The following screenshots will show you where in the installation you will need to set these settings.

 

To setup the fail over database you first install Decisions according to the normal instructions.  Once the installation is complete, you re-run the installation tool and choose the option “Edit Settings” as shown in Figure 10 – Edit Settings from Installer.  Note: This is simply a convenient way to edit Settings.xml in your installed directory and you can accomplish this same thing manually if you prefer not to re-run the installer.

Once the Edit Settings dialog appears you want to configure a second connection string for the property “SecondayDatabaseConnectString.”  Please note to make things easier this setting defaults to the same value you provided for your primary connection string.  Note: Because this is advanced capability no connection string builder user interface, like the one used during installation, is provided. 

 

Note: After the changes are saved you do not need to restart the services for the changes to be recognized.

 

 

Figure 10 – Edit Settings from Installer

 

By using both a primary and secondary database you must configure the ‘Max Text Replication Size’ to allow large data transfers. This setting can be changed to allow any text replication size by running the following script.

EXEC sp_configure ‘max text repl size’, -1 ;

GO

RECONFIGURE;

GO

 

Note: This must be run on both the primary and secondary database server.

A Final Note about Database Failover

Once the application server fails to connect to the primary connection string and begins communicating with the secondary connection it WILL NOT attempt to restore the connection to the primary database.  Because of the potential to be out of sync with transactional data the process of restoring full service to the primary connection must be done manually and requires a restart of the services.

 

Disaster Recovery

Important Note: we only support transactional replication and you cannot use merge replication.

In order to deal with disaster recovery you simply combine the concepts outlined in this document as shown in Figure 11 – Disaster Recovery Configuration.  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.  More information about SQL Replication can be found here: http://technet.microsoft.com/en-us/library/ms151847.aspx

 

 

Figure 11 – Disaster Recovery Configuration

Additional Resources

• Integrating Decisions with External Oracle Database