Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

© 2000 Sedat Kocabiyik22.03.2000Projektgruppe SAP R/3 auf Linux Cluster R EMOTE F UNCTION C ALL.

Ähnliche Präsentationen


Präsentation zum Thema: "© 2000 Sedat Kocabiyik22.03.2000Projektgruppe SAP R/3 auf Linux Cluster R EMOTE F UNCTION C ALL."—  Präsentation transkript:

1 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux Cluster R EMOTE F UNCTION C ALL

2 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 2 Gliederung des Vortrages n Einleitung n Synchrone RFCs n Asynchrone RFCs n Übergabe von Tabellen

3 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 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

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

5 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 5 SAP CPI-C Schnittstelle n Beim R/3 Release 2.0 und früheren Versionen existierte nur CPI-C Schnittstelle im ABAP/4 n 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

6 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 6 CPI-C Handler n 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. n 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

7 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 7 Andere Schnittstellen n 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) n Initializierung der Kommunikation: –RFC Schnittstelle braucht Informationen für die Initializierung(side information) –Im Sideinfo Tabellen gespeichert (Bei R/3 RFCDES Datenbank)

8 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 8 RFC Konzept TCP/IP Sideinfo File SAP Gateway (CPI-C Handler) External Program C Program RFC API R/3 Application Server RFC Interface(based on SAP CPI-C) Function Modules R/2 or SNA Host RFC Interface Database RFCDES Table Sideinfo File Sideinfo File or Table TRFC (R/2) TCP/IPLU 6.2

9 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 9 Gliederung des Vortrages n Einleitung n Synchrone RFCs n Asynchrone RFCs n Übergabe von Tabellen

10 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 10 Integration n CALL FUNCTION func DESTINATION dest EXPORTING e_p1 = e_f1e_p2 = e_f2... IMPORTING i_p1 = i_f1i_p2 = i_f2... TABLES t_p1 = itab1 t_p2 = itab2... EXCEPTIONS except1 = rc1 except2 = rc2... n 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

11 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 11 Integration DispatcherShared Memory R/3 Application Server PXA Taskhandler DYNP ABAP Processor Roll Area Work Process RFC ENGINE

12 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 12 Struktur des RFC Engine n 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 n 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

13 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 13 Datenstruktur n 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 n RFCIO_OPEN_CNTL –act_cntl:Zeigt den aktuellen Arraykomponent –handle: Index des Arrays

14 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 14 Datenstruktur cntl alloc_items free_slots RFCIO_GLOBAL 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 RFCIO_OPEN_CNTL Structure RFCIO_OPEN_CNTL 1... Structure RFCIO_OPEN_CNTL i... Structure RFCIO_OPEN_CNTL n rfc_gl act_cntl (rfc_gl.cntl + handle) RFC Data Structure for Existing Connections of an Internal Mode

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

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

17 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 17 Container n 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 n RFC Engine überprüft das Container ID n Für SNA Partner wird keine Container benutzt

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

19 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 19 Gliederung des Vortrages n Einleitung n Synchrone RFCs n Asynchrone RFCs n Übergabe von Tabellen

20 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 20 Asynchrone RFCs n CALL FUNCTION func IN BACKGROUND TASK DESTINATION dest EXPORTING e_p1 = e_f1e_p2 = e_f2... TABLES t_p1 = itab1 t_p2 = itab2... n Grober Ablauf: –Speicherung auf Tabellen –Commit Work Statement n Destination Systeme:3 und I (R/3 R/3) T (RFC via RFC API) M (CMC X.400 protokoll)

21 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 21 Struktur n 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

22 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 22 Im LUW n 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 n Scheduler eines asyncronen RFCs (Funktionsmodul ARFC_RUN_NOWAIT)

23 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 23 Datenbanktabellen n 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 IDProcess ID Time Stamp TIDLog Destinati on CounterBlock number ARFC Data ARFC Data..

24 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 24 Datenbanktabellen n 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 TimeDateUser Number Of Retrys TIDHost Name Return MessageReserved

25 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 25 Scheduler n 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.

26 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 26 Scheduler n 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

27 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 27 Weitere Zustände n Der Zustand von einem asynchronen RFC kann im Klient System mit dem SM58 geprüft werden RECORDEDSYSFAIL VBRECORDMAILED DEBUGNO_CONF SENDEDREAD CPICERR EXECUTED

28 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 28 Zustandsübergänge EXECUTED delete ARFC_DES T_SHIP ARFC_DEST _CONFIRM COMMIT WORK CALL F. ARFC _DEST_SHIP CALL F. ARFC_DE ST_CONFIRM RECORDED SENDED EXECUTED NO_CONF delete EXECUTED Entry found Caller Callee

29 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 29 Gliederung des Vortrages n Einleitung n Synchrone RFCs n Asynchrone RFCs n Übergabe von Tabellen

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

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

32 © 2000 Sedat Kocabiyik Projektgruppe SAP R/3 auf Linux ClusterSeite: 32 Datenstruktur n Variablen objects und log sind Zeiger auf die sogenannte Table Headers n Urgent Counter Variable ist hinter den Zeigern plaziert n Die restlichen Felder sind mit Flags belegt: no_logging, init, logged, trace objects log urgent no_logging init logged trace off DELTA_HEAD delta_head LOG_HANDLE next rebuild discard confirm withdrawn playback LOG_OBJID log_objid LOG_OPERATION log_operation SAP_UNIT line LOG_INFO log_info RFC_SHARE_CNTL LOG_OBJECT LOG_ENTRY

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


Herunterladen ppt "© 2000 Sedat Kocabiyik22.03.2000Projektgruppe SAP R/3 auf Linux Cluster R EMOTE F UNCTION C ALL."

Ähnliche Präsentationen


Google-Anzeigen