SM21 Systemprotokoll
Job-Verwaltung
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).
Der Technical Lead fungiert als Arbeitspaketleiter bzw. Teilprojektleiter innerhalb der SAP-Basis, wenn das Projekt im Fokus der SAP-Basis steht. Der Technical Lead gewinnt zukünftig mehr an Bedeutung, da die SAP-Basis als Technologieberater agiert und zukünftig mehr Projekte und Projekttätigkeit erwartet wird. Diese Rolle muss immer öfter ausgefüllt werden. Auf Grund der gestiegenen Anforderungen müssen diese Rolle und die damit verbundenen Tätigkeiten durch Schulungen und Weiterbildungsmaßnahmen professionalisiert werden.
Technische Änderungen
Wenn Sie einen Puffer optimieren wollen, müssen Sie verstehen, wie er sich gegenüber Änderungen und Verdrängung verhält. Wenn Daten, die gepuffert werden, geändert werden, muss der Puffer davon in Kenntnis gesetzt werden und die gepufferten Daten invalidieren. Werden die Daten gleichzeitig von einem zweiten Prozess verwendet, gibt es unterschiedliche Strategien, wie der Puffer darauf reagiert: Der Puffer kann eine Lesekonsistenz gewährleisten, d. h., solange sich der Prozess in einer Transaktion befindet, kann er noch auf die Daten vor der Änderung zugreifen, um ein konsistentes Bild der Daten zu bekommen. Alternativ gibt es auch Puffer, die diese Lesekonsistenz nicht gewährleisten, d. h., das Programm muss damit rechnen, dass sich Daten bei mehrfachem Lesen in einer Transaktion ändern. Sofern mehrere Instanzen des Puffers existieren, müssen Sie sich anschauen, wie die Synchronisation zwischen den Puffern abläuft, wenn Daten geändert werden.
Site Reliability Engineering(SRE) ist in der Google-Welt das Äquivalent zur SAP Basis. Ben Treynor, der seit 2003 für Google tätig ist und als Pate von SRE gilt, beschreibt SRE als das „was passiert, wenn man einem Software Engineer Operations-Aufgaben überlasst“.
Etliche Aufgaben der SAP Basis können mit "Shortcut for SAP Systems" einfacher und schneller erledigt werden.
Diese greifen Daten im Arbeitsspeicher ab.
Wenn der Benutzer keine Berechtigung zum Ausführen der Transaktion SPAM hat oder die aktuelle Queue noch nicht bestätigt wurde, stoppt die Transaktion SPAM mit einer entsprechenden Meldung.