REMOTE FUNCTION CALL Projektgruppe SAP R/3 auf Linux Cluster 22.03.2000

Gliederung des Vortrages Einleitung Synchrone RFCs Asynchrone RFCs Übergabe von Tabellen Projektgruppe SAP R/3 auf Linux Cluster 22.03.2000

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 22.03.2000

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 22.03.2000

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 22.03.2000

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 22.03.2000

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 22.03.2000

SAP Gateway (CPI-C Handler) RFC Interface(based on SAP CPI-C) 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 22.03.2000

Gliederung des Vortrages Einleitung Synchrone RFCs Asynchrone RFCs Übergabe von Tabellen Projektgruppe SAP R/3 auf Linux Cluster 22.03.2000

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 22.03.2000

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

Struktur des RFC Engine 4 perioden im RFC: CALL Schritt: Klient ruft remote function auf CALL RECEIVE 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 22.03.2000

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 des unbenutzte Arraykomponent RFCIO_OPEN_CNTL act_cntl: Zeigt den aktuellen Arraykomponent handle: Index des Arrays Projektgruppe SAP R/3 auf Linux Cluster 22.03.2000

Datenstruktur RFCIO_GLOBAL RFCIO_OPEN_CNTL rfc_gl cntl alloc_items free_slots name Logical destination name RFC_TYPE type channel Driver index Buffer administration variables (buffer,...) External handles (icontl, conv_id) Receive data (session, header, sysid[ ]) Caller data Delta manager area RFC_SHARE_CNTL share flags Structure RFCIO_OPEN_CNTL 1 . . . Structure RFCIO_OPEN_CNTL i Structure RFCIO_OPEN_CNTL n act_cntl (rfc_gl.cntl + handle) RFC Data Structure for Existing Connections of an Internal Mode Projektgruppe SAP R/3 auf Linux Cluster 22.03.2000

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 22.03.2000

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 22.03.2000

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 22.03.2000

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 22.03.2000

Gliederung des Vortrages Einleitung Synchrone RFCs Asynchrone RFCs Übergabe von Tabellen Projektgruppe SAP R/3 auf Linux Cluster 22.03.2000

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 22.03.2000

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 22.03.2000

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 22.03.2000

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 .. IP ID Process ID Time Stamp TID Log Destination Counter Block number ARFC Data ARFC Data Projektgruppe SAP R/3 auf Linux Cluster 22.03.2000

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 CALLID State Module Name RFC.RET Time Date User Number Of Retrys TID Host Name Return Message Reserved Projektgruppe SAP R/3 auf Linux Cluster 22.03.2000

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 22.03.2000

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 22.03.2000

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 22.03.2000

Zustandsübergänge EXECUTED delete Caller Callee RECORDED SENDED EXECUTED NO_CONF delete COMMIT WORK CALL F. ARFC _DEST_SHIP CALL F. ARFC_DE ST_CONFIRM Caller EXECUTED Entry found Callee ARFC_DEST_SHIP ARFC_DEST_CONFIRM EXECUTED delete Projektgruppe SAP R/3 auf Linux Cluster 22.03.2000

Gliederung des Vortrages Einleitung Synchrone RFCs Asynchrone RFCs Übergabe von Tabellen Projektgruppe SAP R/3 auf Linux Cluster 22.03.2000

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 22.03.2000

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 22.03.2000

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 DELTA_HEAD delta_head LOG_HANDLE next rebuild discard confirm withdrawn playback RFC_SHARE_CNTL objects log urgent no_logging init logged trace off LOG_ENTRY LOG_OBJID log_objid LOG_OPERATION log_operation SAP_UNIT line LOG_INFO log_info Projektgruppe SAP R/3 auf Linux Cluster 22.03.2000

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 22.03.2000