Validating QSoft's Claims: Role Limit, Performance, 2 Role Per User Strategy

mattbbpl

Member
We are using Qsoft to manage JDE 9.1. We're currently using a very rudimentary security setup in a proof of concept system, but we're looking at setting up a more robust "finalized" security structure in Dev and, later, production.

Researching, I found the following two blog posts from QSoft:

http://www.qsoftware.com/blog/trends-and-best-practise-on-enterpriseone-roles/

http://www.qsoftware.com/blog/row-security-in-jd-edwards-enterpriseone-part-2/

Pertinent portions:
1) "As of the 9 releases, the character limit means that a User can have around 30 Roles – which is a lot."
2) "The research is proving this; we are witnessing a move to 2 Roles per User to try and solve these two issues. Why 2 Roles? The first Role is the functional Role, defining what a bunch of Users can do, for example AP Manager. The second Role consists of the User’s Row Security, which restricts what data a User can see, for example Company A."
3) Well, unless you are suffering from performance issues due to high numbers of Row Security records

The trouble arises from the fact that the powers that be don't view QSoft as a reputable resource (and number 3, even from Qsoft, is vague). I've found Oracle documentation which validates Qsoft's claims regarding sequencing issues, but I'm coming up empty when attempting to find Oracle-sourced documentation confirming the three claims above.

1) What character limit is being referred to here? Is there Oracle documentation I can point the powers that be towards that confirms such a limit?
2) I'm familiar with this setup from 3 other systems I worked on in a past life, and it makes sense to me. I'm just having trouble selling the idea without an Oracle recommended best practice stating that it's actually a good thing to implement. Is there any Oracle documentation stating any portion of this concept, in whole or in part, is a best practice?
3) Is there any Oracle documentation specifying what levels/numbers we should watch out for to avoid performance pitfalls? I'd like to be able to point to numbers to avoid regarding total number of security records, security records per user, etc.
 
I found this document in the knowledge base (A 255 Character Limit Appears To Be Evident On Assigning Roles To Workflow Step (Doc ID 1501014.1)) https://support.oracle.com/epmos/fa...indowMode=0&_adf.ctrl-state=tpwtzj4rf_185#FIX

Which states, in part: "The list of roles that are authorised to perform a workflow step is stored in the database as a comma-separated string of roles. The size for this database column is 255 characters."

But I'm not sure if this is the same limitation as JDE. The states that it applies to Applies to:

Oracle WebCenter Sites - Version 6.3.0 and later
Information in this document applies to any platform.
 
Regarding performance, I'm seeing references in knowledge base articles for other Oracle products stating loose comments about, "it all depends on the OR comments generated". These products use a similar inclusive/exclusive row security model as JDE, filtering out records by appending WHERE clauses to the resulting SQL statements. Now, this performance impact would also affect JDE in a virtually identical manner BUT ONLY in regards to row security. If we separate application security from row security as suggested in the "two role model" then this provides evidence for a high number of ROW SECURITY roles affecting performance but it does not provide evidence for a high number of APPLICATION SECURITY roles affecting performance. Since such separation is allowed but not enforced (and apparently not encouraged) by Oracle, I think I'm unlikely to find any more concrete confirmation on the matter until we actually get to a point where we can do load testing under different scenarios.
 
Matt - there is a character limit. I believe it is 255 characters for a specific field. JDE puts all the roles together into a single field and queries based on that field - it at my customer where we discovered the issue and reported it back to QSoftware. The "30 roles" is an approximation based on a role being no more than 8 characters long (8*30=240 characters). I have more information on this somewhere - but I'll confirm that you don't want to have a user with more than 30 roles otherwise they hit this issue.
 
Keep it simple..

I guess I am wondering..Why don't you use one role per user?

Role = HR Job Title, one role per user. No possibility of misconfiguration such as one user with more than one role set to *ALL. No sequencing issues.

You can do all the same work in row security and attach it to the single role.

Malcolm
 
Thanks for your reply. This is exactly what I was looking for in this regard, I was just hoping for something more official. It looks like I'll have to demonstrate in a sandbox environment once it's available to do so.
 
I guess I am wondering..Why don't you use one role per user?

Role = HR Job Title, one role per user. No possibility of misconfiguration such as one user with more than one role set to *ALL. No sequencing issues.

You can do all the same work in row security and attach it to the single role.

Malcolm
The problem with one role per user is just logistical, not technical. It's easier to create 1 role for each employee type (i.e. plant manager, forklift operator, accountant, HR representative, etc.) and 1 role for each location than create a role for each employee type/location combination.
 
30 roles is the "limit" for a user though I have seen cases where users have far more than that and it has worked for them (I do strongly recommend sticking within the role limit however). As for limiting a user to only two roles, I have not seen this at any site. My experience with a job based role is that a users responsibilities change over time and you will usually end up with 1 role per user in this scenario. There are methods to alleviate the issue with the role sequencer. ALL Out Security manages and resolves any security conflicts between multiple roles allowing the flexibility of utilizing more standardized process based roles. If you are evaluating Qsoft, you should evaluate ALL Out as well and not just take any one vendor's word for what their competition can or can't do.
 
Back
Top