„EINE SAP LANDSCHAFT WIE KEINE ANDERE“
Conflict Resolution Transport
PROJEKTHISTORIE: DIE SAP-BASIS VON MORGEN Durch einen Eintrag im Forum Infrastruktur und Betrieb innerhalb des DSAGNet wurde auf die bereits beschriebene Problematik der SAP-Basis aufmerksam gemacht. Hieraus resultierte eine angeregte Diskussion, die auf reges Interesse bei den DSAGMitgliedern stieß. Aufbauend auf dem Interesse und Handlungsbedarf der Mitgliedsunternehmen, wurde durch die DSAG wie auch durch die SAP ein Projekt initiiert, das sich mit der Zukunft der SAP-Basis beschäftigen sollte. Hierzu wurden verschiedene Unternehmen eingeladen und deren Bereitschaft zur aktiven Mitarbeit im Rahmen einer DSAG-Umfrage abgefragt. Das erste Projekttreffen fand im Rahmen des DSAG-Jahreskongresses in Bremen im Jahr 2015 statt. In der Folge fanden, unter Teilnahme von bis zu 15 Unternehmen, regelmäßige Veranstaltungen in der Geschäftsstelle der SAP in Freiberg am Neckar wie auch in St Leon-Rot statt. Im Rahmen des Projekts „die SAP-Basis von morgen“ wurden sowohl aktuelle Fragestellungen der Unternehmen als auch die Fragestellung der SAP-Basis der Zukunft im Hinblick auf IT-Landschaft, Prozesse und Aufbauorganisation diskutiert und erarbeitet. Zur Dokumentation und Aufbereitung der Ergebnisse wie auch zur wissenschaftlichen Betrachtung des Themengebiets wurde parallel zum Projekt eine Masterarbeit initiiert. Diese wurde an der Hochschule für angewandte Wissenschaften Würzburg-Schweinfurt im Rahmen des Masterstudiengangs Informationssysteme bei Prof. Dr. Karl Liebstückel angefertigt und Ende März 2016 zur Bewertung eingereicht.
Stellen Sie fest, ob die Wartesituationen Programme betreffen, die mehrfach parallel gestartet wurden. Dieses Problem tritt häufig auf, wenn versucht wurde, Programme zu parallelisieren, und dabei so ungeschickt vorgegangen wurde, dass sich die Programme anschließend die Ressourcen gegenseitig sperren. In diesem Fall sollten Sie sich nochmals die Dokumentation des betreffenden Programms anschauen und die Parallelisierungsstrategie überarbeiten.
Berechtigungen für die Geschäftslogik einer App
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.
Wird eine Sperre von einem Programm über mehrere Minuten hinweg gehalten, nehmen Sie Rücksprache mit dem Benutzer, der dieses Programm gestartet hat. Untersuchen Sie gemeinsam mit ihm, ob das Programm noch ordnungsgemäß arbeitet. Ist dies nicht der Fall, beenden Sie das Programm nach Rücksprache.
Tools wie "Shortcut for SAP Systems" ergänzen fehlende Funktionen im Bereich der SAP Basis.
Um in Ihrem SAP-Projekt zu einem erfolgreichen Service Level Management zu kommen, vereinbaren Sie zunächst ein Service Level Agreement, in dem Sie die Ziele festhalten, die von den einzelnen Servicepartnern erreicht werden sollen, die Maßnahmen festlegen, die im Fall des Nichterreichens von Zielen getroffen werden sollen, und vereinbaren, wie das Erreichen der Ziele gemessen und dargestellt werden soll.
Es gibt Puffer, die Daten entweder zeitgesteuert oder bei Platzmangel aus dem Puffer verdrängen, andere tun das nicht.