In SAP, there are a variety of transaction types that allow users to perform business processes. However, each transaction type has its own risks in terms of data protection and system security.
On a technical level, SAP distinguishes between Professional User Transactions and Easy Web Transactions. However, these two transaction types do not say anything about what the transactions can do. They merely represent the access path. Professional User Transactions are the standard transactions. They are executed directly in the SAP system, i.e. called up via the “normal” SAP GUI. An Easy Web Transaction, on the other hand, can only be executed in the SAP GUI for HTML, i.e. in the web browser. To do this, the transactions must be linked to a so-called ITS service.
Within these two transaction types, however, you can also differentiate transactions according to content and usage. And this is where it gets interesting from an authorization point of view, because background transactions usually require a different level of protection than standard dialog transactions, for example.
Dialog transactions in SAP
Most of the transactions we authorize on a daily basis are dialog transactions. These are transactions that bring the user into a dialog with the system. They require user input and are interactive, meaning they allow the user to respond to screens displayed by the system and provide input.
Dialog transactions are very flexible. They can also be used to map complex business processes. At the same time, this very flexibility can become a risk. From an authorization point of view, it is important firstly to check exactly who needs the authorizations and to structure roles in a correspondingly small way in order to avoid overauthorizations. At the same time, dialog authorizations can be restricted by defining individual authorization objects. For example, you can control whether users have only limited access to data or only read access, but not editing access. Although these restrictions via authorization objects and a clean role concept are not specific to dialog transactions, they are particularly important here in order to avoid intentional or accidental security breaches caused by incorrect user entries.
Batch input transactions in SAP
In this type of transaction, a set of data is taken and automatically entered into the system without bringing the user into a dialog with the system. Batch input transactions can be useful for quickly loading bulk data into the system, but they require that the data be put into the correct format beforehand. An example of a batch input transaction is SM35 for running batch input sessions.
Batch input transactions allow users to automatically import large amounts of data into the system. This always involves a significantly increased level of security. Batch input transactions should therefore be authorized very sparingly.
Background transactions in SAP
This type of transaction is executed in the background without the user being informed. Business processes can thus be executed automatically in the background without a user having to actively interact with the system. This theoretically reduces the security risk.
At the same time, background transactions are usually used to directly influence the system. For example, they can be used to perform periodic or scheduled activities such as data backup or batch processing.
Background transactions are very often assigned to technical users, which means they are not dialog users. But for the maintenance of background processes, dialog users must also have permissions for background transactions. Here, good security guidelines are particularly important to ensure that only users with appropriate tasks (e.g. Basis employees) are authorized.
Report transactions in SAP
Report transactions allow users to create and run reports on business processes. An example of this is transaction SE38 for creating ABAP reports. Since this involves reports that may contain sensitive data, the risk of an unintended or malicious action is higher.
Therefore, as with dialog transactions, the same applies here: A good (and well-implemented) role concept and, if necessary, the restriction to individual actions and only certain data minimize the risk on the authorization side.
Parameter transactions in SAP
Parameter transactions are basically restricted dialog transactions. They require less user input because they are already started with predefined parameters that are passed to the system. Parameter transactions normally do not require any input from the user. They perform a specific action – based on the parameters passed – and directly display the result. Parameter transactions are therefore usually faster than dialog transactions because they do not require user input time.
For more information, see the article on creating and authorizing parameter transactions.
Z-transactions
Strictly speaking, Z-transactions are not a separate transaction type. We use them to refer to customer-specific transactions. When the SAP standard reaches its limits, developers can build their own transactions that exactly meet the customer’s requirements. These can be dialog, parameter, background, batch input or report transactions. On the authorization side, they are protected in exactly the same way as SAP standard transactions.
Variant transaction
Variant transactions are very similar to parameter transactions. Here, too, the transaction is filled with predefined values by the system when it is called.
However, the differences to the parameter transaction are in the details:
- Parameter transactions always refer to the initial screen only. Variant transactions can preallocate several screens with variants. At the same time, certain screens can be suppressed in a variant transaction so that they are never displayed. In a parameter transaction, only the initial screen can be suppressed, and only when the transaction is called directly.
- Variant transactions can be assigned different variants depending on the client.
If variant transactions are well designed and implemented, they offer a much lower security risk than, for example, open dialog transactions. However, they are used less frequently because creating and maintaining them is time-consuming.