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

22.03.2000Projektgruppe SAP R/3 auf Linux Cluster© 2000 Sedat Kocabiyik

REMOTE FUNCTION CALL

22.03.2000Projektgruppe SAP R/3 auf Linux Cluster Seite: 2© 2000 Sedat Kocabiyik

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:

– Kommunikation via Dateien (Lesen/Schreiben von Dateien und deren

Austausch)

– Programm-zu-programm Kommunikation

– Direkter Datenbankzugriff

– Unterstützung der standarden Telekommunikationdienste


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


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


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


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)


RFC Konzept

TCP/IP

Sideinfo File

SAP Gateway (CPI-C Handler)

External ProgramC Program

RFC API

R/3 Application Server

RFC Interface(based on SAP CPI-C)

Function Modules

R/2 orSNA Host

RFC Interface

Database

RFCDES TableSideinfo File

Sideinfo File orTable TRFC (R/2)

TCP/IP LU 6.2



Einleitung

Synchrone RFCs

Asynchrone RFCs



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


Integration

Dispatcher Shared Memory

R/3 Application

Server

PXA

Taskhandler

DYNP

ABAP ProcessorRoll Area

Work Process

RFC ENGINE


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


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


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


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


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


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


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



Einleitung

Synchrone RFCs

Asynchrone RFCs



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)


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


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)


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


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


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.


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


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


Zustandsübergänge

EXECUTED delete

ARFC_DEST_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



Einleitung

Synchrone RFCs

Asynchrone RFCs



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


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:

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)


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

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


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

Documents

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