How to restrict data range in customized report in ECC6

[Former Member]

Hi Gurus,

We have a question of how to restrict data range in customized report in ECC6, and we are looking for a solution with best practice.

We have a customize report contains the global data that need to be restricted based on company code that is assigned in user authorization profile. We have done some research and found out:

1. Hard code for security check in the program u2013 not recommended for best practice?

2. Report Tree with variants u2013 the best practice SAP recommended?

Do you know if any other option and SAP documents that we can explore more?

Thanks

Cicy

[Former Member]

Hi Cicy,

If you wish to restrict the data range in the report, the best option is to implement Line items restriction using S_TABU_LIN on the company code field in the table from which the data is pulled in. You can further restrict the table access with S_TABU_DIS authorization object.

Hope this helps!!

Regards,

Raghu

[Former Member]

Use a coding techique which natively contains the needed checks, such as a logical database.

This is normally the easiest way to write a custom report and is almost idiot proof, even for non-programmers.

Downsides: only simple reporting, not performance optimized, inflexible compared to the rest of ABAPs power.

Cheers,

Julius

[mvoros]

Obsolete as well. I would highly recommend avoiding logical databases. You can't use them in OO context which probably does not matter for reporting. There are some problems with tracing and debugging as well.

I am not sure if I understand you scenario but if you have a custom report then option 1 is the standard way. All your custom development should contain all authorization checks directly. Don't forget to maintain entries in SU24 for custom report.

Cheers

[Former Member]

Essentially I think you've captured the options already, though I'd keep it more generic: I.e. add the authorization check on coding level or limit the user's selections by predefining which company codes are used. For the latter you obviously don't need a report tree, though it's likely that you'd want to integrate it in your menu.

Now both options have their pros and cons, let's look first at adding the authorization check on coding level. I second Martin's comments and think that even even for a standard SAP report you possibly could enhance it by adding an appropriate authorization check. In ECC 6.0 your possibilities are almost endless as you can utilize also implicit enhancements (e.g. see SAP online help on [enhancement concept|http://help.sap.com/saphelp_nw70/helpdata/en/42/d356adddec036fe10000000a114cbd/frameset.htm] and [implicit enhancement options in ABAP source codes|http://help.sap.com/saphelp_nw70/Helpdata/en/29/e59441026aae5fe10000000a1550b0/frameset.htm]).

Note that from a developer's perspective I'd refrain from usage of the term hardcoding in this context, because you actually just add the authorization check that returns a result based on the user's profile. Hardcoding usually implies using some fixed constants in your program and is a term that is likely to raise some eyebrows and won't even remotely be associated with best practice.

The main advantage of coding the authorization check instead of using fixed variants is the higher degree of flexibility and less maintenance efforts for required variants/menu updates. I.e. depending on your number of and possible combination of authorization fields/values the number of variants can easily explode. In your case this might be less relevant, but could still be an issue if you have many company codes and users that support different ones (and don't want to run separate transactions for each one).

However, restricting a user to specific company codes by visibly limiting their selections (e.g. predefined, display-only select option/parameter) is easily understood by users and possibly faster done than adding a proper authorization check to the coding. Two main reasons that come to my mind:

<ol>

<li>For objects/documents that the user is not authorized to see, you'd have to define what should happen. I.e. should the program just quietly discard the data or is that bound to cause some confusion and the user needs to be informed somehow? The answer to this question might also depend on the execution mode, e.g. the report might be used as an overview (access via org and similar data) and to display single objects (access via individual object/document references).</li>

<br/>

<li>Sometimes performance considerations are important, i.e. ideally the report should avoid wasting resources. So if users are prone to enter selection criteria that extend their "authorized realm" and there is no need to inform them about discarded documents the program should avoid reading such data.

For a check on company code this could mean adding some simple logic to retrieve all company codes and filter them based on user's selection (i.e. what he entered on the screen) and her/his authorizations. So effectively you'd be building a range with chosen and authorized company codes that you could then use in your further selections.

Obviously this is straightforward in your case and should be efficient as long as your report can easily filter on company code without having to read much data before getting there. There's some examples though where this is not as easy, the classic example is probably displaying IDocs. I guess due to the complexity of the authorization object [S_IDOCMONI|http://help.sap.com/erp2005_ehp_04/helpdata/EN/48/937103842b454299a00fb5f6a34b5f/frameset.htm] SAP used to filter the IDocs after reading them (and probably still do in transactions like WE02, but I'm too lazy to check right now).

</li>

</ol>

If you choose the report-tree&variant solution I'd probably still check if adding a very simple coded authorization check might be beneficial (could be a good second line of defense that might come in handy depending on the different access paths to your report).

Cheers, harald

[Former Member]

Hi All,

Appreciated to all of your response! I was out and came back to work today.

Harald

Our programmer and I are working together this morning to do a test using the u201CAUTHORITY_CHECKu201D.

Thanks

Cicy