Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: Vikram_Joshi on January 02, 2014, 04:36:21 AM
-
Hi Experts,
We are trying to Implement 2nd Instance on Email Server and Ixn Server in our existing eServices environment as per eServices Deployment guide,
Chapter 9 "Multiple Interaction Servers in a Single Tenant" which recommends and lists benefits of Functional Separation of assigning
a separate instance of Interaction Server.
Genesys recommends and lists benefits to have multiple instances to Ixn Server but it does not describe the required configurations.
We have single instances of simple eServices flow involving ESJ + IXN Server + UCS + Routing Solution + Historical Reporting (Datamart + Infomart)
We were planning for below proposed new architecture :
1) We will have new Email Server and Interaction Server working parallel with existing Email Server and Ixn Server.
2) Both ESJ will not contain any common mail box and will submit interactions in their respective Interaction Servers.
3) Both ESJ will have same default-inbound-queue as "Email Inbound Queue"
4) Common URS should support both Interaction Servers, all the strategies has to be re-activated by selecting both Ixn Servers instead of single Ixn Server.
5) In outbound strategy, Outbound mails will select which ESJ to submit interaction to "Create Email Out" block depending on decision taken in strategy,
Email Server will be selected as a variable instead of actual EmailServer.
But we have come across a hurdle when we added one more MM Switch to be associated with new Ixn Server.
As soon as connections were made, URS stopped processing any Interaction.
IRD was incorrectly showing the In Progress / routing counts in Monitoring / Loading Section as zero.
We were been told as eServices environment would support multiple instances of Ixn Server but would not support Multiple Multimedia Switches.
As MM Switch is associated with IXN Dummy application which is configured with same host/port of existing Ixn Server,
hence kindly suggest as how we would associate 2 Ixn Servers with one switch / Dummy Ixn Application.
Also suggest any additional improvement in above listed plan of proposed new architecture.
Regards,
Vikram Joshi
-
According to the eServices 8.1 deployment training guide (lesson 2 page 9) -
[quote]Per tenant - you can deploy at most 1 Interaction server[/quote]
[quote]Of course you can have a primary/backup pair[/quote]
-
Thanks Steve,
I do not have access to "Training Document" but then it seems there is this discrepancy if compared it to the official "Deployment Guide".
Regards,
Vikram Joshi
-
Hi,
Just had a very quick look at the documentation myself:
http://docs.genesyslab.com/Special:Repository/81mm_dep.pdf?id=a3943c9e-a677-405c-97a8-871199462bce
The salient points seem to be:
[list]
[li]If you deploy separate solutions within a single tenant, the usual architecture has a single Interaction Server processing all the interactions according to business processes that are defined for the entire tenant (which may include separate business processes for the separate solutions). The server also uses a single database to store all the interactions.
You can use Configuration Server security to allow a specific server instance to work only with a subset of Business Processes within a tenant.
Include only one multimedia switch per tenant to preserve Stat Server and URS support for Interaction Server.[/li]
[li][/li]
[/list]
So I looks as though in a single tenant environment you need a single MM switch (which is what caused your problems above) and then use CME security to control access to segmented business processes on a per IxN server basis. e.g. create a person, assign it to an access group, run a particular IxN server instance under that person/account, segment your business processes by IxN server account etc. etc.
-
genesysguru, this feature available from from:
Release Number 8.1.300.06 [05/31/13] – General
Support for Red Hat Enterprise Linux 6.0 64-bit
Support for multiple Interaction Server instances in a single tenant
Ability to restrict access by Interaction Server instances to specified Business Processes