SM58 Transaktionaler RFC
SAINT Add-On Installation Tool
In vielen Fällen liegen die Daten, aufgrund derer im SAP-System Dokumente erstellt werden sollen, bereits in elektronischer Form vor, z. B. als Datei. Es wäre extrem unsinnig, diese Daten durch Dialogbenutzer manuell eingeben zu lassen. Vielmehr bietet das SAP-System die Möglichkeit, diese Daten über im Hintergrund laufende Schnittstellenprogramme in das System zu übertragen. Diese Art der Verarbeitung wird auch als Batch-Input bezeichnet und ist eine Sonderform der Hintergrundverarbeitung. Sie wird häufig als Kommunikationsschnittstelle zwischen dem SAP-System und externen DV-Systemen verwendet: Stellen wir uns etwa ein Projekt vor, in dem Kundenaufträge in dezentralen Rechnern mit einer lokalen Software erfasst und gespeichert werden. Nach Bedarf senden diese Rechner ihre Aufträge in einer Datei an eine Zentrale, wo sie per Batch-Input in das SAP-System übertragen werden.
Hybride Clouds sind längst die Norm, auch wenn diese Entwicklung eher zufällig zustande gekommen ist. Die meisten Unternehmen haben sich für verschiedene Cloud-Software-Angebote entschieden und diese entsprechend integriert, sei es Workday für HCM, SalesForce für CRM, Marketo für die Marketingautomatisierung, Coupa für SRM oder Vendavo für die Preisgestaltung. Viele haben sich mit SuccessFactors, Cloud for Customer, Marketing Cloud, Ariba und CPQ auch für die SAP-Varianten dieser Lösungen entschieden.
Analyse und Behebung von technischen Problemen im SAP Basis Umfeld unter den Plattformen ORACLE und Windows
Eine SAP-Transaktion erstreckt sich in der Regel über mehrere Transaktionsschritte (Bildwechsel). Während dieser Schritte werden Daten wie Variablen, interne Tabellen und Bildschirmlisten aufgebaut und im Hauptspeicher des Applikationsservers gehalten. Diese Daten bezeichnet man als Benutzerkontext. In der Regel werden die Schritte einer Transaktion von unterschiedlichen Dialog-Workprozessen ausgeführt, d. h., der erste Transaktionsschritt wird vielleicht vom Workprozess Nr. 3 ausgeführt, der zweite Schritt vom Workprozess Nr. 4 etc. Zu Beginn eines Transaktionsschrittes muss daher der Benutzerkontext dem entsprechenden Workprozess zugänglich gemacht werden. Dieser Vorgang heißt Roll-in. Die technischen Vorgänge beim Roll-in (z. B. das Kopieren von Daten in den lokalen Speicher des Workprozesses) werden in Kapitel 6, »Speicherkonfiguration«, im Detail dargestellt. Analog zum Roll-in zu Beginn eines Transaktionsschrittes wird zum Ende eines Transaktionsschrittes ein Roll-out, also die Sicherung der aktuellen Benutzerdaten, durchgeführt. Die Länge des Roll-ins wird als Roll-in-Zeit, die Länge des Roll-outs als Roll-out-Zeit bezeichnet. Bitte beachten Sie, dass der Roll-out nicht zur Antwortzeit eines Transaktionsschrittes beiträgt. Beim Roll-out, d. h. beim Kopieren des Benutzerkontextes aus dem lokalen Speicher des Workprozesses in den Roll-Speicher, sind die Daten des Benutzers bereits vorher an den Präsentationsserver übertragen worden.
Welche Argumente sprechen nun dafür, mehr oder weniger Workprozesse zu konfigurieren? Das Argument für eine hohe Workprozess-Anzahl ist klar: Wenn Benutzer auf Workprozesse in der Queue des SAP-Dispatchers warten müssen, ist die Versuchung groß, ihnen mehr Workprozesse zur Verfügung zu stellen und dann zu hoffen, dass mehr Benutzer gleichzeitig arbeiten können. Dies ist dann der Fall, wenn Workprozesse durch Wartesituationen blockiert werden, die keine CPU-Leistung kosten, z. B. wenn Workprozesse in den PRIV-Modus gehen oder häufig durch Sperrsituationen auf der Datenbank blockiert sind. Auf der anderen Seite ist das »Aufdrehen« der Anzahl der Workprozesse fragwürdig, denn offensichtlich ist es langfristig sinnvoller, das tatsächliche Performanceproblem zu lösen, nämlich die Wartesituationen zu beseitigen. Das Hinzufügen von Workprozessen kann also nur Symptome abmildern, in der Regel das Performanceproblem jedoch nicht wirklich lösen.
Einige fehlende SAP Basis Funktionen im Standard werden durch die PC-Anwendung "Shortcut for SAP Systems" nachgeliefert.
Dieses Verhalten ergibt sich aus der Tatsache, dass SAP HANA Anfragen massiv parallelisiert und dabei kurzzeitig alle Prozessoren vollständig belegt.
Auf www.sap-corner.de finden Sie ebenfalls viele nützliche Informationen zum Thema SAP Basis.
Technisch gesehen besteht die SAP Basis aus drei Schichten: der Datenbankschicht, der Applikationsschicht sowie der Präsentationsschicht.