Design Patterns - External Configuration Store Pattern

In my previous post, I discussed about ‘Runtime Reconfiguration Pattern’  and how it can be applied in Genesys environment.It is easy to implement ‘Runtime Reconfiguration Pattern’ in Genesys and realize benefits for server applications. For client applications,  I recommend to use ‘External Configuration Store’ pattern along with ‘Runtime Reconfiguration’ to improve availability and scalability.

Problem

The majority of application runtime environments include configuration information that is held in files deployed with the application, located within the application folders. In some cases it is possible to edit these files to change the behavior of the application after it has been deployed. However, in many cases, changes to the configuration require the application to be redeployed, resulting in unacceptable downtime and additional administrative overhead. For example, if you want to change log folder location for Softphone and you need to make changes in all agent desktops.

Local configuration files also limit the configuration to a single application, whereas in some scenarios it would be useful to share configuration settings across multiple applications. Examples include database connection strings, Phone book, Transfer directory etc and storage used by a related set of applications.

In addition, updates to applications and components may require changes to configuration schemas.

Solution

Most of the problems can be addressed by using Configuration Server to store information. On large contact centers with 2K+ agents,  it overloads configuration server and any load on core servers should be avoided.

Solution #1 : Use Configuration Server Proxy

Straightforward solution. Install Configuration Server Proxy and direct client application traffic to proxy

Solution #2 : Use custom application

Use custom application to store and provide configuration data as below

External Configuration Store Pattern

My personal preference is to use custom application to store configuration data for the following reasons

• Flexibility to store different types of data like collections, XML document etc. Particularly useful, if you want to store phone book, personal speed dials etc.
• Easy to store multiple versions of configuration settings. For example, user may want to use different set of transfer directory numbers for holiday period only
• Implement business rules – Depending on user, machine, site or IP address range allows you to present different configuration settings
• Can be used as load balancing solution. In many cases – almost in all scenarios, client applications are configured to use dedicated instance of server applications like CS Proxy or Stat Server. For example, when agent logs in,  custom application can provide CS proxy details from pool instead of dedicated instance, which increases availability and performance

In my next post, I will cover another interesting pattern ‘Cache Aside’ to improve application performance.