SAP RFC Gateway Sicherheit durch secinfo und reginfo ACL Dateien
Troubleshooting und Support
Die zuvor beschriebenen Aufgaben, die in eher unregelmäßigen Abständen anfallen und auf Grund der fehlenden Routine oder des fehlenden Prozess-Know-hows eine gewisse Komplexität mit sich bringen, sollten dahin gehend geprüft werden, ob diese von einem externen Dienstleister effizienter erbracht werden können. Eine Frage, die es zu beantworten gilt, ist, ob es erforderlich ist, das notwendige Wissen im Unternehmen vorzuhalten, um ggf schneller als der externe Dienstleister reagieren zu können. Beispielsweise bei unternehmenskritischen Systemen. Auch zu beachten sind Aspekte der Sicherheit, da externe Personen Zugriff auf das System erhalten. Fortführend müssen die durch Outtasking erbrachten Leistungen regelmäßig kontrolliert und auf deren Qualität und Dokumentation hin überprüft werden. Eine vollständige Abhängigkeit vom externen Partner darf nicht entstehen.
Die Prüfungen decken Standardfehler und -probleme auf. Sie können natürlich keine Aussage darüber machen, wie gravierend die tatsächlichen Auswirkungen auf die Performance sein werden. Dazu sind die oben beschriebenen Laufzeitprüfungen notwendig. Die Verifikation dieser Prüfungen sollte dennoch Bestandteil der Qualitätskontrolle von ABAP-Programmen sein.
Skalierbarkeit der Client-Server-Infrastruktur
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.
In unserem Beispiel soll nun die Last unter Beibehaltung des Applikationsprofils vergrößert werden, d. h., weitere Benutzer sollen die Anwendungen Activity Management, Opportunity Management und Vertrieb nutzen. Nehmen wir an, dass sich in unserem Beispiel die Anzahl der Benutzer um 20 % erhöhen soll. Das Re-Sizing geht davon aus, dass sich dies proportional in der Lasterhöhung niederschlägt. In der Summe können wir also von einer Hauptspeicherauslastung von 87,6 % und einer CPU-Auslastung von 51,2 % ausgehen. Das heißt, die bestehende Hardware reicht für die Erhöhung der Last aus. Allerdings ist es bei einer verteilten Installation nötig, nicht nur auf die summarische Belastung zu schauen, sondern auch die künftige Verteilung der Last auf die Server zu berücksichtigen. In unserem Beispiel erkennen wir, dass der Datenbankserver deutlich höher ausgelastet wird als die Applikationsserver. Da sich auf dem Datenbankserver eine SAP-Instanz befindet, muss die Last, die diese Instanz verursacht, reduziert und auf die beiden Applikationsserver verteilt werden.
Tools wie "Shortcut for SAP Systems" ergänzen fehlende Funktionen im Bereich der SAP Basis.
Viele Unternehmen kämpfen mit der Einführung und Benutzung von secinfo und reginfo Dateien für die Absicherung von SAP RFC Gateways.
Stellt der Dispatcher fest, dass ein SAP-Workprozess des benötigten Typs (Dialog, Verbuchung etc.) frei ist, übergibt er diesem den Auftrag, und der Workprozess kann seine Arbeit aufnehmen.