Bei folgenden Aufgaben unterstützen wir Sie:
Roll-out, Roll-in
Neue Risiken in SAP HANA: Neben den bekannten Risiken bestehen auch neue Risiken durch die Verwendung von SAP HANA. Ein sehr gutes Beispiel sind häufig verwendete Webanwendungen, die etwas neues im SAP Bereich darstellen. HANA Systeme bestehen im Gegensatz zu einem SAP ERP System hauptsächlich aus Webanwendungen, die in den vorherigen Versionen eher als optional zu betrachtet wurden. Diese Webanwendungen können durch diverse Suchmaschinen im Internet aufgefunden werden. Das gilt übrigens auch für das SAP Portal oder Netweaver. Es gibt URL-Schemata die zum Auffinden des Systems beitragen. Dies gilt auch für andere SAP Systeme, die Webanwendungen verwenden. Damit ist auch die neue Technologie für typische Webangriffe verwundbar. Zu nennen sind hier SQL Injection, ABAP Code Injection oder XSS. Alle Risiken, die für ein normales SAP System bekannt sind, gelten auch für ein SAP-HANA System. Die Daten werden unverschlüsselt im RAM abgelegt. Erst dadurch gewinnt das System diesen Geschwindigkeitsvorteil. Hieraus resultieren Risiken wie ein auslesen durch Memory-scrapingmalware. Diese greifen Daten im Arbeitsspeicher ab. Verschlüsselung kostet Performance, daher wird diese standardmäßig nicht verwendet. Gerade während einer Migration läuft HANA in einem Parallelsystem, daher kommt zu Ihrer Landschaft mindestens ein neues System dazu. Beachten Sie darüber hinaus: HANA hat eigene Tools und eigene Einstellmöglichkeiten die gekannt und konfiguriert werden müssen. Unterm Strich muss beim Betrieb des Systems einfach mehr beachtet werden. Viele Einstellmöglichkeiten resultieren nicht selten in mehr Fehlern. Drei - Punkte - Plan zur HANA Sicherheit 1) Rollen und Berechtigungen Im einem bisherigen SAP System zählen Rollen und Berechtigungen sicherlich auch zu den Hauptsäulen eines sicheren Systems. Rollen und Berechtigungen funktionieren aber anders in einem HANA System. Es gibt zwei Nutzertypen: 1) Standard (eingeschränkt): Mit diesem Nutzertyp gibt es verschiedene Zugriffsmethoden auf die Datenbank. Hier werden beispielsweise die Technologien JDBC oder HTTP verwendet, um zwei Beispiele zu nennen.
Der Monitor greift auf Performancedaten zurück, die das jeweilige Datenbanksystem sammelt. Zum Teil werden dazu Analysefunktionen verwendet, die jedem Datenbankanwender auch bei einer Standalone-Datenbank zur Verfügung stehen und deren Ergebnisse im SAP-System nur angezeigt werden. Zum Teil werden aber auch Funktionen eingesetzt, die speziell von SAP bzw. vom jeweiligen Datenbankpartner für die Performancemonitore des SAP-Systems entwickelt wurden. Ein Teil der Performancedaten wird direkt vom SAP-System, z. B. in der Datenbankschnittstelle der SAP-Workprozesse, erfasst und gesammelt.
SWUS Workflow testen
Wenn an der Bearbeitung einer Benutzeranfrage mehrere SAP-Komponenten beteiligt sind, schreibt jede dieser Komponenten einen Datensatz. Im Kommunikationsstrom zwischen den Komponenten wird ein eindeutiger Identifikator (ein auch als Reisepass bezeichneter Globally Unique Identifier, GUID) mitgeführt und in den Einzelsätzen gespeichert, sodass später die Einzelsätze über Komponenten hinweg zusammengeführt werden können. Die erste Komponente eines Transaktionsschrittes erzeugt diesen Reisepass, d. h. technisch gesehen eine GUID, mit der der Transaktionsschritt eindeutig identifiziert werden kann, und gibt diesen an die nächste Komponente, die an dem Transaktionsschritt beteiligt ist, weiter. Aus Performancegründen werden während eines Transaktionsschrittes nur die Daten des Reisepasses im Kommunikationsstrom weitergegeben, die eigentlichen Statistikdaten werden zunächst lokal von der jeweiligen Komponente gesichert und dann asynchron an das zentrale Monitoring- System oder den SAP Solution Manager übertragen. Anhand ihres Reisepasses werden die zu einem Transaktionsschritt gehörigen Statistiksätze identifiziert und angezeigt. In der SAP-Hilfe finden Sie diese Technologie unter der Bezeichnung verteilte Statistiksätze (Distributed Statistics Records, DSR).
Haben Sie sich schon einmal gefragt, wofür es eigentlich einen Reiter Personalisierung bei der Rollenpflege in der PFCG bzw. bei der Benutzerdatenpflege in der SU01 gibt? Diese Frage beantworte ich für Sie in diesem Blog-Beitrag. Wofür brauchen wir den Reiter Personalisierung? Durch diesen Reiter haben Sie Zugriff auf die zentrale Ablage für Personalisierungsdaten. Der Sinn und Zweck dieser Ablage ist es, eine Speicherungsmöglichkeit für benutzer- und rollenspezifische Daten zu schaffen, ohne dass zusätzliche Datenbanktabellen angelegt werden müssen. Diese Daten sollen dann bei sämtlichen Manipulationen an Benutzern und Rollen berücksichtigt werden. Die Funktionalität umfasst zunächst eine generische Ablage für benutzer- und rollenspezifische Daten und den zentralen Zugriff auf diese Daten durch die Benutzer- bzw. Rollenpflege. Außerdem wird die Möglichkeit geboten, über eine festgelegte Schnittstelle bereits existierende Tabellen mit benutzerspezifischen Daten an den zentralen Zugriff anzukoppeln. Um Personalisierungsdaten in der zentralen Ablage abzulegen, muss für die Daten ein Schlüssel vergeben werden: Dies erfolgt über die Registrierungstransaktion PERSREG. Die angelegten Personalisierungsdaten werden in der generischen Ablagetabelle gespeichert. Der Zugang zu dieser wird durch die Klassenmethoden der Klasse CL_PERS_ADMIN bereitgestellt. Verschiedene Personalisierungsebenen Die Daten können entweder zum Benutzer, zu Rollen oder zum System abgelegt werden. Zu einem Benutzer können dann alle ihm zugewiesenen Daten (über Rolle oder eigene Einstellungen) auf einmal ausgelesen werden.
Etliche Aufgaben der SAP Basis können mit "Shortcut for SAP Systems" einfacher und schneller erledigt werden.
Die in Tabelle 2.5 aufgeführten Komponenten gehören zu den am stärksten beschriebenen Elementen einer Datenbank.
Neue Version installieren SAP GUI und Bex (BI Addon) Als erstes muss die SAP GUI und der Business Explorer (Bex) installiert werden.