Architecture [DRAFT]

About Support for Business Continuity

Business Continuity provides protection to enterprise operations in the following situations:

• Disaster Recovery (Site Failure)
• Networking Failure Between Sites
• Graceful Migration

Genesys Info Mart supports Business Continuity by providing contact center reporting in all three scenarios. In other words, the replicated database setup described in this document ensures that a Genesys Info Mart instance continues to gather and process data when one of the sites fails, a network connection fails between the sites, or another Genesys component that supports Graceful Migration is migrated in this manner.

Note, however, that Genesys Info Mart as an individual component supports the Disaster Recovery (Site Failure) scenario only. For this reason, instructions in this document do not cover the switchover between Genesys Info Mart instances during a networking failure or for the purposes of application migration.

The Genesys Info Mart setup that is described in this document can be used in conjunction with Genesys SIP Business Continuity solution, in particular. For information about this SIP Server–based solution for Business Continuity, refer to the SIP Server HA Deployment Guide.

NOTE TO WRITER: CHECK THE LINKS AT PUBLICATION TIME.

Sample Two-Site Architecture

A typical Business Continuity architecture relies on deployment of two or more sites to ensure continuous enterprise operations in the event of a site failure. Particular deployments may vary in distribution of Genesys components across the sites.

The sample Business Continuity architecture that is described in this section uses a synchronized, two-site deployment, where Genesys switch and server architecture is mirrored at each site in an active-active configuration, so that any agent can log in to either switch, at any time. One or several Oracle RDBMS instances are deployed at each data center to host Genesys databases.

This architecture is recommended for use with Genesys-provided SIP Business Continuity solution. To learn about the overall SIP Business Continuity architecture, refer to the SIP Business Continuity Architecture.

To provide reporting in this deployment, Interaction Concentrator at each site collects unique data from the local data sources. For example, SIP Server can serve as a data source for Voice data domain and Interaction Server can serve as a data source for Multimedia data domain. Configuration Server Proxy serves as a data source for Configuration data domain. Outbound Contact Server (OCS) serves as a data source for Outbound data domain in an environment with Outbound Contact.

An Interaction Concentrator instance consists of ICON server (or just ICON) and Interaction Database (IDB). ICON operates at the same site as the data source and stores data in a corresponding IDB. A separate instance of Interaction Concentrator is required at each site to store Voice or Multimedia details. Another, separate instance of Interaction Concentrator is required at each site to store Configuration details. Depending on the Outbound Contact data volume, one or more instances of Interaction Concentrator per OCS are required at each site to store Outbound details. Each IDB in the deployment uses a separate, dedicated database schema.

To provide high availability (HA) of reporting data, a redundant pair of Interaction Concentrators receives events from the same data source. Both ICONs in an HA pair operate in parallel as stand-alone servers; they process incoming data independently and store data in two independent IDBs. In this sample architecture, one IDB from the HA pair is located at the same (local) site as the HA pair of ICON servers while the other IDB from the HA pair is located at the other (remote) site.

An active Genesys Info Mart instance at the primary site (Site 1) accesses all the IDBs at both sites and, for each HA pair, extracts data from the IDB that has the best quality data from a particular data source. The extracted data is stored at the active Info Mart database at Site 1. The data from the Info Mart database at Site 1 is replicated to the standby Info Mart database at Site 2 by means of Oracle GoldenGate. An active instance of Genesys Interactive Insights (GI2) at Site 1 provides historical reports for all users.

The standby Genesys Info Mart instance at Site 2 can be brought into service in the event that Site 1 fails. This Genesys Info Mart must not access the Info Mart database while replication is in progress. (To prevent accidental access, do not configure the database connection until the server at Site 2 has to be brought into service.) A standby GI2 instance at Site 2 can be brought into service in the event that Site 1 fails.

In the case that Site 1 fails, the disaster recovery procedure for the site must be started. As part of this procedure:

• Genesys Info Mart instance at Site 2 is activated and configured to write data into the Info Mart database at Site 2.
• Replication configuration at Oracle GoldenGate at Site 2 is modified to account for the absence of the replication source.

When the failed site, or its replacement, is back in service, Oracle GoldenGate replication must be set up once again between the Info Mart database that will be active and the standby Info Mart database.