LS Security with HR11 Drill Around- wait time

Name	Points
Greg Moeller	4184
David Williams	3349
JonA	3288
Kat V	2984
Woozy	1973
Jimmy Chiu	1883
Kwane McNeal	1437
Ragu Raghavan	1348
Roger French	1311
mark.cook	1244

ThomasT

Advanced Member

Posts: 27

2/17/2011 1:08 PM

I'm relatively new to LS Security and I'm building a new security class for HR users so that they can only see employees with the same user level. I built a new attribute in RM called 'UserLevel'.

I've read many of the postings regarding LS security so I'm familiar with some of the solutions.
I've also read the security manuals too.

I built a new ElementGroup called 'COUL' which contains Company and User Level

Here is the rule of the element group 'COUL' on the new Security class:
if (user.attributeContains('UserLevel',USER_LEVEL)&&SystemCode=='HR') then all access
else
no access

Then on the EMPLOYEE table I wrote this rule:
if (user.attributeContains('UserLevel',table.USER_LEVEL)&&SystemCode=='HR') then all access
else
no access

I refreshed security cache and restarted browser, etc. Logged in and launched HR11. I entered the company clicked 'tab' and it entered the company description, then clicked on the drill around for employee field. It brought up the panel for the employees but it took maybe 5 Minutes for the list of selected employees to appear. 5 mintutes is way too long obviously. I am expecting less than 30 seconds at the most.

I've looked over everything and I can't find out why the select is taking so long. Right now I'm not concerned with next and previous on the HR11. There are about 30K employees in the EMPLOYEE table.

Anyone have any ideas or insight why the select is running this long?

Thomas

Dave Amen

Veteran Member

Posts: 75

2/17/2011 6:19 PM

Thomas,
It appears that you're doing advanced things to solve this (pretty impressive for "relatively new")!

You've found an interesting feature about rules and drop-downs/selection lists/drills, but it's rather counter-intuitive:
- the LARGER the number of records that will be returned, the FASTER it returns.
- the FEWER the number of records that will be returned, the LONGER it takes to run.

I can tell you why that is, but it takes a bit more explaining, and the explanation may give you some ideas as to how to speed this up. Can you give me a call when you have a sec?

Best regards,
Dave
(303) 773-3535

Abdoul

New Member

Posts: 2

3/15/2011 3:30 PM

Dave,

I happens to be ins the same situation, except that mine goes even further and generates an Error 500 code on some of the selections. Were you able to find a solution?

Dave Amen

Veteran Member

Posts: 75

3/15/2011 4:07 PM

Abdoul,
I haven't seen a magic bullet solution. There are many ways to work around this (or simply live with it), such as these:

1) Adjust the rules to return a larger set of records whenever a user uses a selection list. That will cause it to return faster, but it may also display other records for the user to select, only to find they can't inquire on it in the screen.

2) Change the screen rule (in HR.or/HR.sr - not in LS9) so it uses a better index (highly technical).

3) Add a custom index that fits your needs exactly, and make sure your LS9 rules match the fields in this new index.

These aren't very pleasant, I'm afraid. I'm hoping to hear from others who have dealt with this!

Best regards,
Dave
(303) 773-3535

Abdoul

New Member

Posts: 2

3/15/2011 4:35 PM

Thanks Dave for the insight. I was actually leaning towards the index on the User_level field; but though i'd make sure it wasn't a system performance or configuration issue.

Roger French

Veteran Member

Posts: 545

3/18/2011 3:06 PM

What I have found out in my experiences that having the Auditing flag turned ON in security administrator, that was hogging resources and subsequently caused drill selects to take much longer than with it turned OFF. With it turned OFF, drill selects worked almost instantly for most circumstances.