SM59 Konfiguration der RFC-Verbindungen
Versionierung
Es ist möglich für jede Regel in der ACL-Datei ein Trace-Level anzugeben, um jeden Kommunikationskanal individuell zu überwachen. Sie lässt sich ohne weitere Konfiguration mit SNC verwenden. Die Verwendung der Datei wird über den Parameter gw/acl_file gesteuert, indem er einfach auf den entsprechenden Dateinamen gesetzt wird. Verwendung von externen Programmen Wenn ein externes Programm mit Ihrem SAP System kommunizieren will, muss es sich zunächst am Gateway registrieren. Welchen Programmen dies genehmigt wird, wird über die ACL-Datei reginfo gesteuert. Hier werden also Regeln definiert, die bestimmte Programme erlauben oder aber verbieten. Die Syntax der Datei lässt es dabei zu, nicht nur den Namen des Programms, sondern auch den Host auf dem das Programm läuft und Hosts die das Programm verwenden und beenden können zu definieren. Zur Verwendung dieser Datei muss der Parameter gw/reg_info gesetzt sein. Außerdem gibt es die ACL-Datei secinfo, mit der es möglich ist zu konfigurieren, welche User ein externes Programm starten können. Hier werden also Regeln definiert, die bestimmten Usernamen aus dem SAP System erlauben bestimmte externe Programme zu verwenden. Zusätzlich können auch hier die Hosts definiert werden auf denen diese Programme ausgeführt werden. So ist es zum Beispiel möglich einem User zu erlauben das Programm "BSP" auf dem Host "XYZ" auszuführen, aber nicht auf dem Host "ABC". Diese Datei wird über den Parameter gw/sec_info gesteuert. Verwendung des Gateways als Proxy Da das Gateway Ihres SAP Systems außerdem als Proxy-Server dienen kann, sollte zusätzlich die ACLDatei prxyinfo über den Parameter gw/prxy_info aktiviert werden. Nehmen wir an, sie haben 3 SAP Systeme in Ihrem Netzwerk: SRC, TRG und PRX. Wenn SRC nicht direkt mit TRG kommunizieren kann, aber beide mit PRX wäre es möglich das Gateway des Systems PRX als Proxy-Server zu verwenden, also darüber zu kommunizieren. Damit dies nicht jedem erlaubt ist, sollte diese Eigenschaft also dringend eingeschränkt werden. Wie schon bei den anderen ACL-Dateien werden hier Regeln definiert, welche Hosts über das Gateway mit welchen Hosts kommunizieren können. Die Syntax der verschiedenen ACL-Dateien kann je nach Release-Stand abweichen. Es ist deshalb ratsam sie vor der Aktivierung der ACL-Dateien in der entsprechenden SAP Dokumentation nachzulesen. Weitere Unterstützung bei der Verwendung von ACL-Dateien finden Sie auch im SAP Community Wiki.
Die Zeit für die Kommunikation zwischen den Präsentations- und Applikationsservern (Netzwerkübertragung und Aufbau des Bildes am Präsentationsserver) ist in der GUI-Zeit bzw. in der Frontend-Netzwerkzeit enthalten. Eine Erläuterung der Roll-Wartezeit, der GUI-Zeit und der Frontend-Netzwerkzeit finden Sie in Kapitel 7, »Lastverteilung, Remote Function Calls und SAP GUI«, und Kapitel 8, »Internetanbindung und SAP Fiori«.
Applikationsfehler
Wie sollten Sie bei der Analyse komplexerer Programme vorgehen? Wir empfehlen Ihnen, zunächst eine Analyse des gesamten Programms mit Aggregierung pro Aufrufstelle und ohne Analyse von Operationen auf interne Tabellen durchzuführen (Einstellungen der Default-Variante). Das Ziel dieser Analyse ist, die Modularisierungseinheiten mit der höchsten Laufzeit zu ermitteln. Sortieren Sie daher, nachdem Sie die erste Analyse erstellt haben, die Hitliste nach den Nettozeiten, und identifizieren Sie Modularisierungseinheiten oder Anweisungen mit hoher Laufzeit. Wenn Sie aus dieser ersten Analyse nicht bereits Empfehlungen für die Programmoptimierung ableiten können, erstellen Sie in einem zweiten Schritt eine detailliertere Analyse dieser Modularisierungseinheiten, indem Sie eine Variante anlegen, die die Analyse auf diese beschränkt. Aktivieren Sie gleichzeitig den Trace für Operationen auf interne Tabellen, und aktivieren Sie ebenfalls die Aggregierung pro Aufrufstelle.
Grundlagen des Sizings sind detaillierte Erfahrungswerte über den Ressourcenbedarf von Benutzern und Transaktionen. Diese Erfahrungswerte veralten schnell angesichts neuer Applikations- und Rechnergenerationen, daher fokussieren wir uns in diesem Kapitel auf die Prozesse und Werkzeuge. Bei einem Sizing-Projekt sind mehrere Parteien im Boot: Das Kundenprojekt stellt das Mengengerüst, sprich die Anforderungen an konkurrierende Benutzer, Durchsatz bestimmter Transaktionen und erwartetes Datenvolumen, zusammen. Die Experten des Hardwarepartners erstellen ein Hardwareangebot – wenn nötig, unter Rückgriff auf Experten der SAP. Schließlich benötigen Sie als Projektleiter oder -mitarbeiter das Wissen über den prinzipiellen Sizing-Prozess, um unterschiedliche Sizing-Angebote und Aussagen kompetent vergleichen und bewerten zu können, die Möglichkeiten, Risiken und Grenzen einer Sizing-Aussage zu verstehen und schließlich eine fundierte Entscheidung zwischen den Hardwareangeboten zu treffen.
Mit "Shortcut for SAP Systems" steht ein Tool zur Verfügung, das einige Aufgaben im Bereich der SAP Basis erheblich erleichtert.
Einige nützliche Tipps aus der Praxis zum Thema SAP Basis finden Sie auch auf der Seite www.sap-corner.de.
Sind zu dem Zeitpunkt, zu dem der Auftrag den Dispatcher erreicht, alle SAP-Workprozesse des benötigten Typs belegt, wird der Auftrag an die Dispatcher-Queue übergeben.
Diese Subsysteme können wie eigene Systeme betriebswirtschaftlich voneinander unabhängig und isoliert genutzt werden.