Mandantenunabhängige Transaktionen
Indirekte Nutzung von SAP
Hat ein SAP-Benutzer seine Eingabe beendet, sendet sein Präsentationsserver den Auftrag an den Dispatcher des Applikationsservers. Die Antwortzeit (Mittlere Antwortzeit) läuft von dem Moment an, in dem der Auftrag des Präsentationsservers den Dispatcher im Applikationsserver erreicht hat (Punkt 1 in Abbildung 3.2). Sie endet in dem Moment, in dem der Auftrag abgearbeitet ist und die letzte Datenrückgabe an den Präsentationsserver erfolgt.
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.
High Availability ( HA/DR ) Konzepte
Mit SAP Basis liefert SAP das Fundament seiner Software aus. Auf dessen Grundlage können SAP-Anwendungen unabhängig von Betriebssystem und Datenbank verwendet werden, untereinander agieren und mit Daten angereichert werden. Aufsetzend auf einer Client/Server-Architektur, beinhaltet SAP Basis die Konfiguration, ein relationales Datenbank-Management-System sowie eine grafische Benutzeroberfläche.
Mittlerweile gibt es auch andere Verfahren einen Konsens zu kreieren. Aber größtenteils haben sich die folgenden 3 Möglichkeiten als Konsensus-Mechanismus bewährt: 1) Proof of Work (Arbeitsnachweis) 2) Proof of Stake (Geldnachweis) 3) Proof of Importance (Wichtigkeitsnachweis) Die Unterschiede stelle ich in einem anderen Blog-Beitrag dar. Wie entstehen Blöcke in einer Blockchain? Jeder Block baut unwiderruflich auf einen älteren Block auf. Würde man den Block entfernen, müsste man alle Blöcke darüber ebenfalls entfernen, was die komplette Kette an Blöcken zerstören würde. Denn jeder neue Block enthält auch Informationen von seinem Vorgängerblock. Dies ist sehr wichtig für das Verständnis der Unveränderlichkeit einer Blockchain. Würde man einen Block nachträglich manipulieren, müsste man auch alle darauffolgenden Blöcke anpassen. Der Aufwand wäre so unendlich groß und teuer das sich so eine Manipulation praktisch nicht umsetzen lässt. Man kann sich das wie folgt vorstellen. Eine Blockchain entsteht aus den kryptographisch miteinander verketteten Blöcken (Puzzle) voller Transaktionen (Puzzleteile) und kann daher nicht verändert werden, ohne die gesamte Blockchain zu zerstören. Aus diesem Grund wird eine Blockchain als eine unveränderliche Transaktionshistorie angesehen, auf die sich eine dezentralisierte Community geeinigt hat. Eine Blockchain ist so programmiert, dass jeder Miner am längsten Teil der Blockchain mitarbeitet, da dies offensichtlich die Kette ist, in die die meiste Arbeit investiert wurde.
Einige fehlende SAP Basis Funktionen im Standard werden durch die PC-Anwendung "Shortcut for SAP Systems" nachgeliefert.
Im Workload-Monitor (siehe unten) können Sie darüber hinaus feststellen, wie viele Dialogschritte auf den einzelnen Servern durchgeführt wurden.
Das Transaktionsprofil enthält eine Liste aller Transaktionen (bzw. Programme), die in der ausgewählten Periode gestartet wurden.