Creation of reports
ST01 System trace
The presentation layer is based on the software components, collectively called "SAP GUI". This includes several possible implementation variants: for example, SAP GUI for HTML (Web GUI) and Web Dynpro for ABAP (WDA). Since the respective GUI depends entirely on the concrete application, the presentation layer looks very different in practice.
A BW system often plays a very central role in larger companies. Here the data from the various connected source systems are analysed and reported centrally. A previous customer of mine had a BW system, to which a total of over 20 other SAPP production systems were connected. With such a large and mostly living system landscape, it is normal that individual systems are dismantled from time to time. However, especially with large SAP landscapes, there are strict regulations regarding the permissions of technical RFC users. For this reason, the simple "right-click —> delete" of a source system in RSA1 will often not lead to the target, but rather to a failed permission check. With this blog post, I'll show you a workaround on how to clean a source system from a BW system using the RSAR_LOGICAL_SYSTEM_DELETE and RSAP_BIW_DISCONNECT function blocks.
STMS_QA Approval or rejection of requests
I recommend that you schedule the background job PFCG_TIME_DEPENDENCY with the report RHAUTUPD_NEW. Scheduling the RHAUTUPD_NEW report with two variants has proven to be a best practice: Once a day before users log on for the first time (e.g. midnight or very early in the morning). This way the users are synchronized once a day. Once a month (or even once a week) with the option "Perform cleanup", so that obsolete profiles and user mappings are regularly cleaned up. Also handy: If the naming conventions of your roles allow it, you can also align the report according to different time zones. For example, I have a customer who runs the user synchronization for his users in the USA and Asia at different times, so that the daily business of the respective users is not disturbed.
SAP HANA base administrators can master the database in a way that wasn't possible back then. The SAP database is much more self-healing. Errors do less damage, are easier to detect and fix, and are less likely to impact system performance and availability before they are fixed. Monitoring tools can automatically scan the application logs, identify potential errors, and even suggest fixes, making it much easier to get to the root of the problem.
Tools such as "Shortcut for SAP Systems" complement missing functions in the SAP basis area.
As usual, it must be assigned to a package and a workbench order to become available.
This possibility is particularly advantageous when it is a new topic and there is not yet a lot of know-how in the company.