R EMOTE F UNCTION C ALL

REMOTE FUNCTION CALL Projektgruppe SAP R/3 auf Linux Cluster

Gliederungdes Vortrages • Einleitung • Synchrone RFCs • Asynchrone RFCs • Übergabe von Tabellen Projektgruppe SAP R/3 auf Linux Cluster

Kommunikation SAP R/3 ist ein offenes System, deshalb unterstützt er unterschiedliche Kommunikationsarten: • Kommunikation via Dateien (Lesen/Schreiben von Dateien und deren Austausch) • Programm-zu-programm Kommunikation • Direkter Datenbankzugriff • Unterstützung der standarden Telekommunikationdienste Projektgruppe SAP R/3 auf Linux Cluster

Programm-zu-programm • RFC ermöglicht programm-zu-programm Kommunikation • In der Applikationsebene • In der Präsentationsebene • RFC Aufruf für • ABAP/4 Funktionsmodule in R/2 oder R/3 System • Externe Funktion im beliebigen System • RFC Server (Callee) und RFC Client (Caller) • Bei C-programm zusätzliche Administrationen nötig Projektgruppe SAP R/3 auf Linux Cluster

SAP CPI-C Schnittstelle • Beim R/3 Release 2.0 und früheren Versionen existierte nur CPI-C Schnittstelle im ABAP/4 • CPI-C Schnittstelle hat folgende Funktionen: • Aufbauen von Kommunikationsverbindungen • Kontrollierung der Richtung der Datenübertragung • Kode-Umwandlung zwischen ASCII und EBCDIC • Error Handling • Terminierung von Kommunikationsverbindungen Projektgruppe SAP R/3 auf Linux Cluster

CPI-C Handler • CPI-C Handler: • wird auch SAP Gateway genannt. • Zentraler Knoten im R/3 System • Alle Programm-zu-programm Kommunikationen werden durch CPI-C Handler geroutet. • Protokolle: • TCP/IP Protokoll: R/3 <-> R/3, R/3 <-> Externes System • LU 6.2: Ein Kommunikationspartner ist R/2 System oder externe Applikation auf dem SNA Host Projektgruppe SAP R/3 auf Linux Cluster

Andere Schnittstellen • Andere Schnittstellen: • RFC Schnittstelle: Kommunikationspartner unterschiedlicher Typen • RFC API: damit implementieren die externe Programme die RFC Funktionalität • Das Attribut „remote funtion call supported“ im ABAP/4 Development Workbrench einstellen. (function module stub generierung) • Initializierung der Kommunikation: • RFC Schnittstelle braucht Informationen für die Initializierung(side information) • Im Sideinfo Tabellen gespeichert (Bei R/3 RFCDES Datenbank) Projektgruppe SAP R/3 auf Linux Cluster

RFC Konzept Sideinfo File SAP Gateway (CPI-C Handler) TCP/IP TCP/IP LU 6.2 External Program C Program R/3 Application Server R/2 or SNA Host RFC Interface(based on SAP CPI-C) RFC API RFC Interface Function Modules Database Sideinfo File or Table TRFC (R/2) Sideinfo File RFCDES Table Projektgruppe SAP R/3 auf Linux Cluster

Integration • CALL FUNCTION func DESTINATION dest EXPORTING e_p1 = e_f1 e_p2 = e_f2 ... IMPORTING i_p1 = i_f1 i_p2 = i_f2 ... TABLES t_p1 = itab1 t_p2 = itab2 ... EXCEPTIONS except1 = rc1 except2 = rc2 ... • Integration: • Work Prozess: SAPMSSY1, PXA • ABAP Prozessor: implementiert das ABAP Runtime System • RFC Engine: im ABAP Prozessor plaziert • Roll Bereich: prozess-spezifische Daten • Task Handler: Dienste implementiert für ABAP Prozessor • Shared Memory: Dispatcher<->Workprozesse Projektgruppe SAP R/3 auf Linux Cluster

Integration Dispatcher R/3 Application Server Shared Memory Work Process Taskhandler DYNP ABAP Processor Roll Area PXA Projektgruppe SAP R/3 auf Linux Cluster

Struktur des RFC Engine • 4 perioden im RFC: • CALL Schritt: Klient ruft remote function auf • CALLRECEIVE Schritt: Nach dem Empfangen des Requests startet Server die Verarbeitung • RETURN Schritt: Server sendet Rückgabewerte zurück • RETURN RECEIVE Schritt: Klient empfängt die Rückgabewerte • Treibertypen: • „3“: anderes R/3 System (mit unterschiedlicher Datenbank) • „I“: gleiche R/3 System • „T“: TCP/IP Verbindung • Zum externen Programm • Zum SAPGUI • „X“: zurück zum ABAP Projektgruppe SAP R/3 auf Linux Cluster

Datenstruktur • Es existiert ein Datenbereich für jede aufgebaute RFC Verbindung: RFCIO_GLOBAL • cntl : Zeiger auf Array • alloc_items : Anzahl der Arraykomponente • free_slots :index desunbenutzte Arraykomponent • RFCIO_OPEN_CNTL • act_cntl: Zeigt den aktuellen Arraykomponent • handle: Index des Arrays Projektgruppe SAP R/3 auf Linux Cluster

Datenstruktur RFCIO_GLOBAL RFCIO_OPEN_CNTL rfc_gl act_cntl (rfc_gl.cntl + handle) RFC Data Structure for Existing Connections of an Internal Mode Projektgruppe SAP R/3 auf Linux Cluster

Verarbeitung eines RFCs • CALL Schritt: • Klient sendet Function module Call Daten zum Server mit dem Container • CALL RECEIVE Schritt: • Dispathcher empfängt APPC request vom SAP Gateway • Function module stub wird ausgeführt • RETURN Schritt: • Nach der Verarbeitung werden Rückgabewerte zurückgeschickt • RETURN RECEIVE Schritt: • Rückgabewerte werden empfangen Projektgruppe SAP R/3 auf Linux Cluster

CALLBACK • CALLBACK ist ein RFC für Klient System • Destination Name kann explizit angegeben werden, oder vordefiniertes BACK sein • Klient prüft ob es ein CALLBACK-Fall ist • Übergang vom RETURN RECEIVE zum CALL RECEIVE Projektgruppe SAP R/3 auf Linux Cluster

Container • Containertypen: • Container, die am Anfang des RFCs geschickt werden(Identifizierung) • Container, die für die Parameterübergabe zuständig sind • Container für ‚End, Exception & Error Handling‘ • RFC Engine überprüft das Container ID • Für SNA Partner wird keine Container benutzt Projektgruppe SAP R/3 auf Linux Cluster

Buffer Manager • Pufferung reduziert die Netzwerk Last • Pufferung in zwei Fällen: • Bevor die Daten geschickt werden • Nach dem sie empfangen wurden • APPC Bereich als Puffer • Jede RFC Verbindung hat ihren eigenen Data Send Buffer mit fixierter Länge • Die Variable buffer im RFCIO_OPEN_CNTL zeigt auf Data Send Buffer Projektgruppe SAP R/3 auf Linux Cluster

Asynchrone RFCs • CALL FUNCTION func IN BACKGROUND TASK DESTINATION dest EXPORTING e_p1 = e_f1 e_p2 = e_f2 ... TABLES t_p1 = itab1 t_p2 = itab2 ... • Grober Ablauf: • Speicherung auf Tabellen • Commit Work Statement • Destination Systeme: „3“ und „I“ (R/3 <-> R/3) „T“ (RFC via RFC API) „M“ (CMC X.400 protokoll) Projektgruppe SAP R/3 auf Linux Cluster

Struktur • Struktur von asynchronen RFCs • Für jedes LUW eine Transaktions-ID (TID) • RFC Argumente (ARFCSDATA) und RFC Requests (ARFCSSTATE) werden gespeichert • RFC Request an Update Work Prozess • Verarbeitung von RFCs • Start time wird im COMMIT WORK gespeichert Projektgruppe SAP R/3 auf Linux Cluster

Im LUW • Fallunterscheidung im LUW • Update Request findet statt: • Neuer Update Request eingefügt • Starten vom Scheduler • Keine Update Request findet statt: • Mehr als zwei Work Prozesse • Scheduler wird direkt aufgerufen (Ausführungszeit) • Weniger als zwei Work Prozesse • Scheduler wird auf einem anderen Applikations-Server gestartet • Scheduler eines asyncronen RFCs (Funktionsmodul ARFC_RUN_NOWAIT) Projektgruppe SAP R/3 auf Linux Cluster

Datenbanktabellen • Datenbanktabelle ARFCSDATA und interne Tabelle SENDDATA • Die ersten vier Felder sind von einer include Struktur ARFCTID bestimmt • Logical destination name, Zähler des ARFCs, Blocknummer, und Parameterdaten .. Projektgruppe SAP R/3 auf Linux Cluster

Datenbanktabellen • Datenbanktabelle ARFCSSTATE und interne Tabelle SENDSTATE • Ein asynchrone FC status ist mit call ID identifiziert und der Zustand wird im ARFCSTATE gespeichert • Restlichen Felder: Funktionsmodul Name, Zeit, Datum und SAP user • ARFCRETRYS: Anzahl der (wiederholten) Versuche • Aktueller Transaktionskod, Server Host Name und ein Feld für Fehlermeldungen Projektgruppe SAP R/3 auf Linux Cluster

Scheduler • Workload Restriction • Scheduler sammelt RFC Requests des LUW und ordnet den Server Prozesse zu.(Server LUW) • Scheduler arbeitet im alternativen Dialog Workprozess • Enqueue Mechanismus: Wenn ein Request abgelehnt wird, heißt daß schon ein enqueue für diesen Destination Name bereits läuft (Ziel dabei ist die Reduzierung der Anzahl der Work Prozesse) • ARFC_RUN_NOWAIT(gestartet vom Klient) startet ein alternatives Dialog Work Prozess. • Aufgenommene Requests werden vom laufenden Scheduler verarbeitet • Es gibt ein möglichkeit, daß der Administrator mehr als einen work Prozess zu einem ARFC zuordnet. Dann sind die Logical Destination Namen in einer Tabelle gespeichert. Der Scheduler wählt zufällig einen. Projektgruppe SAP R/3 auf Linux Cluster

Scheduler • Scheduler Loop • Wenn ein Enqueue erhalten ist, Scheduler ruft Funktionsmodul ARFC_RUN auf.(welche LUW startet) • Requests werden nachNamen sortiert • Der Zustand der aufgenommenen ARFCs wird auf „SENDED“ gesetzt • Wenn keine Fehler auftreten, wird der Zustand auf „EXECUTED“ oder „MAILED“ gesetzt • Entsprechende Einträge werden dann gelöscht(ARFCSTATE) • Wenn Löschoperation fehlt, Zustand wird auf „NO_CONF“ gesetzt • Bei der Rückgabe COMMUNICATION_FAILURE, wird auf „CPICERR“ gesetzt (erneutes Versuch) • Bei SYSTEM_FAILURE auf „SYSFAIL“ • Beim erfolg, alle RFC Daten für dieses LUW werden gelöscht Projektgruppe SAP R/3 auf Linux Cluster

Weitere Zustände • Der Zustand von einem asynchronen RFC kann im Klient System mit dem SM58 geprüft werden RECORDED SYSFAIL VBRECORD MAILED DEBUG NO_CONF SENDED READ CPICERR EXECUTED Projektgruppe SAP R/3 auf Linux Cluster

Zustandsübergänge COMMIT WORK CALL F. ARFC _DEST_SHIP CALL F. ARFC_DE ST_CONFIRM Caller EXECUTED Entry found Callee Projektgruppe SAP R/3 auf Linux Cluster

Delta Manager • Delta Manager spielt in der Übergabe von Tabellenparameter eine Rolle • Wenn eine interne Tabelle gesendet wird, sendet man die komplette Tabelle zum RFC Server • Im RFC Server wird eine lokale Kopie erzeugt • Beim Funktionsmodul RETURN oder beim CALLBACK wird nur delta informationen geschickt Projektgruppe SAP R/3 auf Linux Cluster

Struktur von Delta Manager • Delta Manager ist an RFC Engine angeschlossen • Der Handler of internal Tables implementiert alle Tabellenoperationen • Delta Manager besteht aus drei Teilen: • Register Agent: Registriert Tabellen, die in der Verbindung zum ersten Mal benutzt werden ordnet eine Object ID zu der Tabelle • Log Agent: wird vom Table Handler aufgerufen speichert Informationen über Tabellenoperationen in ein Datenbereich (DELTA_LOG enthält high priority entries; die Tabellenoperationen beschreiben) • Playback Agent: Empfängt die log entries via Container Agent und spielt die entsprechende Operation ab (Playback) Projektgruppe SAP R/3 auf Linux Cluster

Datenstruktur • Variablen objects und log sind Zeiger auf die sogenannte Table Headers • Urgent Counter Variable ist hinter den Zeigern plaziert • Die restlichen Felder sind mit Flags belegt: no_logging, init, logged, trace LOG_OBJECT RFC_SHARE_CNTL LOG_ENTRY Projektgruppe SAP R/3 auf Linux Cluster

Delta Management • CALL Schritt: • Zuerst high priority entries gesendet • Container: RFCID_DeltaWithdrawn, RFCID_DeltaConfirm • Tabelle wird registriert • CALL RECEIVE Schritt: • Der Name, Object ID, Tabelleninformationen werden gelesen • Tabellen Einträge werden empfangen und in die Tabelle eingefügt • RETURN Schritt: • Die high priority log entries im DELTA_LOG werden wieder gesendet • RETURN RECEIVE Schritt: • Tabellenoperationen werden abgespielt Projektgruppe SAP R/3 auf Linux Cluster

R EMOTE F UNCTION C ALL