Fjärrfunktionsanrop (RFC) in SAP ABAP handledning

Vad är RFC i SAP?

RFC står för FjärrfunktionsanropDet är den mekanism som gör det möjligt för affärsapplikationer att kommunicera och utbyta information – i fördefinierade format – med andra system. RFC är det vanligaste sättet att SAP systemet pratar med ett annat, och det är också bryggan som förbinder SAP system till icke-SAP tillämpningar.

RFC erbjuder två gränssnitt:

1. Ett samtalsgränssnitt för ABAP-program.
2. Ett samtalsgränssnitt för icke-SAP program.

Alla ABAP-program kan anropa en fjärrfunktion med hjälp av SAMTALSFUNKTION...DESTINATION påstående. De DESTINATION parametern talar om för SAP system som den anropade funktionen körs på ett annat system än den anropande.

syntax

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

Logiska destinationer definieras via transaktion SM59 och lagras i tabellen RFCDES.

RFC-gränssnittets funktioner

RFC-körtiden ansvarar för tre saker vid varje anrop:

• Konverterar all parameterdata till den representation som förväntas av fjärrsystemet.
• Ringer upp de kommunikationsrutiner som behövs för att prata med fjärrsystemet.
• Hantera kommunikationsfel och rapportera dem till uppringaren via EXCEPTIONS parameter för CALL FUNCTION.

RFC är SAP protokoll som hanterar kommunikation mellan system och förenklar relaterad programmering. Det är processen att anropa en funktionsmodul som finns på en annan maskin än det anropande programmet. RFC:er kan tekniskt sett användas för att anropa en funktionsmodul på Samma maskin, men de används oftast när det anropande och det anropade programmet körs på separata maskiner. RFC-gränssnittssystemet används för att upprätta RFC-anslutningar mellan olika SAP system, liksom mellan SAP och externa (icke-SAP) system.

Detaljer som du måste veta om RFC

• SAP använder CPIC protokoll (Common Programming Interface for Communication) för att överföra data mellan system. CPIC är SAP-specifik. RFC är ett kommunikationsgränssnitt byggt ovanpå CPI-C, men med fler funktioner och en vänligare yta för applikationsprogrammerare.
• RFC-bibliotekets funktioner stöder C programmeringsspråk och Visual Basic på Windows plattformar.
• RFC-anslutningar fungerar över hela systemet. En RFC-anslutning definierad i klient 000 kan även användas från klient 100 utan någon skillnad.
• RFC är protokollet för att anropa specialiserade subrutiner (funktionsmoduler) över nätverket. Funktionsmoduler är jämförbara med C-funktioner eller Pascal-procedurer: de exponerar ett definierat gränssnitt genom vilket data, tabeller och returkoder utbyts. Funktionsmoduler hanteras inuti SAP systemet i ett dedikerat bibliotek, Funktionsbyggare.
• Funktionsbyggaren (transaktion SE37) ger applikationsprogrammerare en miljö för att skriva, dokumentera och testning funktionsmoduler som kan anropas lokalt såväl som på distans. Systemet genererar automatiskt den extra koden (den RFC-stub) behövs för fjärrsamtal.
• RFC-anslutningar underhålls med hjälp av transaktioner SM59. SAP skickar även en RFC-SDK (Software Development Kit) som använder omfattande C-bibliotek så att externa program kan ansluta till SAP systemet.
• Den enda skillnaden mellan ett fjärranrop till en annan server och ett lokalt anrop är DESTINATION parameter, som anger vilken målserver programmet ska köras på.

Fördelar med RFC

RFC minskar programmeringsarbetet genom att ta bort behovet av att implementera moduler och metoder på nytt på distans. RFC-lagret tar hand om:

• Konvertera data till ett format som fjärrsystemet (målsystemet) kan förstå.
• Anropa rutinerna som behövs för att upprätta kommunikation med fjärrsystemet.
• Hantera fel som uppstår under kommunikationen.
• Tillhandahåller tillförlitlig transaktionell semantik när transaktionella eller köade varianter används.

Typer av RFC

SAP stöder fyra RFC-varianter. Var och en erbjuder en annan avvägning mellan latens, tillförlitlighet och ordningsgarantier.

1. Synckronisk RFC (sRFC)

SyncChronous RFC kräver att både klienten och servern är tillgängliga vid anropstillfället. Det är den vanligaste typen och används när anroparen behöver resultatet omedelbart efter exekvering.

sRFC är ett kommunikationsmedel mellan system där bekräftelser förväntas. Källsystemets resurser väntar på målsystemet och säkerställer att meddelandet anländer med en bekräftelse. De utväxlade uppgifterna är konsekventa och tillförlitliga.

Nackdelen är att om målsystemet inte är tillgängligt väntar källsystemresurserna tills det kommer tillbaka, vilket kan försätta källsystemprocesser i viloläge/RFC/CPIC-läge på målsystemet och blockera resurser.

Används för:

• Realtidskommunikation mellan system.
• Kommunikation mellan SAP Webbapplikationsservern och SAP GUI.

2. Asynkron RFC (aRFC)

Asynkron RFC är kommunikation mellan system där ingen bekräftelse krävs – jämförbart med droppping ett vykort med posten. Båda systemen behöver inte vara tillgängliga vid tidpunkten för exekveringen, och resultatet returneras inte omedelbart till det anropande systemet.

Källsystemresursen väntar inte på målsystemet; den levererar data och går vidare. Detta gör aRFC snabb men inte tillförlitlig i sig själv – data kan gå förlorade om målsystemet inte är tillgängligt.

Används för:

• Avfyrnings-och-glöm-kommunikation mellan system.
• Parallell bearbetning över system.

3. Transaktionell RFC (tRFC)

Transaktionell RFC är en speciell form av asynkron RFC. Den säkerställer transaktionsliknande hantering av bearbetningssteg som annars skulle vara autonoma.

tRFC exekverar den anropade funktionsmodulen på RFC-servern exakt en gång, även om data skickas flera gånger på grund av nätverksproblem. Fjärrsystemet behöver inte vara tillgängligt just då RFC-klienten kör anropet. tRFC-komponenten lagrar den anropade funktionen och dess data i SAP databas under en unik Transaktions-ID (TID)Om målsystemet inte är tillgängligt skrivs data in i RFC-tabeller (synliga i transaktionsfältet). SM58) och senare upptäckt av schemaläggarrapporten RSARFCSE, som körs var 60:e sekund.

Används för:

• Utökar asynkron RFC med leverans högst en gång.
• Tillförlitlig kommunikation mellan system där exakt engångskörning är viktig.

4. Köad RFC (qRFC)

Queued RFC utökar tRFC genom att garantera att enskilda steg bearbetas i den ordning som anges av den anropande applikationen. För att säkerställa att flera LUW:er (logiska arbetsenheter/transaktioner) bearbetas i avsedd ordning kan tRFC serialiseras med hjälp av inkommande och utgående köer – vilket är därifrån namnet "queued RFC" kommer.

Används för:

• Utöka transaktionell RFC med strikt ordning.
• Scenarier där en definierad bearbetningssekvens är obligatorisk.
• Fall där flera transaktioner måste behandlas i en förutbestämd ordning.

Jämförelse av RFC-typer

Typ	Väntar den som ringer?	Pålitlig?	Beställd?	bäst för
sRFC	Ja	Ja	Ej tillämpligt (enkelsamtal)	Uppslagningar i realtid
aRFC	Nej	Nej	Nej	Eld-och-glöm, parallellt arbete
tRFC	Nej	Ja (exakt en gång)	Nej	Tillförlitliga asynkrona uppdateringar
qRFC	Nej	Ja (exakt en gång)	Ja	Strikt ordnade uppdateringar

Typer av RFC-anslutningar

SM59 stöder flera anslutningstyper. De tre du kommer att stöta på oftast sammanfattas nedan.

Typ 3 — ABAP-till-ABAP

Typ 3-poster anger kopplingen mellan ABAP-systemVärdnamnet eller IP-adressen är obligatorisk; inloggningsinformation kan anges valfritt. Typ 3 är tillämplig både för RFC:er mellan ABAP-system och för externa anrop till ABAP-system.

Typ I — Peer med samma databas

Typ I-poster anger ABAP-system som delar samma databas som det aktuella systemet. Dessa poster är fördefinierade och kan inte ändras. Ett typiskt postnamn ser ut så här ws0015_K18_24:

• ws0015 — värdnamn
• K18 — systemnamn (databasnamn)
• 24 — TCP-tjänstnamn

Typ T — Externt program

Typ T-destinationer ansluter till externa program som använder RFC API för att ta emot RFC:er. Aktiveringstypen kan vara antingen Start or RegistreringOm det är Start måste värdnamnet och sökvägen för det program som ska startas anges.

Hur man Code en RFC

Hela byggandet av en RFC har fem steg. De tre första är mekaniska klick i SE37 och SM59; de två sista handlar om att få fram nackdelarna.tracinte rätt.

Steg 1: I funktionsmodulens attributfliken för transaktionen SE37, ställ in bearbetningstypen till Fjärraktiverad modul för att markera funktionsmodulen som RFC-kompatibel.

Steg 2: Skriv koden för funktionsmodulen i källkodsredigeraren.

Steg 3: Definiera destinationen för RFC-servern i RFC-klientsystemet som anropar fjärrfunktionen — utfört i transaktionen SM59.

Steg 4 — Deklarera parametrar: Alla parameterfält för en fjärrstyrd funktionsmodul måste definieras som referensfält – det vill säga skrivs mot ABAP Dictionary-fält. Värdeparametrar är inte tillåtna för fjärrstyrda funktionsmoduler.

Steg 5 — Undantag: Systemet höjer KOMMUNIKATIONSFEL och SYSTEMFEL internt vid fel på transportnivå. Undantag på applikationsnivå kan genereras inuti en fjärrfunktion precis som i en lokal.

Felsökning av fjärrfunktionsanrop

• Det är inte möjligt att felsöka ett fjärrfunktionsanrop till ett icke-ABAP-system på klassiskt sätt — den främmande runtime-miljön är ogenomskinlig.
• För ABAP-till-ABAP RFC-anrop kan dock ABAP-felsökaren användas för att övervaka körningen av RFC-funktionen inuti fjärrsystemet.
• Med fjärranrop körs ABAP-felsökaren (inklusive dess användargränssnitt) på det lokala systemet. Datavärden och annan körtidsinformation för fjärrfunktionen strömmas tillbaka från fjärrsystemet.

Nyckel SAP RFC-transaktioner

Den dagliga RFC-verktygslådan kokar ner till en handfull T-koder som varje ABAP-utvecklare och Basis-administratör bör känna till på reflexen.

T-kod	Syfte
SM59	Underhåll RFC-destinationer — värd, inloggning, typ, säkerhet.
SE37	Funktionsbyggare — skapa eller redigera fjärraktiverade funktionsmoduler.
SM58	Övervaka misslyckade transaktionella RFC:er och bearbeta dem igen.
SMQ1 / SMQ2	Övervaka utgående (SMQ1) och inkommande (SMQ2) qRFC-köer.
STRUST	Underhåll SSL-certifikat som används av HTTPS-skyddade RFC-destinationer.
ST22	Inspektera korta dumpningar orsakade av misslyckade fjärranrop.

Bästa metoder för SAP RFC

Ett väl utformat RFC-lager gör integrationer snabba, observerbara och enkla att utveckla. Följande vanor är värda att integrera i varje projekt.

• Välj rätt variant för nackdelentract. Använd sRFC för synkrona uppslagningar, tRFC för asynkrona uppdateringar som sker högst en gång och qRFC för att sortera ärenden.
• Återanvänd en destination per målsystem snarare än att sprida värdnamn över många destinationer — det gör att autentiseringsuppgifterna roteras tractabell.
• Hårdkoda aldrig inloggningsuppgifter i ABAP. Använd betrodda systemanslutningar eller säkra inloggningsbiljetter där det är möjligt.
• Övervaka SM58 och SMQ2 regelbundet. Fastnade tRFC-poster fördröjer tyst affärsprocesser tills de bearbetas om.
• Skicka endast referenstypade parametrar. Värdeparametrar bryter fjärraktiverade funktionsmoduler.
• Använd STRUST för att hantera TLS-certifikat för HTTPS-destinationer — utgångna certifikat är en av de främsta orsakerna till mystiska COMMUNICATION_FAILURE-dumpar.

Vanliga frågor