This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

SAP ABAP Tools in Eclipse – ACM_UNEXPECTED_VALUE

Scenario: You’ve installed the SAP ABAP Tools in Eclipse and you’re trying to browse the catalog in a SAP Netweaver system.
You keep getting an error prompt which contains the error ACM_UNEXPECTED_VALUE.  Checking for SAP notes takes you down the path of ACLs and DCL for ABAP CDS views.  However, you’re not convinced this is the right direction to resolve your problem.

I had the above issue and it was a simple case of a large number of the ABAP CDS (Core Data Services) views in the database did not exist (they had either not been created or failed to activate). 

It was nothing to do with authorisations or permissions (I had profile SAP_ALL).
I was also seeing quite a number of short dumps related to “table not found” type errors from the database layer.

To fix the problem, SAP note 2519431 documents transaction SDDLAR (I was in a NW 7.52 system).

You can run transaction SDDLAR then select “All Missing DDL Views” in the section “Repair“; then click “Activate“.
It gives you the option of running with “Check Only“, without modification to the database.
Browse the list of returned objects that are missing, then when you’re ready, try and activate them all by re-running the report with the “Check and Repair” option selected.

HowTo: Hide SAP tables including USR02

Within an SAP system, the user account passwords are hashed and stored in the SAP schema table USR02.
If the SAP system users have access to transaction SE16, then it’s possible for them to view the USR02 table by default.

This would present the user with the opportunity of seeing the password hash values.

It would be possible to spot a commonly used password hash and provided the user knows the actual password text that generated the hash, could use it to log in as a different SAP user, maybe with higher privileges.

More importantly, if the user manages to modify the table through transaction SM30, they could set their own hashes.

It is better to create a new authorisation group for the USR02 table, then exclude this specific auth group from the user roles via auth object S_TABU_DIS and setting the “Authorization Group” field.

An example would be to create a new authorisation group “ZZND” (zz no display) in transaction SE54.
Then, still in SE54, assign all the tables you do not wish anyone to see, to the new auth group.

Use transaction PFCG to edit your roles and change authorisation S_TABU_DIS, so that the field “Authorization Group” is set to a range “$*” to “ZY*” (it excludes ZZ*):


The next time the users try to access the table, they will receive a no authorization prompt in SE16.

UPDATE 30/05/2014: The post above was based on R/3 4.7.  Later releases may have an SC auth group already defined with the USR* tables, plus others, already defined.  You may still wish to create your own ZZND auth group to ensure continuity across upgrades and for your own standardisation practices if you must customise the list of tables in the auth group.  Thanks Matt.