Verbindungsaufbau
Kopplungsarten
Eine zweite Besonderheit tritt auf, wenn der Sender seine Verbindung zum Empfänger nicht schließt. Wir beschreiben diesen Fall anhand eines Beispiels: Nehmen wir an, dass ein Sender einen RFC in einem Empfängersystem (einem SAP-System) ausführt und nach der Ausführung die Verbindung aus Performancegründen nicht wieder schließt. Dieses Verfahren wird oft angewandt, wenn viele RFCs hintereinander ausgeführt werden, denn jeder Verbindungsaufbau ist mit einem Performancenachteil verbunden. Nehmen wir in unserem Beispiel außerdem an, dass jeder RFC sehr schnell ist, d. h., dass jede Ausführung z. B. 20 ms benötigt. Wie verhält sich das Empfängersystem in diesem Fall?
Einer Anmeldegruppe können mehrere Applikationsserver zugeordnet werden. Fällt ein Server aus, kann ein anderer die ankommenden RFCs verarbeiten (Aspekt der Hochverfügbarkeit).
SAP-Basis bezieht sich auf die Verwaltung des SAP-Systems, die Aktivitäten wie Installation und Konfiguration, Lastausgleich und Leistung von SAP-Anwendungen, die auf dem Java-Stack und SAP ABAP laufen, umfasst. Dazu gehört auch die Wartung verschiedener Dienste in Bezug auf Datenbank, Betriebssystem, Anwendungs- und Webserver in der SAP-Systemlandschaft sowie das Stoppen und Starten des Systems. Hier finden Sie einige nützliche Informationen zu dem Thema SAP Basis: www.sap-corner.de.
Clients und Server
RFCs werden zu folgenden Zwecken verwendet: zur Kommunikation zwischen unterschiedlichen Systemen, etwa zwischen zwei SAP-Systemen oder zwischen einem SAP-System und einem externen System. Innerhalb eines SAP-Systems: – zur Kommunikation zwischen den Applikationsinstanzen oder zwischen der Applikationsebene und der Präsentationsebene (GUI-Kommunikation) – zur Parallelisierung von Prozessen: Da ein Programm nacheinander mehrere RFCs asynchron starten kann, ohne deren Verarbeitungsende abwarten zu müssen, werden RFCs dazu verwendet, Prozesse zu parallelisieren und Last dynamisch auf die unterschiedlichen Rechner innerhalb eines SAP-Systems zu verteilen.
Nach der Ausführung des ersten RFCs wartet der RFC-Server-Workprozess 500 ms. Ruft der Sender vor Ablauf dieser Wartezeit das Empfängersystem erneut, wird der RFC im selben Workprozess ausgeführt. Das Roll-in und Roll-out des Benutzerkontextes werden somit vermieden. Wird innerhalb der 500 ms kein weiterer RFC ausgeführt, wird der Benutzerkontext aus dem Workprozess herausgerollt und steht anderen Benutzern für Anfragen zur Verfügung. Der Benutzerkontext und die CPICVerbindung bleiben dabei weiterhin erhalten, sie werden nur aus dem Workprozess herausgerollt. Beim Herausrollen wird ein Statistiksatz erstellt. Die Antwortzeit, die dieser Statistiksatz anzeigt, ist die Zeit, die der Workprozess belegt war. Nehmen wir ein Beispiel, in dem vier RFCs mit einer Antwortzeit von je 20 ms schnell hintereinander ausgeführt werden. Anschließend wartet der Workprozess noch 500 ms. Die Antwortzeit für den RFC-Aufruf wird damit mit ca. 600 ms angegeben. Die Antwortzeiten der vier RFCs finden Sie in den Details des Statistiksatzes.
Verwenden Sie "Shortcut for SAP Systems", um viele Aufgaben in der SAP Basis einfacher und schneller zu erledigen.
Auch bei ändernden OData-Services sollte die lokale Verbuchung verwendet werden.
So viele Informationen... wie kann man die aufheben, so dass man sie bei Bedarf wiederfindet? Scribble Papers ist ein "Zettelkasten", mit dem das sehr einfach möglich ist.
Diese Festlegung wurde getroffen, da die Antwortzeit im Dialog-Task natürlich die Zeit widerspiegeln soll, die ein Benutzer vor seinem Bildschirm wartet.