Database management, database export and database import
SAP Basis Administration
The SAP Patch Manager offers two scenarios for inserting support packages or queues: Test Scenario Use the test scenario to determine whether conflicts or problems occur (e.g., unreleased repairs) or whether a modification match is necessary before the actual insertion. This scenario allows you to estimate and minimise the time and effort required to load support packages. In this scenario, no data is imported into the system, and you can continue to play in the event of an error without the error being corrected. You must select the test scenario explicitly. Note that once the test scenario has passed, the queue is empty and needs to be redefined. You must also explicitly choose the default scenario.
If the user assignment of several transactions is to be verified, where it is not clear whether all transactions have been maintained in the menu of roles, the use of the transaction SE16N is always appropriate. Here you can also see the transactions that were assigned to a role only by the S_TCODE permission object. The result also shows which transaction is included in which role. What experience have you had in identifying specific transactions with user assignment? Do you know of any other ways to solve this problem? About your experiences and.
Detect bottlenecks
New risks in SAP HANA: In addition to the known risks, there are also new risks from the use of SAP HANA. A very good example are frequently used web applications that represent something new in the SAP area. In contrast to an SAP ERP system, HANA systems consist mainly of web applications, which were considered optional in the previous versions. These web applications can be found by various search engines on the Internet. This also applies to SAP Portal or Netweaver. There are URL schemes that help locate the system. This also applies to other SAP systems that use Web applications. This makes the new technology vulnerable to typical web attacks. SQL Injection, ABAP Code Injection, or XSS are all included. All risks known for a normal SAP system also apply to a SAP-HANA system. The data is stored unencrypted in RAM. Only then does the system gain this speed advantage. This results in risks such as a read-out by memory scraping malware. These pick up data in memory. Encryption costs performance, so it is not used by default. Especially during a migration HANA runs in a parallel system, therefore at least one new system comes to your landscape. Also note: HANA has its own tools and settings that need to be known and configured. The bottom line is that the system simply needs more attention when operating. Many settings often result in more errors. Three - points - HANA Security Plan 1) Roles and permissions In a previous SAP system, roles and permissions are certainly one of the main pillars of a secure system. Roles and permissions work differently in a HANA system. There are two types of users: 1) Default (limited): With this type of user, there are different access methods to the database. For example, the JDBC or HTTP technologies are used to give two examples.
It is of great importance to keep the knowledge of SAP Basis experts in the company transparent. One possibility is of course to "look over the shoulder" or to ask the expert directly. However, this is very time-consuming and puts a strain on the expert himself.
"Shortcut for SAP Systems" makes it easier and quicker to complete a number of SAP basis tasks.
However, this role will be much more coordinated in the future.
The world is not going digital, but it is already.