Apel de funcție de la distanță (RFC) în SAP Tutorial ABAP

⚡ Rezumat inteligent

Apelul de funcție la distanță (RFC) este SAP mecanism de comunicare care permite unui program ABAP să invoce un modul de funcții care rulează pe un alt site SAP sau sistem extern. Se absoarbetracVerifică instalațiile sanitare ale rețelei, convertește formatele de date și raportează defecțiunile apelantului în mod clar.

  • 📡 Mecanism de bază: CALL FUNCTION…DESTINATION invocă un modul de funcții pe o destinație logică definită în SM59.
  • 🔁 Patru variante: SyncRFC-urile acronice, asincrone, tranzacționale și puse în coadă garantează fiecare condiții de livrare diferite.tract.
  • 🌐 Tipuri de conectare: SM59 acceptă Tipul 3 (ABAP-to-ABAP), Tipul I (conectări cu aceeași bază de date) și Tipul T (programe externe).
  • 🛠️ Calea de construcție: Setați modulul funcțional la Activat de la distanță în SE37, codați-l și definiți destinația în SM59 pe apelant.
  • 🤖 Unghiul AI: Asistenții inteligenți artificiali generează exemple de RFC ABAP din specificații în limbaj natural și analizează erorile SM58 în remedieri acționabile.

Funcțiile interfeței RFC

Ce este RFC în SAP?

RFC standuri pentru Apel de funcție la distanțăEste mecanismul care permite aplicațiilor de business să comunice și să facă schimb de informații — în formate predefinite — cu alte sisteme. RFC este cea mai comună modalitate prin care se SAP sistem comunică cu altul și este, de asemenea, puntea care conectează SAP sisteme către non-SAP aplicatii.

RFC oferă două interfețe:

  1. O interfață de apelare pentru programe ABAP.
  2. O interfață de apel pentru persoane care nu suntSAP programe.

Orice program ABAP poate invoca o funcție la distanță folosind FUNCȚIE DE APEL...DESTINATIE afirmație. The DESTINATION parametrul spune SAP sistem pe care funcția apelată îl rulează pe un sistem diferit de cel al apelantului.

Sintaxă

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

Destinațiile logice sunt definite prin tranzacții SM59 și stocate în tabel RFCDES.

Funcțiile interfeței RFC

Funcțiile interfeței RFC

Timpul de execuție RFC este responsabil pentru trei lucruri la fiecare apel:

  • Conversia tuturor datelor parametrilor în reprezentarea așteptată de sistemul la distanță.
  • Apelarea rutinelor de comunicare necesare pentru a vorbi cu sistemul de la distanță.
  • Gestionarea erorilor de comunicare și semnalarea acestora apelantului prin intermediul EXCEPTIONS parametrul de CALL FUNCTION.

Comunicare RFC între SAP sisteme

RFC este SAP protocol care gestionează comunicarea între sisteme și simplifică programarea aferentă. Este procesul de apelare a unui modul funcțional care se află pe o mașină diferită de programul apelant. RFC-urile pot fi utilizate din punct de vedere tehnic pentru a apela un modul funcțional pe acelaşi mașină, dar sunt cel mai adesea utilizate atunci când programele apelante și apelate rulează pe mașini separate. Sistemul de interfață RFC este utilizat pentru a configura conexiuni RFC între diferite SAP sisteme, precum și între SAP și extern (ne-SAP) sisteme.

Detalii esențiale despre RFC

  • SAP folosește CPIC protocol (Common Programming Interface for Communication - Interfață comună de programare pentru comunicare) pentru transferul de date între sisteme. CPIC este SAPspecific. RFC este o interfață de comunicații construită pe baza CPI-C, dar cu mai multe funcții și o suprafață mai prietenoasă pentru programatorii de aplicații.
  • Funcțiile bibliotecii RFC acceptă limbaj de programare C și Visual Basic pe Windows platforme.
  • Conexiunile RFC funcționează în întregul sistem. O conexiune RFC definită în clientul 000 poate fi utilizată și de la clientul 100, fără nicio diferență.
  • RFC este protocolul pentru apelarea subrutinelor specializate (module funcționale) prin rețea. Modulele funcționale sunt comparabile cu funcțiile C sau procedurile Pascal: ele expun o interfață definită prin care se schimbă date, tabele și coduri de retur. Modulele funcționale sunt gestionate în interiorul SAP sistem într-o bibliotecă dedicată, Creator de funcții.
  • Constructorul de funcții (tranzacție SE37) oferă programatorilor de aplicații un mediu pentru scrierea, documentarea și de testare module funcționale care pot fi apelate atât local, cât și de la distanță. Sistemul generează automat codul suplimentar ( RFC stub) necesar pentru apeluri la distanță.
  • Conexiunile RFC sunt menținute folosind tranzacții SM59. SAP livrează, de asemenea, un SDK-ul RFC (Kit de dezvoltare software) care utilizează biblioteci C extinse, astfel încât programele externe se pot conecta la SAP sistemului.
  • Singura diferență dintre un apel la distanță către un alt server și un apel local este DESTINATION parametru, care specifică serverul țintă pe care ar trebui să se execute programul.

Avantajele RFC

RFC reduce efortul de programare prin eliminarea necesității de a reimplementa module și metode la capătul distant. Nivelul RFC se ocupă de:

  • Conversia datelor într-un format pe care sistemul la distanță (țintă) îl poate înțelege.
  • Apelarea rutinelor necesare pentru configurarea comunicării cu sistemul la distanță.
  • Gestionarea erorilor care apar în timpul comunicării.
  • Furnizarea unei semantici tranzacționale fiabile atunci când se utilizează variante tranzacționale sau în coadă.

Tipuri de RFC

Tipuri de RFC

SAP suportă patru variante RFC. Fiecare dintre ele oferă un compromis diferit între latență, fiabilitate și garanții de ordonare.

1. SyncRFC cronologic (sRFC)

SyncRFC-ul chronous necesită ca atât clientul, cât și serverul să fie disponibile în momentul apelului. Este cel mai comun tip și este utilizat ori de câte ori apelantul are nevoie de rezultat imediat după execuție.

sRFC este un mijloc de comunicare între sisteme unde se așteaptă confirmări de primire. Resursele sistemului sursă așteaptă sistemul țintă și se asigură că mesajul ajunge cu un ACK. Datele schimbate sunt consistente și fiabile.

Dezavantajul este că, dacă sistemul țintă nu este disponibil, resursele sistemului sursă așteaptă până când acesta revine, ceea ce poate împinge procesele sistemului sursă în modul Repaus/RFC/CPIC la sistemul țintă și poate bloca resursele.

Folosit pentru:

  • Comunicare în timp real între sisteme.
  • Comunicarea dintre SAP Serverul de aplicații web și SAP GUI.

2. RFC asincron (aRFC)

RFC asincron este o comunicare între sisteme unde nu este necesară nicio confirmare — comparabilă cu renunțarea la informații.ping o carte poștală prin poștă. Nu este necesar ca ambele sisteme să fie disponibile în momentul execuției, iar rezultatul nu este returnat imediat sistemului apelant.

Resursa sistemului sursă nu așteaptă sistemul țintă; aceasta livrează datele și merge mai departe. Acest lucru face ca aRFC să fie rapid, dar nu fiabil în sine - datele se pot pierde dacă sistemul țintă nu este disponibil.

Folosit pentru:

  • Comunicare de tip „declanșare și uitare” între sisteme.
  • Procesare paralelă între sisteme.

3. RFC tranzacțional (tRFC)

RFC tranzacțional este o formă specială de RFC asincron. Acesta asigură o gestionare similară tranzacțiilor a etapelor de procesare care altfel ar fi autonome.

tRFC execută modulul funcției apelate pe serverul RFC o singură dată, chiar dacă datele sunt trimise de mai multe ori din cauza unor probleme de rețea. Sistemul la distanță nu trebuie să fie disponibil în momentul în care clientul RFC execută apelul. Componenta tRFC stochează funcția apelată și datele sale în SAP bază de date sub o unică ID-ul tranzacției (TID)Dacă sistemul țintă nu este disponibil, datele sunt scrise în tabele RFC (vizibile în fișierele de tranzacții). SM58) și ulterior preluate de raportul planificatorului RSARFCSE, care rulează la fiecare 60 de secunde.

Folosit pentru:

  • Extinderea unui RFC asincron cu livrare maximă o dată.
  • Comunicare fiabilă între sisteme unde contează execuția unică.

4. RFC în coadă (qRFC)

RFC-ul plasat în coadă extinde tRFC-ul garantând că pașii individuali sunt procesați în secvența specificată de aplicația apelantă. Pentru a se asigura că mai multe LUW-uri (Unități Logice de Lucru / tranzacții) sunt procesate în ordinea dorită, tRFC-ul poate fi serializat folosind cozi de intrare și ieșire - de unde provine denumirea de „RFC plasat în coadă”.

Folosit pentru:

  • Extinderea RFC tranzacțional cu ordonare strictă.
  • Scenarii în care o secvență de procesare definită este obligatorie.
  • Cazuri în care mai multe tranzacții trebuie procesate într-o ordine predefinită.

Comparație tipuri RFC

Tip Apelantul așteaptă? De încredere? Ordonat? Cele mai bune
sRFC Da Da N/A (apel unic) Căutări în timp real
aRFC Nu Nu Nu Lucru paralel, de tipul „aprinde și uită”
tRFC Nu Da (exact o dată) Nu Actualizări asincrone fiabile
qRFC Nu Da (exact o dată) Da Actualizări strict ordonate

Tipuri de conexiuni RFC

Tipuri de conexiuni RFC

SM59 acceptă mai multe tipuri de conexiune. Cele trei pe care le veți întâlni cel mai des sunt rezumate mai jos.

Tipul 3 — ABAP-la-ABAP

Intrările de tip 3 specifică conexiunea dintre sisteme ABAPNumele gazdei sau adresa IP sunt obligatorii; informațiile de conectare pot fi furnizate opțional. Tipul 3 este aplicabil atât pentru RFC-uri între sisteme ABAP, cât și pentru apeluri externe către sisteme ABAP.

Tipul I — Peer din aceeași bază de date

Intrările de tip I specifică sisteme ABAP care partajează aceeași bază de date ca sistemul curent. Aceste intrări sunt predefinite și nu pot fi modificate. Un nume tipic de intrare arată astfel: ws0015_K18_24:

  • ws0015 — nume de gazdă
  • K18 — numele sistemului (bazei de date)
  • 24 — Numele serviciului TCP

Tipul T — Program extern

Destinațiile de tip T se conectează la programe externe care utilizează API-ul RFC pentru a primi RFC-uri. Tipul de activare poate fi fie acasă or ÎnscriereDacă este Start, trebuie furnizate numele gazdei și calea programului care va fi pornit.

Cum să Code un RFC

Construcția completă a unui RFC are cinci pași. Primii trei sunt clicuri mecanice în SE37 și SM59; ultimii doi se referă la obținerea con-ului.tracNu e corect.

Pasul 1: În fila de atribute a modulului funcțional al tranzacției SE37, setați tipul de procesare la Modul activat de la distanță pentru a marca modulul funcțional ca fiind compatibil cu RFC.

Modul SE37 activat de la distanță

Pasul 2: Scrieți codul pentru modulul funcțional în editorul de cod sursă.

Codul sursă al modulului de funcții

Pasul 3: Definiți destinația serverului RFC în sistemul client RFC care apelează funcția remote — se face în tranzacție SM59.

Configurarea destinației SM59

Pasul 4 — Declararea parametrilor: Toate câmpurile de parametri pentru un modul de funcții la distanță trebuie definite ca câmpuri de referință — adică, introduse în câmpurile Dicționarului ABAP. Parametrii de valoare nu sunt permiși pentru modulele de funcții activate la distanță.

Pasul 5 — Excepții: Sistemul ridică EȘEC_DE_COMUNICARE și EROARE_DE_SISTEM intern, în cazul erorilor la nivel de transport. Excepțiile la nivel de aplicație pot fi generate în interiorul unei funcții la distanță exact ca într-una locală.

Depanarea apelurilor de funcții de la distanță

  • Acesta este nu se poate depana un apel de funcție la distanță într-un sistem non-ABAP în mod clasic — timpul de execuție extern este opac.
  • Totuși, pentru apelurile RFC ABAP-to-ABAP, depanatorul ABAP poate fi utilizat pentru a monitoriza execuția funcției RFC în interiorul sistemului la distanță.
  • În cazul apelurilor la distanță, depanatorul ABAP (inclusiv interfața sa cu utilizatorul) rulează pe sistemul local. Valorile datelor și alte informații de execuție pentru funcția la distanță sunt transmise înapoi de la sistemul la distanță.

Cheie SAP Tranzacții RFC

Setul de instrumente RFC de zi cu zi se reduce la o mână de coduri T pe care fiecare dezvoltator ABAP și administrator Basis ar trebui să le cunoască din reflex.

Cod T Scop
SM59 Mențineți destinațiile RFC — gazdă, logon, tip, securitate.
SE37 Function Builder — creează sau editează module de funcții activate de la distanță.
SM58 Monitorizați RFC-urile tranzacționale eșuate și reprocesați-le.
SMQ1 / SMQ2 Monitorizați cozile qRFC de ieșire (SMQ1) și de intrare (SMQ2).
STRUST Mențineți certificatele SSL utilizate de destinațiile RFC protejate prin HTTPS.
ST22 Inspectați dump-urile scurte cauzate de apeluri la distanță eșuate.

Cele mai bune practici pentru SAP RFC

Un strat RFC bine conceput menține integrările rapide, observabile și ușor de evoluat. Următoarele obiceiuri merită integrate în fiecare proiect.

  • Alege varianta potrivită pentru înșelătorietract. Folosește sRFC pentru căutări sincrone, tRFC pentru actualizări asincrone de tip „cel mai o dată” și qRFC atunci când ordinea contează.
  • Reutilizați o destinație per sistem țintă în loc să răspândească numele de gazdă pe mai multe destinații — face ca rotația acreditărilor să fie mai eficientă tractabel.
  • Nu introduceți niciodată acreditări în cod hard în ABAP. Folosiți conexiuni de sistem de încredere sau tichete de conectare securizate, acolo unde este posibil.
  • Monitorizați SM58 și SMQ2 în mod curent. Intrările tRFC blocate întârzie în mod silențios procesele de business până când sunt reprocesate.
  • Transmiteți doar parametrii de tip referință. Parametrii de valoare întrerup modulele de funcții activate de la distanță.
  • Folosește STRUST pentru a gestiona certificatele TLS pentru destinațiile HTTPS — certificatele expirate sunt o cauză principală a dump-urilor misterioase de tip COMMUNICATION_FAILURE.

Întrebări frecvente

RFC este protocolul de nivel scăzut care apelează orice modul funcțional activat de la distanță. Un BAPI este un anumit, SAP-modul de funcții certificat care expune o metodă stabilă de tip obiect business — fiecare BAPI este expus prin RFC, dar nu fiecare apel RFC găsește un BAPI.

Un RFC de încredere este o destinație SM59 în care sistemul țintă are încredere în autentificarea apelantului, astfel încât nicio parolă nu este schimbată la fiecare apel. Contextul utilizatorului apelantului este propagat. Elimină acreditările codificate fix cu prețul unei configurări mai stricte.

SM58 afișează intrările RFC tranzacționale eșuate sau în așteptare, care așteaptă să fie reprocesate. Fiecare rând conține ID-ul tranzacției, modulul funcției apelate, destinația țintă, textul erorii și ora ultimei reîncercări.

Nu. În mod implicit, traficul RFC este necriptat. Destinațiile SNC (Secure Network Communications) sau TLS/HTTPS trebuie configurate pentru a cripta traficul. SNC este mecanismul standard pentru peisajele de producție.

tRFC garantează că un apel este executat exact o singură dată, dar nu păstrează ordinea între apeluri. qRFC se bazează pe tRFC și, în plus, serializează apelurile prin cozi de intrare sau ieșire, astfel încât apelurile să ruleze în secvența exactă definită de aplicație.

Da. Programele externe se pot înregistra împotriva unui SAP gateway folosind RFC SDK (JCo pentru Java, NCo pentru .NET sau SDK-ul C). SAP apoi le apelează printr-o destinație de tip T la fel ca orice modul de funcții ABAP.

Asistenții inteligenți artificiali generează fișiere RFC ABAP din specificații în limbaj natural, propun tipul de destinație potrivit pentru un scenariu și traduc textul erorii SM58 într-o listă de remedieri concrete — accelerând munca de integrare zilnică pentru echipele Basis și ABAP.

Da. Transmiteți unui asistent AI eroarea ST22 sau SM58, iar acesta corelează tiparele COMMUNICATION_FAILURE / SYSTEM_FAILURE cu cele mai probabile cauze principale — certificat expirat, gateway nefuncțional, autorizare lipsă — și sugerează codul T relevant de inspectat.

Rezumați această postare cu: