If applications are “behind” CSProxy, you can set this specific account as “Log on as” only on CSProxy application. Less work, the same effect. All applications behind CSP will see only those objects, that this specific account will have access to.
Sometimes, even with complex configurations, it’s better to play around with CU after all, than to do everything with subfolders. From day-to-day maintenance perspective, work done to configure CUs will prospect in the future with simpler management. For example if you’ll need to change persmissions on all Voice objects, with subfolders you will have to do it in several places in CME (possibility of forgetting something). With CU this can be achieved simpler.
You are right on expected results. No matter which method do you use (Subfolders or CU) permissions allow to reduce data throughput and network traffic, improve stability and efficiency of Genesys applications. Of course this is very dependant on configuration.
Configuration units are special folders created under Environment and Resources. These can then hold the same folders you would normally find under Environment or Resources. In a sense they start to create a multi tenant CME inside a single tenant one. Unlike multi tenant, were tenant A cannot see or use another tenant’s objects, the restrictions are controlled only by permissions and can be less strict.
So in a single tenant CME for one customer (My Bank) you have a series of config units for each division (Loans, Mortgages, Savings). Within these config units you can add folders to hold whatever objects that division has, its own switch, t-server and persons for example. You can even have config units inside config units!
It is then very easy to grant permissions on the Loans config units to only the Loans access group (which lives inside the Loans CU).
Whilst writing this I found a new config option “Site” when I select new at the Environment and Resources level.
Sites can exist inside config units too. Something to play with in a model
After a period of R&D (also known as “trial and error”… ) I’ve found the best method to reduce “traffic” on a non-blended Platform to be;
Create new Users for your Voice Interactions (ICR) and Mutlimedia Interactions (MCR).
Give the new Users FULL Permissions to all Environment and Resource assets in CME (The same as the “default” Username) and apply the changes to propogate throughout all Sections.
Identify and separate your ICR and MCR assets in the CME Resources section by adding sub-Folders and moving items into those. For example; move your GAD/MCR Agents to a sub-Folder called Persons>MCR…
Set restricted Permissions to the sub-Folders for your new Users;
For MCR assets, add the ICR Username to the Permissions for the CME sub-Folder and apply “No Access” and repeat the process for Agent Groups, DN Groups, Persons, Place Groups, Places, Skills and Switches.
Take a look at your CME Applications in the Environments section and determine which are solely ICR and which are solely MCR. For example; a Voice Interaction StatServer which serves a Voice URS/TServer is solely ICR… (<this can include, but is not limited to, Configuration Proxies…)
Change the Security settings of the Application, so that it starts up using your Solution-specific Username. In my example, “Log On As” would be changed from “default” to the ICR Username.
Restart your Application(s).
Test your Application by adding/amending/deleting assets in your new CME Resources sub-Folder structure - if you add a Skill to the Skills>ICR sub-Folder, check your ICR and MCR StatServer logs - you should find that the update propogated to ICR StatServer - but does not appear in the MCR StatServer log…
In my own studies, I have proved that this method reduces the amount of irrelevant messaging/notifications by up to 50% for MCR assets - and up to 30% for the ICR assets. A huge uplift in processing and stability!
CSP’s may have Clients which themselves have Clients which require Full Access to CME. In my studies, I found that some Applications using a CSP threw up errors due to the fact that their own Cleints required updates for Objects which the CSP does not have acess to…
So - in my latest notes I am suggesting that individual Applications should be updated through Permissions - and my advice is to be very careful of the knock-on effect updating the Permissions a CSP might have…
) I’ve found the best method to reduce “traffic” on a non-blended Platform to be;