Detaillierte Prüfung

Verwendung

Diese Prüfung kann im Dispatcher oder im Workprozess stattfinden: Wenn der lokale Applikationsserver geprüft werden soll, findet sie im Workprozess statt, wenn ein anderer Server geprüft werden soll, findet sie im Dispatcher des zu prüfenden Servers statt. Dadurch wird kein freier Dialog-Workprozess für die Abarbeitung des Requests benötigt. D.h. der Aufrufer wird nicht dadurch blockiert, dass er auf einen freien Dialog-Workprozess warten muss.

Prozess

Hier ist der Ablauf so:

Die Anzahl der maximal verfügbaren Ressourcen wird bestimmt: Anzahl der Dialog-Workprozesse (dia_wps) - Anzahl der Dialog-Workprozesse, die für die Dialog-Anwender frei bleiben sollen (wait_dia_wps).

Diese Anzahl wird durch den Profilparameter rdisp/rfc_min_wait_dia_wp bestimmt.

Falls die Anzahl der Dialog-Workprozesse kleiner ist als die Anzahl der Workprozesse, die für die Dialog-Anwender frei bleiben sollen, dann wird diese Anzahl auf wait_dia_wp = dia_wps - 1 gesetzt.
Es wird geprüft, ob die Ressourcenermittlungüberhaupt aktiviert ist.

Falls die Ressourcenermittlung deaktiviert ist (nicht erlaubt!) wird der Rückgabewert=2 und der Grund= TH_ARFC_RES_NOT_ACTIVATED gesetzt.
Es wird geprüft, ob freie Workprozesse vorhanden sind, um Aufträge entgegenzunehmen:
1. Anzahl der freien Workprozesse wird bestimmt (waiting_wps)
2. Falls waiting_wps <= wait_dia_wps ist, werden keine Ressourcen zurückgegeben und der Grund= TH_ARFC_RES_WAITING_DIAWP und Rückgabewert=0 gesetzt.
3. Die Ressourcen werden neu ermittelt
  
  Hierzu wird zunächst die Anzahl der Workprozesse bestimmt, die gerade durch aktive RFCs belegt sind (Funktion DpGetExtCheckedResourcesCnt). Diese wird von der max. Anzahl belegbarer Prozesse abgezogen, also
  
  dia_wps-wait_dia_wps-DpGetExtCheckedResourcesCnt()
  
  ausgerechnet. Das Minimum aus diesem Wert und der Anzahl der momentan freien Dialog-Workprozesse wird dann als zuteilbare Ressource bestimmt.
  
  resources=min(waiting_wps,(dia_wps-wait_dia_wps-DpGetExtCheckedResourcesCnt()))
Prüfung der Kommunikationskanäle: sind noch genügend Einträge der Kommunikationstabelle vorhanden (Anzeige über SM51 Springen Server Informationen Komm.Tabelle )
1. quota = (rdisp/max_comm_entries * rdisp/rfc_max_comm_entries) / 100
  
  (es zählt nur der ganzzahlige Anteil, Stellen nach dem Komma werden ignoriert).
  
  Falls die Quote 0 ergibt, wird der Grund = TH_ARFC_RES_LOW_MAX_COMM_ENTRIES und der Returnwert 2 ( NEVER_GET_RESOURCES) gesetzt.
2. Die Anzahl der benutzten Kommunikationskanäle wird bestimmt, und es wird geprüft, ob die erlaubte Quote überschritten ist.
3. Falls die Quote überschritten ist ( count>quota), werden keine Ressourcen zurückgeliefert und der Grund = TH_ARFC_RES_MAX_COMM_ENTRIES gesetzt und der Rückgabewert 0 gesetzt.
4. Ansonsten werden die Ressourcen neu ermittelt (und eventuell reduziert)
  
  new_resources = min(quota - count, resources) und der Grund = TH_ARFC_RES_OK und der Rückgabewert 0 gesetzt.
Prüfung der belegten Workprozesse: Hat der Benutzer schon zu viele Workprozesse belegt? (Anzeige über SM50)
1. quota = (dia_wps * rdisp/rfc_max_own_used_wp) / 100
  
  (es zählt nur der ganzzahlige Anteil, Stellen nach dem Komma werden ignoriert).
  
  Falls die Quote 0 ergibt, wird der Grund= TH_ARFC_RES_LOW_OWN_USED_WP und der Returnwert=2 ( NEVER_GET_RESOURCES) gesetzt.
2. Die Anzahl der selbst benutzten Workprozesse wird bestimmt, und es wird geprüft, ob die erlaubte Quote überschritten ist.
3. Falls die Quote überschritten ist ( count>quota) werden keine Ressourcen zurückgeliefert und der Grund= TH_ARFC_RES_OWN_USED_WP gesetzt und der Rückgabewert=0 gesetzt.
4. Ansonsten werden die Ressourcen neu ermittelt (und eventuell reduziert)
  
  new_resources = min(quota - count, resources) und der Grund = TH_ARFC_RES_OK und der Rückgabewert 0 gesetzt.
Prüfung der Dispatcher-Queue (Dialog-Queue des Dispatchers)

Da jeder RFC mit einem Eintrag in die Dialog-Queue verbunden ist, wird überprüft ob in der Dialog-Queue noch genügend Platz für neue Aufträge vorhanden ist. (Anzeige über Transaktion SM51 Springen Server Informationen Queue Info , Profilparameter rdisp/elem_per_queue, Default=2000). Es werden die aktuellen Queue-Informationen gelesen.
1. Falls es dabei zu einem Fehler kommt, wird Grund= TH_ARFC_RES_REQQUEUE_ERROR und der Rückgabewert=2 gesetzt. Ansonsten
  
  que_max= maximale Anzahl von Einträgen in der Queue
  
  count= aktuelle Anzahl von Einträgen in der Queue
2. quota = (que_max * rdisp/rfc_max_queue) / 100
  
  (es zählt nur der ganzzahlige Anteil, Stellen nach dem Komma werden ignoriert).
  
  Falls die Quote 0 ergibt, wird der Grund= TH_ARFC_RES_LOW_REQQUEUE und der Returnwert=2 ( NEVER_GET_RESOURCES) gesetzt.
3. Falls die Quote überschritten ist ( count>quota), werden keine Ressourcen zurückgeliefert und der Grund= TH_ARFC_RES_REQQUEUE gesetzt und der Rückgabewert=0 gesetzt.
Anmeldungen

Da jeder RFC mit einer Anmeldung im Zielsystem verbunden ist, wird überprüft ob noch Anmeldungen vorgenommen werden können. (Anzeige über Transaktion SM04, Profilparameter rdisp/tm_max_no, Default=200).
1. quota = (rdisp/tm_max_no * rdisp/rfc_max_login) / 100
  
  (es zählt nur der ganzzahlige Anteil, Stellen nach dem Komma werden ignoriert).
  
  Falls die Quote 0 ergibt, wird der Grund= TH_ARFC_RES_LOW_LOGIN und der Returnwert=2 ( NEVER_GET_RESOURCES) gesetzt.
  
  count= Anzahl der Anmeldungen
2. Falls die Quote überschritten ist ( count>quota), werden keine Ressourcen zurückgeliefert und der Grund= TH_ARFC_RES_LOGIN gesetzt und der Rückgabewert=0 gesetzt.
3. Ansonsten werden die Ressourcen neu ermittelt (und eventuell reduziert)
  
  new_resourcen=min(quota - count, resources) und der Grund= TH_ARFC_RES_OK und der Rückgabewert=0 gesetzt.
Eigene Anmeldungen

Da jeder RFC mit einer Anmeldung im Zielsystem verbunden ist, wird überprüft, ob noch Anmeldungen vorgenommen werden können. Damit nicht ein Benutzer zu viele Anmeldungen im System vornimmt, ist die Anzahl der eigenen Anmeldungen beschränkt (Anzeige über Transaktion SM04, Profilparameter rdisp/tm_max_no, Default=200).
1. quota = (rdisp/tm_max_no * rdisp/rfc_max_own_login) / 100
  
  (es zählt nur der ganzzahlige Anteil, Stellen nach dem Komma werden ignoriert).
  
  Falls die Quote 0 ergibt, wird der Grund= TH_ARFC_RES_LOW_OWN_LOGIN und der Returnwert=2 ( NEVER_GET_RESOURCES) gesetzt.
  
  count= Anzahl der Anmeldungen
2. Falls die Quote überschritten ist ( count>quota), werden keine Ressourcen zurückgeliefert und der Grund= TH_ARFC_RES_OWN_LOGIN gesetzt und der Rückgabewert=0 gesetzt.
  
  Ansonsten werden die Ressourcen neu ermittelt (und eventuell reduziert).
Serverzustand

Damit der Server einen RFC-Request bearbeiten kann, muss er betriebsbereit sein. Ein Server ist im Normalzustand aktiv. Sollte sich der Server in einem anderen Zustand befinden, werden keine Ressourcen zurückgeliefert und der Grund entsprechend gesetzt.

Weitere Informationen: Zustände eines SAP-Applikationsservers
- TH_ARFC_RES_SERVER_HIBERNATE, der Server wurde deaktiviert (über SM51 oder SMMS, damit bekommt er von anderen Servern keine Aufträge mehr z.B. Verbuchung)
- TH_ARFC_RES_SERVER_SHUTDOWN, der Server wird gerade heruntergefahren
- TH_ARFC_RES_SERVER_STOP, der Server wurde gestoppt (nach dem Shutdown)
- TH_ARFC_RES_SERVER_STARTING, der Server befindet sich in der Startphase und ist noch nicht betriebsbereit
- TH_ARFC_RES_SERVER_INIT, der Server ist initialisiert (vor der Startphase)
- TH_ARFC_RES_SERVER_UNKNOWN, der Server befindet sich in einer unbekannten Phase (sollte nicht vorkommen)

Weitere Informationen

Ressourcenprüfung als RFC-Client anstoßen