There are quiet a few companies that want to give end-users access to extract table data via SE16 or SE16N. If you decide to give SE16N, please read our blog that shoes the pitfalls & danger of giving SE16N – In addition, the auditors, security people and basis folks worry about using having transactions such as SQVI, SQ01 etc…. Why is that? For starters, users can access confidential data once they can use SQVI as it is not protecting the data to be extracted by company code or other organizational values. A guideline on how to convert SQVI report into a InfoSet query will be published on this blog.
In addition, SQVI reports, if created poorly, can have a drag on system performance as the endusers never have performance in their minds and run queries over millions of records with inadequate table joins. The same applies to SQ01 – SQ03 transactions. These are a red flag for most of the auditors also if the user is allowed to add custom code on InfoSet level. Security managers usually recommend that SQxx transactions are used in a development environment and the queries mapped to transactions so that these can go through Change Control and given to users via roles in a controlled manner .
Firstly, end-users should not have SE16 nor any other ‘help yourself’ transaction in a productive environment – period -. To make things less critical, you may want to create custom transactions that calls one table (example ZSE16_MARA) and secure the user roles so that they can access only specific tables via S_TABU_DIS.
However, this opens a new can of worms. Now, the user can view data for all company codes, plants etc. and sometimes you really don’t want this as you spent a lot of money & time creating roles that limits the users to their turf.
If this is the case, you can use object S_TABU_LIN and secure by company code, plant, sales organization and more. However, to maintain these settings, ca be rather time consuming.
Aha! I don’t need this, you may think and hand out SQVI or ABAP Query to these users – not a good idea, unless you love people digging around everywhere and slow down your system. Also, limit by organizational values is rather difficult with query tools.
Hmm, what next? Well, what about a tool, that can be run outside of SAP, is SOX compliant and gives the user a easy to use & quick way to extract data into Excel or Access? A tool that considers the SAP Authorizations the user has and only delivering the data the user is actually able to access in SAP? If this sounds like a good thing to have, please don’t hesitate to contact us via the contact us link or by clicking here! We will be more than happy to talk to you and to give you a demo! We can also send you a whitepaper on how to setup roles by using the s_tabu_lin object.
Add
Add
Comments