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.
Weitere Informationen: 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.
Prozess
Prüfung der Ressourcen des lokalen Applikationsservers
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)
Prüfung der Ressourcen anderer Applikationsserver
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
und die Export-Parameter
NOREQ: Anzahl möglicher asynchroner RFC Requests
MAXREQ: Maximale Anzahl 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.
Reduzierung der Ressourcen
Bei jeder Ressource wird eventuell eine Reduzierung vorgenommen, wenn der aktuelle Verbrauch zu nahe an der Quote liegt.
new_resource = min((quota-count),resource)
Vorgeschlagene Wartezeit
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).