CC 5.2: Only BASIS User Analysis

[Former Member]

Hello All.

We had just installed GRC CC 5.2 in the Organization. All setup and configure is running OK. We scheduled the first full Synch User, Role & Profile synch Job. Then a schedule was performed for Batch Risk User, Role & Profiles analysis. We obtained the Informer User Analysis as follows:

No. of Users Analyzed 18,066

Users with no Violations 18,053 .... 100%

Users with Violations ....... 13 ..... 0%

Only the BASIS users taken is incorrect. I think we are making something wrong with the configuration default values for the GLOBAL risk analysis.

Default report type for risk analysis = Permission Level

Default risk level for risk analysis = All

Default user type for risk analysis =All

Default rule set for risk analysis =GLOBAL

Exclude Locked Users, Exclude Expired Users, Exclude Mitigated Risks = No

The <Report Type> value for the Batch Risk Analysis was obtained only with the Permission Level Analysis checkbox mark`d.

Kindly suggest me the difference between a Permission Level or Action Level Config parameters in combination with the Batch Risk Analysis.

Hope somebody would answer or suggest!

Thanks and Best Regards,

Victor.

Edited by: Victor Sarabia Rangel on Jun 1, 2008 6:28 PM

[Former Member]

Hello Prem.

After a great execution of our Basis Team and the very skilled involvement of GRC Director were the part players to attain our goal: the steady performance of GRC landscape. I appreciate your help and patience all this months.

http://www.grcexpertonline.com/article.cfm?session=&article=2863

Here I include some very usefull notes that produce a favorable outcome, and do not forget to apply SP09.

Apply:

SAP Note 1022187

SAP Note 1178370

SAP Note 1034117

Best Regrads,

Victor

[Former Member]

Hello,

We are using CC 5.1 and applied the settings in note 1121978 and now see in the logs:

Jun 27, 2008 6:34:06 PM com.virsa.cc.xsys.riskanalysis.AnalysisDaemonBgJob start

INFO: Daemon idle time longer than RFC time out, terminating daemon 0

Jun 27, 2008 6:34:06 PM com.virsa.cc.xsys.riskanalysis.AnalysisDaemonBgJob start

INFO: Analysis Daemon ID 0 terminiated

Jun 27, 2008 6:34:06 PM com.virsa.cc.xsys.riskanalysis.AnalysisDaemonBgJob start

INFO: Daemon idle time longer than RFC time out, terminating daemon 1

Anyone have this issue? Sounds like it is misreading the RFC time out of 1441 minutes?

Thanks,

Paul D. Chamberlain

[Former Member]

Hi Prem.

That would be great.

Jun 28th We implemented

sapnote 1044174

.

And the JOB began to move, at the moment we have 1692 Out of 11286 (14%) done in the second Job(Profiles), the job(Roles) completed 100% succesfully this morning. We hope keep the pace and move forward to populate Graph with the Management Report JOB.

So far so good,

Best Regards,

[Former Member]

Hi Victor,

Here you go as promised , the way to debug CC java tables.

The table VIRSA_CC_GENOBJ holds data of users pofiles and role

table VIRSA_CC_PMRVL holds results from the batch job for batch risk analyis( from the scchedule anlaysis tab)

by executing the following query

select count(*) as tot from VIRSA_CC_SYSUSR where vsyskey='SID' ( SID is for the back end for which you are trying to sycnh)

the above statment should tell you the numebr of users .

after that Run

1.select * from virsa_cc_genobj where genobjtp=1 (and this displays the no for users wrttien in the back from the sycnh and if pressdelete the users the entries will be

deleted and you can do the fresh full sycnh .

2.select * from virsa_cc_genobj where genobjtp=2( this is for roles,delete if you want to and you can do the full role sycnh afterwards for resh figures)

3.select * from virsa_cc_genobj where genobjtp=3( this is for profiles , delete if you want to and you can do a full synch for the profiles)

Hope this helps let me know how it goes

Prem

[premb]

Hi Prem,

I do not think it is advisable if you have same user (for ex) in more than 1 system. In that case you will have 1 entry for all the system, And if you delete the user, then it will be deleted for all system. The table will store only the first system and after that if you add the same user for different system, it will not store or update. So there is a chance of not deleting the record for that system or deteling for all the systems.

Thanks

Prem

[Former Member]

Hi Prem.

I Appreciate your soon response. We will consider your recommendation as soon as we can solve some difficulties with a new first synch JOB.

Job was scheduled at 11:02pm yesterday , CC presents the following message after one hour processing (00:05).

Jun 27, 2008 11:02:34 PM com.virsa.cc.xsys.riskanalysis.AnalysisEngine performActPermAnalysis

INFO: Job ID:27 : Analysis starts: AADCON1000

Jun 27, 2008 11:36:25 PM com.virsa.cc.xsys.bg.CCWarDaemon deleteTempSpoolFiles

INFO: Clean up spool directory...

The JOB does not moves forward.....

We have applied the next notes:
1063596 y 1034117

The JOB does not crash but does not move either,

this was our last log view.

Jun 28, 2008 8:22:34 AM com.virsa.cc.dataextractor.bo.DataExtractorSAP getObjPermissions

FINEST: getObjPermissions: elapsed time=720ms

Jun 28, 2008 8:22:37 AM com.virsa.cc.xsys.riskanalysis.AnalysisEngine performActPermAnalysis

INFO: Job ID:27 : Analysis done: AADCON1038 elapsed time: 15912961 ms --- 2 Out of 10619 (0%) done

Kindly suggest ups and downs.

Best Regards,

Victor

[Former Member]

Hi Vicotor,

I know probably you have these parameters settings as betow under config performance tuning tab, but if you dont please set them as below.

Batch size for User Synchronization = 1000

Number of Web Services Worker Threads= 5

Number of Background Job Worker Threads=3

RFC time out for Web Services / Background Job Worker Threads (Minutes) = 1441

as it could be a performace issue , but however the full synch could take quite a while , specailly the batch risk analysis for users, roles etc this could take even upto 10 hours some time .

I had issues with job runnign too long and disk running out space for about 2900 users , and it want overwriting the entires rather it making a new entry every time I ran the full synch , so I had execute certian SQL statements to remove the enties from the back end.

Regards

Prem

[Former Member]

Hi Prem. Definetely it is a performance Issue. We reviewed the parameters and read as follows:

size=1000, threads=5, backgroundJobs=3, TimeoutRFC=1441

Our first guess ,we think ,has to do with the number of server nodes in Java (up to 4).

Second guess , i assume we must put attention to ORACLE BD performance.

The Batch Risk Analysis JOB was broken to only 100 users and is stuck in the very first....

We applied SAP note 1121978, we are waiting for the SAP Global Service Consulting response

Jun 28, 2008 11:03:04 AM com.virsa.cc.xsys.util.RuleLoader getActRuleMatrix

INFO: Action rules cache loaded: memory used in cache=-17M, free=1690M, total=1962M

Jun 28, 2008 11:03:04 AM com.virsa.cc.xsys.util.RuleLoader getActionRules

FINEST: riskRange is empty => all risks

Jun 28, 2008 11:03:04 AM com.virsa.cc.xsys.util.RuleLoader getActionRules

FINEST: Rule Loader Rules Size=>41937

Jun 28, 2008 11:03:04 AM com.virsa.cc.xsys.riskanalysis.AnalysisEngine performActPermAnalysis

INFO: Job ID:28 : Rules loaded, elapsed time: 10567 ms

Jun 28, 2008 11:03:06 AM com.virsa.cc.xsys.riskanalysis.AnalysisEngine performActPermAnalysis

INFO: Job ID:28 : # objects to analyse: 100

Jun 28, 2008 11:03:06 AM com.virsa.cc.xsys.riskanalysis.AnalysisEngine performActPermAnalysis

INFO: Job ID:28 : Analysis starts: SAPGRPPR1

Jun 28, 2008 11:44:22 AM com.virsa.cc.xsys.bg.CCWarDaemon deleteTempSpoolFiles

INFO: Clean up spool directory...

Jun 28, 2008 12:44:24 PM com.virsa.cc.xsys.bg.CCWarDaemon deleteTempSpoolFiles

INFO: Clean up spool directory...

We have 17000 users and 10300 roles scenario to analyse, could you please help me with the SQL Information that you
mentioned?

Note 1121978 settings...

Minimum Java Options for 6.30/6.40/7.00 SAP systems:
-XX:PermSize=256m (before 192m)
-XX:MaxPermSize=256m (before 192m)

Heap size recommendation:
-Dispatcher heap size=256m (before 170)

5. New Generation
-XX:NewSize=341m (before 320m)
-XX:MaxNewSize=341m (before 320m)

6. Permanent Space
-XX:MaxPermSize=512m (before 256m)
-XX: PermSize =512m (before 256m)

JCo Connectors
u2022	VIRSAHR_METADATA
o	max pool: 50 (before 5)
o	max connection: 100 (before 10)

u2022	VIRSAHR_MODEL
o	max pool: 50 (before 5)
o	max connection: 100 (before 10)

u2022	VIRSAR3_01_METADATA
o	max pool: 50 (before 5)
o	max connection: 100 (before 10)

u2022	VIRSAR3_01_MODEL
o	max pool: 50 (before 5)
o	max connection: 100 (before 10)

Thanks again for your time and interest.

Regards,

Victor

Edited by: Victor Sarabia Rangel on Jun 28, 2008 9:28 PM

Edited by: Victor Sarabia Rangel on Jun 28, 2008 9:39 PM

Edited by: Victor Sarabia Rangel on Jun 28, 2008 9:56 PM

[Former Member]

Hi Victor

Ok , I will have to give you the SQL statement on monday , hope thats ok with you, as I have written it down on my pad in the office

there are two SQL queries to execute

1.first one is to read how amnay enties are in the back end .

2. second is to delete the entries and restart the server and do a fresh full sycnh , dont break into ranges .

but it looks like you DB is oracle ,so delete the entries accordingly

so I will send you them statement first thing in the morning when I get to the office

Regards

[Former Member]

Hello Victor,

The difference between the permission and action level during batch analysis is as follows:

Action level analysis only tells you who has access to a particular transaction code, this is helpful in certain cases where a user should not have access to two defined transaction codes, you could pick this up here.

Permission level analysis tells you in addition what permissions a user has within a transaction (authorization objects and values), this is helpful in transactions where multiple activities can be performed within one transaction code.

I think the paramter you have set "Default report type for risk analysis = Permission Level" is correct, because the permission level will offer you a more comprehensive analysis.

When you scheduled a user analysis also check what User Group you specify as this could narrow the results, if you insert a "*" then this should analyse all users.

If your reports are still not showing correctly, you could also check that the correct function-action and function-permission files have been loaded for each system, this could also possibly be affecting your results.

Hope this helps.

Regards,

Chris

[Former Member]

Hallo Chris. Sorry for the late answer but this has been a very long and difficult issue with SAP so far.

We logg´d into the system and verified that the Analysis Daemon is not running. We look´d at SAP Note 999785 on how to test the Analysis Daemon. Also under the Performance Tuning Tab in the CC Configuration.

We reset the Web Service Threads to default 5 and the Worker Threads to default 3 and restart the server. Also check

the Analysis Daemon to see if the Job Worker threads and WS are visible and are on IDLE State before we runn´d any further jobs.

We have attached a new file "ChangedIP to the host in the BgJobStart URL.doc"; it shows, after restart the server, the

situation. We reapply SAP Note 999785 . The issue has changed...we have a new log in Jobs.

Looks like the issue related to the Background Daemon not configured is resolved. But now we have a new issue due to critical Performance problems during Batch Risk Analysis Job.

We apply Note 1121978 with recommended Jco settings. Then restart the J2EE server after these changes were made.

"Do we have any possibility in order to restart the Job analysis from 90% to the end after restart J2EE? or Do

we need to run the full analysis again?

Kindly need further suggestions.

Best Regards,

Vic

[Former Member]

Hi Victor,

hope you dont mind me answering your question, I am currently working with CC 5.2 myself . you need to do the full synch again , they is no way that the job will pick up form where left off .

Break down the full synch into 8 jobs,

1. full user synch in ( synch mode)

2.Full role synch

3.full profile synch

4. Batch risk anlaysis for users ( full synch mode) ( select the system and put * in user field and user group field)

5.Batch risk anlaysis for roles ( full synch mode)

6.Batch risk anlaysis for profiles ( full synch mode)

7.Batch risk anlaysis for critical actions ( full synch mode)

8.finally the mangement reports by itself .

there adter set the incremental jobs weekly .

bare in mind one thing mate this full sycnh chews up a lot of disk space.after all this if you still dont see any change in the mangement figures you need to check entries on your database .

hope this helps .