02-21-2013 3:26 AM
I’ve given SQVI access to a user. To limit the queries to Material Management (MM), S_TABU_DIS and S_TABU_NAM are restricted to MM. That’s working fine for data source = tables. But if the data source is changed to SAP Info Set Query or Logical database, you can pull info outside MM. Is there a way to restrict the data source?
Thanks
J
02-21-2013 8:20 AM
Hi Jennifer
I would remove SQVI if the user is business and not I.T. (even I.T. as well actually) and get them to define why they need to run SQVI and then ask a developer to create a custom report for them which is assigned to a custom tcode with relevant org level auth checks.
Kind regards
David
02-21-2013 8:20 AM
Hi Jennifer
I would remove SQVI if the user is business and not I.T. (even I.T. as well actually) and get them to define why they need to run SQVI and then ask a developer to create a custom report for them which is assigned to a custom tcode with relevant org level auth checks.
Kind regards
David
02-21-2013 7:58 PM
Hi David,
Thanks for the reply.
In lieu of SQVI, can we use SQ01? I’m not too familiar with queries but I think SQ01 can be restricted to specific infoset.
thanks
J
02-21-2013 9:55 PM
Hi Jennifer
No for SQ01, SQ02, SQ03
Stick with custom transaction running off defined ABAP with authori* checks. Anything else will give problems.
That's my personal opinion....
Kind regards
Davids
02-22-2013 2:40 PM
Hi David, you can successfully maintain auth checks within a query infoset but by the time you have finished messing about with that you may as well do the job properly as you described.
A few years back I had a project where we had a few thousand queries, several hundred infosets (unrestricted) and a few weeks to meet a data law. Properly coded reports would have solved that particular fun time.
02-22-2013 2:54 PM
Hi Jennifer and Alex
I should have been more precise on my 'No to SQ01..' 🙂
@ Alex - good spot sir!
@ Jennifer - it depends on the number of users who are already using and abusing queries in your client's system so it may not be possible to resist those requests for access.
If you can refuse to assign SQ01, SQ02 etc then all the better as that forces the business to go down the developer route and reduces your (and the business) overheads.
If you can't then I think Alex is absolutely correct in his appraisal.
Best wishes
David
02-22-2013 4:42 PM
Jennifer - I realise I haven't responded to your original question.
You can't restrict the source in SQVI as standard.
If the source is an LDB (Logical Database) then any auth checks in that LDB will be enforced when executed. If the source is a query infoset then checks are still performed on the tables that make up the query infoset. Users will still only be able to report on the tables they have access to so if they are restricted only to MM tables then that is all they would have access to.
If you are in the situation where you can grant SQVI or SQ01 then I strongly recommend that you nip this in the bud now and take the approach recommended by David and have reports developed properly with auth checks in place (assuming that you don't want to do the reporting out of BW). If people really want to use SQ01 then have the reports developed in dev & transported through to prod where users can run them but not edit them. A very real problem that I frequently see is that users build a set of reports that pull in data from different sources without completely understanding the data source. This leads to different people reporting different figures as they are not using identical data schema's.
02-25-2013 2:58 AM
Hi Alex and David,
Thanks for your inputs. Very helpful indeed.
I will go for your suggestion of developing reports instead of giving access to query. We only have a handful of users with access to the tcode and not much queries created. Hopefully it's not going to be a big task.
regards
Jenn