Free-form recognition and document check
Operations
Always the latest version: Your system will always be up to date and you will have access to the latest versions. Patches are performed by the external SAP Basis team.
A well-cared-for emergency user concept enables the audit-proof allocation of extended permissions in combination with the assurance of daily operations in your company. This article first addresses the fundamental issues that require an emergency user approach. It then briefly explains how such a concept works in general and how we implement it. An Emergency User is normally used when tasks are temporarily taken over outside the initial field of activity. I described the different scenarios of when such a user can be used and how to deal with them in this blog post for you. Why is an emergency user approach important? There are several scenarios in which the use of an emergency user with extended rights is useful: In urgent cases, it is often necessary to be able to quickly make changes to the system that are outside the user's actual field of activity. A key user who has the necessary permissions is on vacation and needs a representation. The same user suffers short-term illness and his/her representative must take over his/her duties to ensure the operation. We recommend developing a concept for the short-term allocation of the additional permissions. This will ensure the implementation of the above scenarios. How does an emergency user approach work? An emergency user concept in SAP works fundamentally via a temporary assignment of additional rights to a specific user. After the tasks have been completed, the user is deprived of the rights. The tasks performed with the extended permissions are logged and can then be evaluated by an auditor. However, there are a few things to keep in mind: A process for granting special rights should be defined. It must be specified which users can get special rights. The time period for which users can request an emergency user should be limited.
Then contact us now!
To display custom tiles based on catalogues and groups when the launchpad starts, permissions are placed in the menu of the underlying role. This makes it possible to ensure that every user on the launchpad can only see and open their applications. Open Launchpad permissions SAP provides default roles for opening the Fiori Launchpad. This distinguishes between the Fiori permissions to start the launchpad normally and to manage the user interface.
The dataowner should be the adm of the target system, which you can change (in the Unix console) with "chown adm K12345.DEV" (respectively R12345.DEV for the data file). To change the access permissions, you can use the command "chmod 664 K12345.DEV". Attach transport jobs in the SAP system Once this has been done, you can attach the transport orders in your SAP system to the import queue. This is done by using the STMS -> Import Overview (F5) to display the import queues. Select the import queue of the target system with a double click. After that, you will receive a pop-up under "Additions"->"More orders"->"Attach", which you can use to attach the transport orders to the import queue. In the pop-up you have to name the exact transport order. The correct name for this is as follows: The first three characters are the file extension of the two files you copied into the transport directory. The last characters consist of the file name of the cofiles file. In our example transport the transport would be called "DEVK12345" (deriving from the cofiles file K12345.DEV) This should now return a positive message from SAP and the transport is attached to the import queue. Now you can import this transport into the system just like any ordinary transport order. Step-by-step Summary Copy Cofiles/data file to transport directory Normally /usr/sap/trans, if not —> AL11 -> DIR_TRANS Customise file owners and permissions chown adm chmod 664 In SAP system: STMS -> Import Overview -> Select Import Queue -> Additions -> Additional Jobs -> Attach Enter Transport Jobs ().
For administrators, a useful product - "Shortcut for SAP Systems" - is available in the SAP basis area.
Incidentally, the problem arises particularly frequently after role transports: If an authorization role is changed in the development system and then transported to the production system, the current profile is not automatically assigned to the users with the respective role.
I hope that with this I can give you some guidance so that you can avoid these mistakes.