Bereitschaft zur Weiterbildung
Systemänderbarkeit und Mandanteneinstellungen
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.
Administratoren müssen häufig einen Teil oder die gesamte Datenbank replizieren, zB um ein System-Backup zu erstellen oder ein Upgrade zu testen, bevor es in die Produktion übernommen wird. In der Vergangenheit war dies bei den meisten Datenbanken überraschend schwierig zu bewerkstelligen. Mit HANA funktioniert die Replikation sofort und bietet umfangreichere Funktionen und eine bessere Kontrolle als frühere Datenbanken.
OData Services
Die erste Tuningmaßnahme beim Applikationstuning ist der effiziente Einsatz von SAP-Standardfunktionen. In der Regel gibt es viele betriebswirtschaftlich äquivalente Möglichkeiten, Geschäftsprozesse in der SAP-Komponente abzubilden. Unter diesen Möglichkeiten, die sich nur in der technischen Implementierung unterscheiden, gibt es mehr oder weniger performante Lösungen, die sich für den Benutzer letztlich in einer hohen oder einer niedrigen Antwortzeit auswirken. Hier hat man also bereits beim Customizing der SAP-Komponente Einfluss auf die spätere Performance.
Dieser Punkt klingt zuerst vielleicht ein wenig banal. Wer testet, dokumentiert das doch sicherlich? Die Erfahrung zeigt: Ja, aber oftmals lückenhaft. Bei erfolglosen Tests, bei denen im Anschluss Nachoder Zusatzentwicklungen anstehen und die Fehlerursache auf den ersten Blick nicht direkt ersichtlich ist, zahlt sich eine gute Ergebnisdokumentation oftmals aus. Dies spart Entwicklern Zeit in der Kommunikation und Aufwand durch eine erneute Nachstellung des Szenarios. An dieser Stelle bietet der SAP Solution Manager umfangreiche Möglichkeiten, Templates und Ergebnisdokumente zentral und in den einzelnen Testplänen zu verwalten. Ausschließlich automatisiert Testen Das automatisierte Testen bietet viele Vorteile, sei es eine höhere Softwarequalität durch umfassendere Testabdeckung oder Wiederverwendbarkeit von Testfällen. Jedoch ist es nicht immer sinnvoll, ausschließlich auf Automatisierte Testskripte zurückzugreifen. Eine weniger gute Wahl stellt die Testautomatisierung bei sich häufig änderder Software bzw. Prozessen dar, da hierbei der Wartungsaufwand enorm hoch sein kann. An dieser Stelle ist es oftmals effektiver, manuelle Testdurchläufe auszuführen, anstatt viel Zeit in die mehrmalige Anpassung von Testskripten zu investieren. Schlechte Testvorbereitung Die relevanten Prozesse wurden definiert, die Testpläne angelegt und der Testzeitraum hat begonnen - also kann das Testen ja beginnen? Nicht immer. Oftmals führt mangelnde Testvorbereitung zu ungeplanten zeitlichen Zusatzaufwänden. Mal wurden die Tester nicht mit der Testumgebung vertraut gemacht oder keiner hat daran gedacht, sich um einen ausreichenden und aktuellen Testdatenbestand (Stammdaten, Bewegungsdaten) zu kümmern. Stellen Sie sicher, dass Sie wirklich an alles Nötige gedacht haben! (fehlende Testdaten, nicht repräsentative Testumgebung, instabil).
Basisadministratoren steht mit "Shortcut for SAP Systems" eine PC-Anwendung zur Verfügung, die etliche Tätigkeiten in der SAP Basis vereinfacht bzw. ermöglicht.
Diese Präsentationsschicht tauscht Daten mit der Applikationsschicht aus.
Einige nützliche Tipps aus der Praxis zum Thema SAP Basis finden Sie auch auf der Seite www.sap-corner.de.
Fällt ein Applikationsserver aus oder koppeln Sie einen Applikationsserver temporär ab, muss die Benutzerverteilung neu eingestellt werden.