Vorteile von SAP Basis Support
Geringe Workprozess-Anzahl
Im Rahmen eines zu schaffenden Innovations-Teams oder Testlaboratoriums ist es notwendig, Ideen außerhalb der SAP-Basis zuzulassen bzw. bewusst andere Ideenquellen innerhalb und außerhalb des Unternehmens in Anspruch zu nehmen. Dies können bspw Geschäftsbereiche, externe Dienstleister, Hochschulen oder auch Vortragsreihen zu bestimmten Themengebieten sein.
Ein wichtiger Bereich der SAP Security ist die Analyse der kundeneigenen SAP-Programme, die klassisch in der proprietären SAP-Sprache ABAP geschrieben werden. Auch hier können, wie in allen Programmiersprachen, Sicherheitslücken programmiert werden – sei es nun bewusst oder unbewusst. Die Muster der Sicherheitslücken im ABAP-Code unterscheiden sich dabei allerdings von denen in Java-Stacks oder Windows-Programmen. Das Ziel bei diesen herkömmlichen Programmen ist es meistens, durch gezielte Falscheingaben das Programm entweder zum Absturz zu bringen (Buffer Overflow) oder künstlich eigenen Code zur Ausführung zu bringen (Code Injection). Beides ist in ABAP nicht möglich, da ein Absturz eines Prozesses nichts anderes bewirkt als das Erzeugen eines Eintrages in der Log-Datenbank (Dump ST22) und ein anschließendes Beenden des Reports mit Rückkehr an den Menüstartpunkt. Eine direkte Manipulation wie in anderen Hochsprachen oder Servern ist also nicht möglich. Allerdings gibt es andere Manipulationsmöglichkeiten.
SPRO Einführungsleitfaden
Die genannten Puffer bilden eine Pufferhierarchie, d. h., es werden zunächst die Puffer abgefragt, die nahe an der Anwendung liegen, bevor die Zugriffe auf den Datenpuffer der Datenbankinstanz, den Betriebssystempuffer und den Puffer des Speichersubsystems durchschlagen. Grundsätzlich gilt: Je weiter unten in der Hierarchie ein Puffer liegt, desto generischer ist sein Einsatzbereich; je höher in der Hierarchie ein Puffer liegt, desto höher muss sein Performancegewinn für die Anwendung sein. Ist das nicht der Fall, kann auf diesen Puffer verzichtet werden.
Grundlagen des Sizings sind detaillierte Erfahrungswerte über den Ressourcenbedarf von Benutzern und Transaktionen. Diese Erfahrungswerte veralten schnell angesichts neuer Applikations- und Rechnergenerationen, daher fokussieren wir uns in diesem Kapitel auf die Prozesse und Werkzeuge. Bei einem Sizing-Projekt sind mehrere Parteien im Boot: Das Kundenprojekt stellt das Mengengerüst, sprich die Anforderungen an konkurrierende Benutzer, Durchsatz bestimmter Transaktionen und erwartetes Datenvolumen, zusammen. Die Experten des Hardwarepartners erstellen ein Hardwareangebot – wenn nötig, unter Rückgriff auf Experten der SAP. Schließlich benötigen Sie als Projektleiter oder -mitarbeiter das Wissen über den prinzipiellen Sizing-Prozess, um unterschiedliche Sizing-Angebote und Aussagen kompetent vergleichen und bewerten zu können, die Möglichkeiten, Risiken und Grenzen einer Sizing-Aussage zu verstehen und schließlich eine fundierte Entscheidung zwischen den Hardwareangeboten zu treffen.
Tools wie z.B. "Shortcut for SAP Systems" sind bei der Basisadministration extrem nützlich.
Diese greifen Daten im Arbeitsspeicher ab.
Als dritte Möglichkeit sind High-End Lösungen erhältlich, die zusätzlich die Infrastruktur und Legacy mit überwachen.