Remote Function Call (RFC) ind SAP ABAP tutorial

Hvad er RFC i SAP?

RFC står for FjernfunktionsopkaldDet er den mekanisme, der gør det muligt for forretningsapplikationer at kommunikere og udveksle information – i foruddefinerede formater – med andre systemer. RFC er den mest almindelige måde at SAP systemet taler med et andet, og det er også broen, der forbinder SAP systemer til ikke-SAP applikationer.

RFC tilbyder to grænseflader:

1. En opkaldsgrænseflade til ABAP programmer.
2. En opkaldsgrænseflade for ikke-SAP programmer.

Ethvert ABAP-program kan kalde en fjernfunktion ved hjælp af OPKALDSFUNKTION...DESTINATION udmelding. Det DESTINATION parameter fortæller SAP system, hvor den kaldte funktion kører på et andet system end den, der kalder det.

Syntaks

CALL FUNCTION 'remotefunction'
  DESTINATION dest
  EXPORTING  f1 = ...
  IMPORTING  f2 = ...
  TABLES     t1 = ...
  EXCEPTIONS ...

Logiske destinationer defineres via transaktion SM59 og gemt i tabellen RFCDES.

RFC-grænsefladens funktioner

RFC-kørselstiden er ansvarlig for tre ting ved hvert kald:

• Konvertering af alle parameterdata til den repræsentation, der forventes af det eksterne system.
• Ringer til de kommunikationsrutiner, der er nødvendige for at tale med fjernsystemet.
• Håndtering af kommunikationsfejl og formidling af dem til den, der ringer op via EXCEPTIONS parameter af CALL FUNCTION.

RFC er SAP protokol, der håndterer kommunikation mellem systemer og forenkler den relaterede programmering. Det er processen med at kalde et funktionsmodul, der findes på en anden maskine end det kaldende program. RFC'er kan teknisk set bruges til at kalde et funktionsmodul på samme maskine, men de bruges oftest, når det kaldende og kaldte program kører på separate maskiner. RFC-grænsefladesystemet bruges til at oprette RFC-forbindelser mellem forskellige SAP systemer, såvel som mellem SAP og ekstern (ikke-SAP) systemer.

Detaljer, du skal vide om RFC

• SAP anvender CPIC protokol (Common Programming Interface for Communication) til at overføre data mellem systemer. CPIC er SAP-specifik. RFC er en kommunikationsgrænseflade bygget oven på CPI-C, men med flere funktioner og en mere brugervenlig overflade for applikationsprogrammører.
• RFC-bibliotekets funktioner understøtter C programmeringssprog og Visual Basic på Windows platforme.
• RFC-forbindelser fungerer på tværs af hele systemet. En RFC-forbindelse defineret i klient 000 kan også bruges fra klient 100 uden nogen forskel.
• RFC er protokollen til kald af specialiserede subrutiner (funktionsmoduler) over netværket. Funktionsmoduler kan sammenlignes med C-funktioner eller Pascal-procedurer: de eksponerer en defineret grænseflade, hvorigennem data, tabeller og returkoder udveksles. Funktionsmoduler administreres inde i SAP systemet i et dedikeret bibliotek, Funktionsbygger.
• Funktionsbyggeren (transaktion SE37) giver applikationsprogrammører et miljø til at skrive, dokumentere og test funktionsmoduler, der kan kaldes lokalt såvel som eksternt. Systemet genererer automatisk den ekstra kode (den RFC-stump) nødvendigt til fjernopkald.
• RFC-forbindelser vedligeholdes ved hjælp af transaktioner SM59. SAP sender også en RFC-SDK (Software Development Kit), der bruger omfattende C-biblioteker, så eksterne programmer kan oprette forbindelse til SAP system.
• Den eneste forskel mellem et fjernopkald til en anden server og et lokalt opkald er DESTINATION parameter, som angiver den målserver, som programmet skal køre på.

Fordele ved RFC

RFC reducerer programmeringsindsatsen ved at fjerne behovet for at genimplementere moduler og metoder i den eksterne ende. RFC-laget tager sig af:

• Konvertering af dataene til et format, som det eksterne (mål)system kan forstå.
• Kald af de rutiner, der er nødvendige for at oprette kommunikation med fjernsystemet.
• Håndtering af fejl, der opstår under kommunikation.
• Tilvejebringelse af pålidelig transaktionel semantik, når der anvendes transaktionelle eller køvarianter.

Typer af RFC

SAP understøtter fire RFC-varianter. Hver af dem tilbyder en forskellig afvejning mellem latenstid, pålidelighed og rækkefølgegarantier.

1. Synckronisk RFC (sRFC)

SyncChronous RFC kræver, at både klienten og serveren er tilgængelige på kaldetidspunktet. Det er den mest almindelige type og bruges, når den kaldende har brug for resultatet umiddelbart efter udførelse.

sRFC er et kommunikationsmiddel mellem systemer, hvor der forventes bekræftelser. Kildesystemets ressourcer venter på målsystemet og sikrer, at beskeden ankommer med en bekræftelse. De udvekslede data er konsistente og pålidelige.

Ulempen er, at hvis målsystemet ikke er tilgængeligt, venter kildesystemressourcerne, indtil det vender tilbage, hvilket kan skubbe kildesystemprocesser i dvale-/RFC/CPIC-tilstand på målsystemet og blokere ressourcer.

Anvendes til:

• Realtidskommunikation mellem systemer.
• Kommunikation mellem SAP Webapplikationsserveren og SAP GUI.

2. Asynkron RFC (aRFC)

Asynkron RFC er kommunikation mellem systemer, hvor der ikke kræves nogen bekræftelse – sammenlignelig med dropping et postkort med posten. Begge systemer behøver ikke at være tilgængelige på udførelsestidspunktet, og resultatet returneres ikke straks til det kaldende system.

Kildesystemressourcen venter ikke på målsystemet; den leverer dataene og går videre. Dette gør aRFC hurtig, men ikke pålidelig i sig selv — data kan gå tabt, hvis målsystemet ikke er tilgængeligt.

Anvendes til:

• "Sluk og glem"-kommunikation mellem systemer.
• Parallel behandling på tværs af systemer.

3. Transaktionel RFC (tRFC)

Transaktionel RFC er en særlig form for asynkron RFC. Den sikrer transaktionslignende håndtering af behandlingstrin, der ellers ville være autonome.

tRFC udfører det kaldte funktionsmodul på RFC-serveren præcis én gang, selvom dataene sendes flere gange på grund af netværksproblemer. Fjernsystemet behøver ikke at være tilgængeligt i det øjeblik, RFC-klienten kører kaldet. tRFC-komponenten gemmer den kaldte funktion og dens data i SAP database under en unik Transaktions-ID (TID)Hvis målsystemet ikke er tilgængeligt, skrives dataene i RFC-tabeller (synlige i transaktionsfeltet). SM58) og senere registreret af planlægningsrapporten RSARFCSE, som kører hvert 60. sekund.

Anvendes til:

• Udvidelse af asynkron RFC med højst én levering.
• Pålidelig kommunikation mellem systemer, hvor præcis éngangsudførelse er vigtig.

4. RFC i kø (qRFC)

Queued RFC udvider tRFC ved at garantere, at individuelle trin behandles i den rækkefølge, der er angivet af den kaldende applikation. For at sikre, at flere LUW'er (logiske arbejdsenheder/transaktioner) behandles i den tilsigtede rækkefølge, kan tRFC serialiseres ved hjælp af indgående og udgående køer – hvilket er derfra navnet "queued RFC".

Anvendes til:

• Udvidelse af transaktionel RFC med streng rækkefølge.
• Scenarier hvor en defineret behandlingssekvens er obligatorisk.
• Tilfælde hvor flere transaktioner skal behandles i en foruddefineret rækkefølge.

RFC-typesammenligning

Type	Venter den, der ringer op?	Pålidelig?	Bestilt?	Bedste For
sRFC	Ja	Ja	Ikke tilgængelig (enkelt opkald)	Opslag i realtid
aRFC	Ingen	Ingen	Ingen	Affyr-og-glem, parallelt arbejde
tRFC	Ingen	Ja (præcis én gang)	Ingen	Pålidelige asynkrone opdateringer
qRFC	Ingen	Ja (præcis én gang)	Ja	Strengt ordnede opdateringer

Typer af RFC-forbindelser

SM59 understøtter adskillige forbindelsestyper. De tre, du oftest vil støde på, er opsummeret nedenfor.

Type 3 — ABAP-til-ABAP

Type 3-poster angiver forbindelsen mellem ABAP systemerVærtsnavnet eller IP-adressen er obligatorisk; logonoplysninger kan angives valgfrit. Type 3 gælder både for RFC'er mellem ABAP-systemer og for eksterne kald til ABAP-systemer.

Type I — Peer i samme database

Type I-poster angiver ABAP-systemer, der deler den samme database som det aktuelle system. Disse poster er foruddefinerede og kan ikke ændres. Et typisk postnavn ser sådan ud ws0015_K18_24:

• ws0015 — værtsnavn
• K18 — systemnavn (databasenavn)
• 24 — TCP-tjenestenavn

Type T — Eksternt program

Type T-destinationer opretter forbindelse til eksterne programmer, der bruger RFC API'en til at modtage RFC'er. Aktiveringstypen kan være enten Starten or RegistreringHvis det er Start, skal værtsnavnet og stien til det program, der skal startes, angives.

Hvordan man Code en RFC

Den komplette opbygning af en RFC har fem trin. De første tre er mekaniske klik i SE37 og SM59; de sidste to handler om at få adgang til con'en.tracikke rigtigt.

Trin 1: I funktionsmodulets attributfaneblad for transaktionen SE37, indstil behandlingstypen til Fjernaktiveret modul for at markere funktionsmodulet som RFC-kompatibelt.

Trin 2: Skriv koden til funktionsmodulet i kildekodeeditoren.

Trin 3: Definer destinationen for RFC-serveren i RFC-klientsystemet, der kalder fjernfunktionen — udført i transaktionen SM59.

Trin 4 — Deklarering af parametre: Alle parameterfelter for et fjernfunktionsmodul skal defineres som referencefelter – dvs. indtastes i ABAP Dictionary-felter. Værdiparametre er ikke tilladt for fjernaktiverede funktionsmoduler.

Trin 5 — Undtagelser: Systemet hæver KOMMUNIKATIONSFEJL og SYSTEMFEJL internt ved fejl på transportniveau. Undtagelser på applikationsniveau kan oprettes i en fjernfunktion præcis som i en lokal.

Fejlfinding af fjernfunktionsopkald

• Det er ikke muligt at fejlfinde et fjerntliggende funktionskald til et ikke-ABAP-system på den klassiske måde - den fremmede runtime er uigennemsigtig.
• Ved ABAP-til-ABAP RFC-kald kan ABAP-debuggeren dog bruges til at overvåge udførelsen af ​​RFC-funktionen i det eksterne system.
• Med fjernkald kører ABAP-debuggeren (inklusive dens brugergrænseflade) på det lokale system. Dataværdier og andre runtime-oplysninger for fjernfunktionen streames tilbage fra fjernsystemet.

Nøgle SAP RFC-transaktioner

Den daglige RFC-værktøjskasse koger ned til en håndfuld T-koder, som enhver ABAP-udvikler og Basis-administrator bør kende uden videre.

T-kode	Formål
SM59	Vedligehold RFC-destinationer — vært, logon, type, sikkerhed.
SE37	Funktionsbygger — opret eller rediger fjernaktiverede funktionsmoduler.
SM58	Overvåg mislykkede transaktionelle RFC'er og genbehandl dem.
SMQ1 / SMQ2	Overvåg udgående (SMQ1) og indgående (SMQ2) qRFC-køer.
STØR	Vedligehold SSL-certifikater, der bruges af HTTPS-beskyttede RFC-destinationer.
ST22	Undersøg korte dumps forårsaget af mislykkede fjernopkald.

Bedste praksis for SAP RFC

Et veldesignet RFC-lag holder integrationer hurtige, observerbare og nemme at udvikle. Følgende vaner er værd at integrere i ethvert projekt.

• Vælg den rigtige variant til ulempentract. Brug sRFC til synkrone opslag, tRFC til asynkrone opdateringer med højst én gang, og qRFC til rækkefølge af opgaver.
• Genbrug én destination pr. målsystem i stedet for at sprede værtsnavne på tværs af mange destinationer — det skaber rotation af legitimationsoplysninger tractabel.
• Hardkode aldrig legitimationsoplysninger i ABAP. Brug pålidelige systemforbindelser eller sikre logon-sager, hvor det er muligt.
• Overvåg SM58 og SMQ2 rutinemæssigt. Fastsiddende tRFC-poster forsinker lydløst forretningsprocesser, indtil de genbehandles.
• Send kun reference-typede parametre. Værdiparametre afbryder fjernaktiverede funktionsmoduler.
• Brug STRUST til at administrere TLS-certifikater For HTTPS-destinationer er udløbne certifikater en af ​​de primære årsager til mystiske COMMUNICATION_FAILURE-dumps.

Ofte Stillede Spørgsmål