!--a11y-->
Ressourcenermittlung für asynchronen und
transaktionalen RFC 
Die Ermittlung der Ressourcen für einen Applikationsserver erfolgt in 2 Schritten. Zunächst wird geprüft, ob lokal überhaupt genügend Ressourcen für die Prüfung vorhanden sind (Kommunikationskanäle und Platz für ARFC-Antworten). Wenn ja, wird die detaillierte Prüfung durchgeführt. Soll der lokale Applikationsserver geprüft werden, erfolgt diese Prüfung im Workprozess. Falls ein anderer Applikationsserver geprüft werden soll, so übernimmt der Dispatcher dieses Servers die Prüfung.
Die Algorithmen zur Prüfung werden im SAP-Kernel durchgeführt und sind im Detail in den folgenden Abschnitten beschrieben:
Sie können auch auf Clientseite einen Ressourcen-Check auf dem RFC-Server veranlassen: hierzu benutzen Sie die ARFC-Optionen in der Transaktion SM59. Diese sind in folgendem Abschnitt beschrieben: Ressourcenprüfung als RFC-Client anstoßen.

Sie können den Detailgrad der Prüfung auf der Serverseite durch den Parameter rdisp/rfc_check steuern.
Die lokale Prüfung erfolgt durch Aufrufen des Funktionsbausteines TH_ARFC_LOCAL_RESOURCES.
Dieser hat die Importparameter
· CHECK_CLIENT_ONLY: Ist dieser Parameter auf 1 gesetzt, so wird nur geprüft, ob sind Kommunikationskanäle und Platz für ARFC-Antworten vorhanden sind. Der Ablauf dieser Prüfung ist im Abschnitt Lokale Prüfung beschrieben.
Ist CHECK_CLIENT_ONLY nicht gesetzt, so wird anschließend die detaillierte Prüfung im Workprozess durchgeführt.
· TRACE: Ist der Trace-Parameter gesetzt, werden die ermittelten Ressourcen in die Trace-Datei des Dispatchers dev_disp geschrieben.
Folgende Export-Parameter gibt der Funktionsbaustein zurück:
· NORES: Anzahl der Ressourcen für asynchronen RFC
· WAIT: Vorschlagswert für die Wartezeit (Sekunden)
· REASON: Grund weshalb keine Ressourcen verfügbar sind
· MAXRES: Anzahl der maximal verfügbaren Ressourcen
· IREASON: Grund weshalb keine Ressourcen verfügbar sind (intern)
Zur Prüfung der Ressourcen eines anderen Servers wird der Funktionsbaustein TH_ARFC_REQUESTS verwendet. Er hat die Import-Parameter
· SERVER: Auf welchem Server sollen die Ressourcen ermittelt werden?
· TRACE: siehe oben
Export-Parameter
· NOREQ: Anzahl möglicher asynchroner RFC Requests
· MAXREQ: Anzahl maximaler asynchroner RFC Requests
· REASON: Grund weshalb keine Ressourcen verfügbar sind
· CREASON: Grund weshalb keine Ressourcen verfügbar sind
Hier wird zuerst die lokale Prüfung, anschließend die detaillierte Prüfung durch den Dispatcher des entfernten Applikationsservers durchgeführt.
Bei jeder Ressource wird eventuell eine Reduzierung
vorgenommen, wenn der aktuelle Verbrauch zu nahe an der Quote liegt.
new_resource =
min((quota-count),resource)
Falls keine Ressourcen mehr vorhanden sind, wird dem
Aufrufer eine Wartezeit vorgeschlagen. Die maximale Wartezeit (max_wait) kann
durch den Profilparameter rdisp/rfc_max_wait_time,
(Defaultwert 15 Sekunden) definiert werden.
Diese Wartezeit berechnet sich folgendermaßen:
quota =
Ressource * Parameterwert / 100
count = aktueller Verbrauch der Ressource
Da keine Ressourcen zurückgeliefert werden, ist also count >
quota
wait = min
(max(1,count-quota), max_wait).