Operation of your ERP landscape on SAP on HANA
SAP Development
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.
The Queue determines which support packages are inserted into your system in which order by the SAP Patch Manager. If the queue is not yet fully defined, you must define the queue from the available support packages. If the Queue is already fully defined, it is only displayed; they no longer have the ability to change the selection. However, you can delete the queue completely with Queue [page 37]. Note that your system is inconsistent when you delete the queue after objects have been imported (for example, after an error in the DDIC_IMPORT step and following). The deletion in these SPAM steps should only be used for troubleshooting and you should repeat the insertion of the support packages as soon as possible. The SPAM transaction ensures that only support packages that match your system are displayed in the queue. Support packages intended for another release or an uninstalled add-on will not appear in the queue, even if they are loaded into your SAP system. For more information, see Rules for the Queue [page 19]. You must define the queue before you insert support packages. Prerequisites You have loaded the appropriate support packages with the SPAM into your SAP system [page 15]. Procedure To define a queue, select View/Define SPAM on the entry screen of the transaction. The Select Component dialogue box appears. You will see the list of installed software components (e.g. SAP_BASIS, SAP_HR, SAP_BW, Add-On). Select the desired component. You see the available queue. This queue contains the support packages available for the selected component in your system, and any required Conflict Resolution Transports (CRT), as well as associated Add-On Support Packages. You can: If the queue you see matches your wishes, you can accept the queue with Queue confirm and leave this selection window.
Decommissioning/uninstallation of SAP systems and their databases
To add additional permissions for defined groups in the launchpad to PFCG roles, follow the steps described above. This time, you only select a "SAP Fiori tile group" instead of a "SAP Fiori tile catalogue". There are very few differences between permissions. Fiori Eligibility for OData Services The launch authorisation for the OData service stored in the backend from a Fiori app is queried on both the front-end and back-end servers when the application is launched. Therefore, this permission must be added to the appropriate role on both servers. The typical sequence of clicking on a Fiori app in the launchpad triggers the following steps: 1) When selecting the tile, the app Fiori implementation is called 2) The app retrieves dynamic data from the HTTP endpoint of the OData service on the frontend server from 3) An RFC call to the gateway activation of the backend system is followed, retrieving the relevant business logic 4) Now the Fiori permission for the corresponding OData service is queried on the backend 5) If this was successful the appropriate business logic permissions are queried in the OData service. To add the Fiori permission to run a OData service for an app to a role, please perform the following steps: In the PFCG, open the appropriate role in Change mode, perform steps on the following screenshot: 1) Select Menu tab 2) Arrow next to the "Transaction" button click 3) Select Permissions proposal.
Use "Shortcut for SAP Systems" to accomplish many tasks in the SAP basis more easily and quickly.
SAP Basis is the foundation of any SAP system. You can find a lot of useful information about it on this page: "www.sap-corner.de".
A possible cause of error is that the appropriate OCS file was not found or the data file could not be opened for writing.