Why I Now Love SU24
By Gary Kirkwood
When I started at Winterhawk, I was unaware that SAP Transactions could have their standard values amended and that objects could be added to either customised or standard ones, in spite of my previous SAP Security & Authorisations experience. Then, on my first Winterhawk assignment, a colleague introduced me to SU24, a very useful transaction code. It allows a Security Developer to add or amend values within transactions so that every time a transaction is assigned to a role it brings in the authorisations you have set it.
Previously I’d been shown that objects needed to be added manually, or existing ones changed within the SAP Roles themselves, so it was incredibly useful when my colleague shared her experience and this new (to me anyway) functionality with me. Ultimately it makes it easier to assign values that are required for a client to streamline their authorisation concepts.
Not every business will require the SAP standard values; using SU24 allows the Security Developer to specify values that are in line with Business Processes. This is highly beneficial, because users are authorised to do only what their Job Function requires, rather than have too much authorisation, which is often the case. It also means that when creating or amending roles you know that the correct authorisations are being applied.
What is SU24 and why should we use it?
Various transactions require certain activity types which don’t always come as SAP standard. Take ME52N or another purchase order transaction for example: sometimes the activity 09 for display prices is missing, which can produce errors for the user population. Rather than repeatedly amending the role that they have been assigned, you can amend the transaction itself so that every time that transaction is used in the future, the activity type automatically comes through.
Within SU24, effectively what you’re doing is going into the particular transaction and looking for the missing object or value, amending it and adding in the activity 09. This should then be saved and transported into the Development client and populated through to Production. Once complete you can go through into the original role that contained this transaction, reimport the menu structure and then confirm that the activity type which was missing is now appearing in that role.
It also negates the need to use manually added objects, or object only roles. Manually added objects can cause a problem in that when a transaction is added, it still doesn’t bring through the authorisations, you would have to add them in manually – not the best way to do things and it’s not SAP best practice. SU24 allows you to set the authorisations accordingly, so they set every time you migrate it.
It is also beneficial to use SU24 for customised transactions. When an ABAP developer creates customised transactions, they don’t always pay close attention to authorisations; often when they assign a transaction to a role it comes in as strictly the transaction, without any associated authorisations. This can lead to errors when testing is performed, but again you can align the missing required authorisations via SU24 and then migrate them through. Technically speaking, it hard codes the authorisation values that you’ve set (which are mainly SAP standard authorisation objects) to that transaction and they then get pushed through to the role every time it’s used in the future.
What are the benefits of SU24?
The primary benefit this brings is not having to constantly maintain the SAP roles. For example, if you don’t maintain it for one particular transaction type, it can easily be addressed within the role itself; however, if that transaction is then added to a further role, you will again face the original problem of an authorisation failure in testing and the need to update the role in question – a very laborious, time-consuming process to repeat. If you use SU24 you can set the authorisations accordingly and they will be assigned every time that transaction is used in the future.
SU24 helps save time and money as you are not having to maintain a role every time there is an error with a particular transaction. A transaction could sit in eight different roles, requiring you to maintain each individual role with every occurrence of an error; however, an SU24 fix of that transaction means it is consistent in each role going forward.
One of the best parts of working at Winterhawk is the culture of sharing best practice & past experiences. In spite of working with SAP Security & Authorisations for over 14 years, I hadn’t been told about SU24 before – that’s definitely proof that there is always something new to learn! At Winterhawk, we recognise the importance of ongoing training and development, and the value it brings to the company as well as our clients.
