List of Read-Only Server Applications...?

[tony]

Hello!

I found a decent question on the KB at Genesys, where someone had asked for a list of Applications that are Read-Only and therefore viable to run from a Config Proxy.  Unfortunatley, the reply was rather less than informative, in that it states that there is no "official" list and it would be better to review individual Applications, to determine if they are RO...

I wondered if anyone has been through this exercise and might have already listed (generally) the Applications which are Read-Only and therefore viable to connect via a Config Proxy?

If not, when I'm done, I'll post them in this thread...

Thanks!

Tony

[Daimonas]

From a client-server point of view, client being application and config application being the server, I run all my applications using a config proxy with no problems.

[Steve]

On our platform we use proxies for CC-Pulse, WFM – Configuration Utility, WFM – Database Utility and Outbound Contact Manager.
And not for Configuration Manager, IRD, Data Modelling Assistant, Genesys Agent Desktop and Solution Control Interface.

Thinking about it now I can't think why SCI needs to write to the config database!

Currently the proxies don't really offer us any advantage. We are using external authentication for all users and all authentication requests have to go through the Config Server. There is a FR with Genesys to allow the proxies to interact with the authentication servers directly, thereby reducing the load on the main CS.

[tony]

Thanks Daimonas, Steve...

I don't think I could consider that all Client Applications would run from the Proxy - since I know that things like GAD and DMA do write to the Config Server... I guess I should have listed what we have;

ICR (Enterprise and Network)
MCR (email - with GAD/GSD)
WfM
CCA (with Brio)
OCS
Softphone
TLib
Stat SDK
...etc...



- Also, LDAP would be a problem I hadn't yet foreseen... LDAP Authentications via Config Proxy = NO, currently...

These are much appreciated - Thank You both!

Tony

[René]

Hi Tony,

Maybe it would be easier to prepare list of applications that requires read-write access. Here is list (off top of my head):
- CME
- IRD
- SCI (change of logging options)
- DMA (synchronize statistics)
- WFM DataAggregator (agent synchronization between Configuration and WFM database)
- Multimedia Knowledge Manager
- Multimedia Universal Contact Server
- Genesys Agent Desktop (could be run with CfgProxy with some limitations - agents can't save preferences + custom dictionary)
- SIP Server (if internal registrar is enabled)
- [i]OCM (not sure about that...)[/i]
- any custom application that modifies Genesys configuration

René

[Daimonas]

Correct, anyone who requires administrative access to clients such as config manger, Genesys desktop, SCI, DMA, etc. would want to connect directly to Config Server.

However, find it handy to have most users/supervisors connect to proxy's if write access is not needed, specially for contact centers across the WAN. This way we can do maint. on the config server itself and not interfere with their access.

Rene - Only write access need for OCM is to update viewing filters and save them for future use on calling lists.

Good point regarding LDAP auth, wonder why that not supported on proxy. Same binary version running it, I thought it would.

[tony]

Sorry - I'm not clear on something, now...

We have CCPulse+ running and some of the instances connect to a Config Proxy, using Port 2030 (i.e. not 2020) - this is providing LDAP authentication.  It works because it is also connected to the Config Server itself.  I understand that this means that the Config Server is still used for LDAP authentication (the "down side") however that was not the goal of installing our Config Proxy - the reason the Config Proxy was installed was to decrease the number of Clients once changes are Broadcast by the Config Server (the "up side").

So - although the Client will authenticate via the Config Proxy, to the Config Server because of the LDAP "issue", it also means that there are 200 clients [i]less [/i] for the update/change/delete Broadcasts from the Config Server...

- Does this make sense?

Tony

[René]

[quote]So - although the Client will authenticate via the Config Proxy, to the Config Server because of the LDAP "issue", it also means that there are 200 clients less for the update/change/delete Broadcasts from the Config Server...[/quote]

Absolutely right Authentication requests are forwarded to Configuration Server, all others are served by CfgProxy or rejected (write requests).

R.

[tony]

Thanks for the clarification - so, given that CCPulse+ only needs to authenticate once per session/day, it is a relatively small overhead - the benefits being that any config updates that run from the Config Server, go to 1 Application (the Config Proxy), instead of hundreds of CCPulse+ clients

Knowing that there are many more updates throughout the day, than CCPulse+ client authentication requests - the maths is clear to me;

250 x CCPulse+ Client LDAP Requests, via Config Proxy, to Config Server = 250 requests per day
Config Server Update Broadcasts (without Config Proxy) = 250 broadcasts per change
Config Server Update Broadcasts (with Config Proxy) = 1 broadcast per change (250 broadcasts per change for the Config Proxy...)

I think the Config Proxy idea still works for me, even if it does use the Config Server for LDAP authentications and this is the reason I was looking for anything else that will be able to use a Config Proxy...

Tony

[René]

CCPulse sends multiple authentication requests but you'll be ok if number of simultaneous authentication requests won't be too high (=several per second). I don't assume that all CCPulse user do login the same time...

R.

[Steve]

Tony, Pulse is a minor issue for us. We have about 10,000 agents, although these don't all login together we do see 4 -5000 logging in between 8 and 9. Many of these will open WFM and GAD, in addition to this WFM supervisors and CC-Pulse users also login as well as a few SCI and IRD users.

All this hammers our Config Server as all the authentication request have to go through it, and it works sequentially. Delays of 70 - 100 ms are common. When the proxies connect to the authentication server directly we expect this time to reduce.

[tony]

Thanks Steve - are you saying that using a Proxy is what you do - or what you want to do?  If you have already done it, is it possible to quantify the difference for the access to the Config Database?

Tony

[Steve]

Tony we do use proxies, and when we get the next version which can talk to the authentication serevrs directly, we expect the CS load to drop. Once I get some figures I'll add to this thread.

[Timur Karimov]

Sorry - but now I'm not clear on something....

when i setup the multi-site configuration, i install primary and backup config server on main site and the config proxy server on remote site. on remote site i have GAD server and same agent with supervisors. But for supervisor's can do any maintency job, such as change agent property or something we mast have read-write access to config DB, right? but config proxy provide only read-only access to config db. well it sound stupid but why we need proxy server if it's not provide service what we need? and again what we may do for bring away this stupid and ridiculous question ?

[tony]

Timur,

This is exactly the point I was trying to make, earlier in this thread; for GAD/GSD to function effectively, you need to have READ/WRITE access to the Config Layer.  Your GAD/GSD Clients would be connected to a Config Proxy, which needs to have the (Primary) Config Server as a [i]Connection [/i] within it's [b]Options [/b] in CME.  That is how it would be able to READ/WRITE to the Config Database; through the Config Proxy, via the Config Server, to the Config Database.

This means that, even though you are using a Config Proxy, sometimes it is used to READ/WRITE to the Config Server, because they are connected.  So - why bother with a Config Proxy - right?  There are 2 main reasons;

1. The User authentications for Logins from GAD/GSD (i.e. not READ/WRITE, but READ ONLY) will only have to use the Config Proxy and not the Config Server - even if the 2 are connected in CME.
2. Any [i]Broadcasts [/i] from the Config Layer will see the Config Proxy as just 1 Application and send just 1 Broadcast to that Application, instead of having to send hundreds of Broadcasts to Clients (all of the instances of GAD/GSD).  This removes a lot of strain from the Config Server, since you are remvoing Clients to a Config Proxy.  Less Clients on the Config Server = overall speedier responses = more stability for the Platform!

I've drawn some pretty pictures, to illustrate this - someone please correct me if I am wrong!

Tony