Limitation in the number of global groups?

[deleted_user]

Hello everyone,

I'm now setting up a test environment - "discovery" might be more appropriate - and that includes the creation of folders, global groups and setting permissions.
There will be something like 20 standard folders and subfolders per study and 8-10 study specific groups. In total, there could be over 3000 new groups each year.

I'm looking for some experiences and feedback about the SDD global groups. How many groups do you have in your production instance? Did you notice performance degradations with the number of groups increasing? Any advice regarding the management of permissions in the system?

Thank you,
François

[Russ_N]

I don't know if there is a performance impact by using a large number of groups, but there can be an impact on whoever is creating or maintaining the groups.

It sounds like we might be using a similar general directory structure. We basically have an environment level (development/qa/production) with a compound folder under the environment and a study folder nested within compound. A series of standard folders are then under the study folder. Kinda like this:

prd
|-compound
|-|-study

(sorry - hard to indent and draw properly on this forum)

Originally, we were going to create groups on the study level. But since there could be a number of studies for each compound, not all of the studies are created at the same time, and it is common for the same users to work on multiple studies within the same compound, we thought that it would be better to create groups at the compound level (as well as some "global" groups, for users that would work on all compounds).

-Russ

Message was edited by: Russ N Message was edited by: Russ N

[deleted_user]

Hello Francois,
Very short, it certainly is important to consider the hierarchy of the study structure thoroughly. If you design your structure closer to the one recommended by SAS, you will be have a better performance, since they have given some thought to the logical design but then again you have to consider your business side and see how you can map the business side to original structure. Deep folder structures are recommended. It will also depend on what data you are going to have in the environment.

Which version are you running now and do you mainly use the web based console or PC sas?

Your internal network infrastructure has also has say in this. Make sure how the routing is as smooth as possible, reduce the bottlenecks. Which can improve performance to a greater extend.

Regarding groups its not a problem, managing it will be a problem. A good way to delegate levels of permissions is to have group at lower report level folder (standard folder structure) and give them autonomy where further allocation of permission rests on the selected groups.

I would suggest the following:

PRODUCT (no access other than read to users) access to admin
----Indication (ditto)
-------Study (ditto)
-----------Report (ditto)
--------------subfolders (major group level access controls)
------------------subfolder (lead designates & allocates permissions)
------------------subfolder (ditto)
------------------subfolder (ditto)
--------------subfolders
--------------subfolders
------------------subfolder (lead designates & allocates permissions)
------------------subfolder(lead designates & allocates permissions)
------------------subfolder(lead designates & allocates permissions)

--------------subfolders
------etc

Hope it helps.

If in doubt ask away.

/Joe

[deleted_user]

Hello,

Thank you both for your feedback.

We installed the version 3.4 on 3 UNIX servers (not ASP).

Regarding the maintenance, I should have mentionned that we plan to automate the creation of folders, groups, etc. using the API. I wrote some JAVA classes to connect to an ORACLE DB, retrieve the list of compounds & studies to be created, create the folders & groups and set the permissions according to an XML file (SAS made something similar since then, I think). Maintenance should not be an issue...

The reason why I asked about the number of groups is that I have a problem with two 2 API methods. GetAccessControlList and UpdateContainerAccessControlList are managing the permissions on folders but compared to other API methods they are very slow (500 milliseconds vs 5/10 seconds). SAS is investigating and it seems to be specific to our environment. In the meantime I list all topics that might potentially impact the performances and groups might be one of them.

About the folders hierarchy, I'm afraid we cannot apply your strategies. Not all users should see all compounds, not all compound users should see all studies, not all study users should see all data / reports. Our ambitious project is to have everything in SDD from the cleaning reports (+ SAS programs & datasets) to the statistical reports (+ SAS programs & AD). But that includes monitoring reports, metrics, etc. Because of the large audience, we have to restrict access to parts of the study folders hierarchy. As mentionned in my original post, our estimation is 8/10 groups for each study.

From what I read Joe, you think it shouldn't be a problem to have 3000 or more groups (apart from maintenance aspects)? Sorry for being tactless but could you tell me how many groups you have in your instance(s)? Also, are you using the API?

Thank you,
François

[Matt_SAS]

Francois

The SAS SDD QA team has tested the creation of 20,000 groups without any incident. We don't have any data as to whether there will be any performance issues with large number of groups.

Matt