1 / 33

R EMOTE F UNCTION C ALL

R EMOTE F UNCTION C ALL. Gliederung des Vortrages. Einleitung. Synchrone RFCs. Asynchrone RFCs. Übergabe von Tabellen. Kommunikation. SAP R/3 ist ein offenes System, deshalb unterstützt er unterschiedliche Kommunikationsarten:

nadda
Download Presentation

R EMOTE F UNCTION C ALL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. REMOTE FUNCTION CALL Projektgruppe SAP R/3 auf Linux Cluster

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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

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

  10. 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

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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

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

  20. 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

  21. 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. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

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

  30. 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

  31. 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

  32. 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

  33. 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

More Related