Abap blog, apel de la distanță

Remote Call Call (RFC) este o interfață standard pentru schimbul de date între sistemele SAP și non-SAP. Interfața de transfer de date se bazează pe CPI-C sau TCP / IP. Referință standard asupra subiectului RFC sau curs BC415.







Caracteristicile funcțiilor RFC

  • Când apelați FM local, funcționează în același flux de lucru ca și programul de apelare. Dacă sunați de la distanță de la FM, acesta începe într-un flux de lucru separat (LER - LUW, unitate logică de lucru) dacă sistemul de la distanță este un sistem R / 3.
  • Deoarece sistemele de la distanță pot fi / 3 sistem R, sistemul R / 2 sau în afara altor nici un sistem SAP pentru sisteme non-SAP există o bibliotecă specială RFC-SDK, prin care poate fi pus în aplicare RFC client-server.
  • Când apelați modulul RFC, programul solicită comanda DB implicită (cu excepția tRFC, qRFC, bgRFC). Prin urmare, apelurile RFC nu ar trebui să fie între operatorii OpenSQL.
  • În interfața FM RFC, este necesar să se definească explicit tipul pentru fiecare parametru, referințele (LIKE) sunt interzise.

Alocarea apelurilor RFC

Apelul RFC este definit folosind cuvântul cheie DESTINATION. Ca parametru, poate lua numele sistemului la distanță, SPACE, NONE, BACK.

  • SPACE - apel local FM (implicit). Dacă nu specificați DESTINAȚIA în parametrii apelului RFC, funcția va fi executată local, ca de obicei, fără a crea propriul LUW.
  • NU - Lansarea este de asemenea locală, principala diferență fiind că apelul ajunge la poarta specificată în setări și este înregistrată ca apel la distanță. DB LUW dvs. este creat.
  • BACK - utilizate în interiorul funcțiilor RFC sincrone, pentru a lansa funcțiile RFC în sistemul care le-a denumit.

Manipularea excepțiilor pentru apelurile RFC

Când apelați modulul RFC, pot apărea următoarele excepții:

  • COMMUNICATION_FAILURE - apare atunci când conexiunea pentru sistemul specificat nu este configurată în câmpul DESTINAȚIE sau când conexiunea nu a putut fi stabilită.
  • SYSTEM_FAILURE - apare dacă modulul apelat nu există pe sistemul la distanță sau în cazul altor probleme în apelurile RFC.
  • RESOURCE_FAILURE - apare când sunați RFC-uri asincrone, dacă nu există resurse disponibile pe serverul de aplicații al grupului.

Tipuri de funcții RFC:

  1. SincronizareRFC (sRFC) - când sRFC este apelat, fluxul de lucru își suspendă funcționarea, până când modulul sRFC este executat. Modulul este executat într-un DB LUW separat.

În cazul în care numiți mai multe sRFC succesiv dintr-un grup de funcții, datele globale ale grupului de funcții vor fi disponibile până când va fi apelată ultima funcție din grupul dat.

În cazul în care SRFC în sine provoacă CALL SCREEN, CALL TRANZACȚII, sau a afișa o listă cauzată de ecranele vor fi afișate în programul va începe SRFC, dar numai în cazul în care SM59 Set de acces la distanță interactiv, în caz contrar sistemul va arunca o SYSTEM_FAILURE excepție.

  1. Apeluri AsynchronousRFC (aRFC) - funcția de la distanță începe să funcționeze în paralel imediat după apel, în timp ce fluxul de lucru nu își suspendă activitatea. Un apel asincron este declanșat atunci când apelul FM este apelat cu cuvintele cheie: PORNIRE NOUĂ PERSONALĂ <ИмяЗадачи>. Modulul este executat într-un DB LUW separat. aRFC poate fi de asemenea utilizat în execuția de fundal.

Pentru a obține rezultatele lucrării aRFC, trebuie să specificați procedura de procesare a rezultatelor atunci când o apelați, este specificată utilizând cuvântul cheie: PERFORMING <ИмяПроцедуры> La sfarsitul sarcinii. Procedura ca primul parametru trebuie să conțină o variabilă la care se va scrie numele sarcinii (numele acestei variabile nu contează). Pentru a obține date de la aRFC, în interiorul acestei proceduri este utilizată o comandă obligatorie (dacă nu este specificată în procedură, sistemul va arunca o excepție - COMMUNICATION_FAILURE): RECEIVE RESULTS FROM FUNCTION <ИмяARFC>, cu parametrii IMPORTARE, TABLURI, EXCEPȚII care vor fi transferate din aRFC.

Procedura nu trebuie să aibă întreruperi în execuția programului în corpul tău, cum ar fi: CALL SCREEN, SUBMIT, COMMIT WORK, WAIT, apeluri RFC, mesaje cu tipuri W și I.







Pentru a aștepta apelurile aRFC, există cuvântul cheie WAIT UNTIL <Условие>. Dacă condiția este îndeplinită după apelul aRFC, programul începe imediat după WAIT UNTIL. Dacă nu, programul verifică din nou starea. Acest proces se repetă până când condiția este îndeplinită sau dacă sunt îndeplinite toate apelurile aRFC.

Un exemplu de program care pornește două funcții aRFC și așteaptă ambele:

aRFC, precum și sRFC pot apela dialoguri în interiorul lor, dar utilizarea lor în acest context pare îndoielnică, este discutată mai detaliat în curs (BC415).

Toate apelurile tRFC sunt stocate în tabele: ARFCSSTATE și ARFCSDATA. Dacă nu doriți să apelați tRFC imediat după COMMIT muncă, puteți apela FM START_OF_BACKGROUNDTASK (doCOMMITWORK) și setați ora și data de începere a acumulat tRFC apeluri.

După executarea lucrării COMMIT WORK în cazul unei actualizări locale de succes (în LUW a programului principal), datele acumulate creează o sarcină de fundal, dacă această activitate este finalizată cu succes, toate datele din tabelele tRFC sunt șterse. Dacă sarcina nu a fost finalizată, se declanșează mecanismul de reîncercare sau de returnare.

De exemplu, dacă conexiunea la sistemul de la distanță nu a fost stabilită, lucrarea este reluată automat. În mod implicit, numărul de repetări este de 30, intervalul de așteptare este de 15 minute.

În cazul în care a doua dintre cele două apeluri tRFC eșuează, un mesaj cu tipul A sau X sau o excepție a apelului prin RAISE după executarea cu succes a primei apare:

  • Toate modificările efectuate în actualul LUW (și acesta este cel din toate tRFC-urile) sunt redate înapoi
  • A scrie în jurnalul de apeluri tRFC (a se vedea SM58)

Pentru a forța revocarea tuturor modificărilor sau pentru a anula tRFC-LUW, FM-RESTART_OF_BACKGROUNDTASK servește.

Dacă apar apeluri tRFC pe diferite sisteme (destinație „A“, DESTIONATION „B“), pentru fiecare dintre ele creează un apeluri tRFC-LUW, tRFC sunt grupate în funcție de scopul.

Pentru a apela tRFC separat de restul, puteți utiliza cuvântul cheie: AS SEPARATE UNIT.

Fiecare tRFC-LUW are propriul său ID unic, pentru a-l primi puteți folosi FM: ID_OF_BACKGROUNDTASK (apelați înainte de COMMIT WORK). Folosind acest ID, poți determina starea pentru tRFC-LUW prin FM - STATUS_OF_BACKGROUNDTASK.

  1. Funcțiile qRFC-RFC efectuate în ordinea coadajului. Când utilizați tRFC nu putem controla ordinea de pornire modulul tRFC, cu alte cuvinte, ordinea apelului lor nu se poate compara cu ordinea în care le conduc. qRFC, spre deosebire de tRFC, ne permite să controlam ordinea lansării lor.

Pentru a plasa apelurile tRFC în ordinea FIFO (primul venit, primul venit), trebuie să specificați numele coadă înainte de fiecare apel tRFC folosind funcția FM: TRFC_SET_QUEUE_NAME:

Numele coada poate conține 24 de caractere, cu excepția% și *.

Pentru a administra qRFC, se utilizează tranzacția SMQ1 în loc de tranzacția SM58. Tabelul în care sunt stocate datele qRFC-TRFCQOUT.

Mai multe informații despre bgRFC sunt aici.

Tranzacțiile utilizate în relația cu RFC

Funcțiile BAPI

Pentru a face schimb de date de afaceri, între sistemele SAP și non-SAP, a fost creat așa-numitul Business Framework. Partea sa centrală este depozitul de obiecte de afaceri (BOR). Fiecare obiect de afaceri oferă o abordare orientată pe obiecte pentru stocarea datelor de afaceri și lucrul cu procesele de afaceri. De exemplu, prin apelarea metodelor obiectului de afaceri, manipulăm astfel datele de afaceri pentru care răspunde fără a se îngriji de problema tehnică (link-uri în tabele etc.)

Obiectul de activitate constă în următoarele părți:

  • Date tehnice - numărul intern, numărul de eliberare al sistemului SAP cu care este disponibil, etc.
  • Lista interfețelor pe care le acceptă obiectul - interfața definește structura comportamentală a obiectului
  • Câmpurile cheie sunt atribute care identifică un obiect unic. (Numărul comenzii de achiziție)
  • Atribute - pot fi fie câmpuri din baza de date, fie trimiteri la alte obiecte calculate în timpul lucrului cu obiectul (cele virtuale) (Obiectul de activitate "Comanda de aprovizionare", de exemplu, poate avea link-uri către obiecte de livrare primite)
  • Metodele sunt apeluri către tranzacții R / 3, module funcționale sau alte coduri ABAP. BAPI reprezintă doar punerea în aplicare a metodelor obiectului de afaceri.
  • Evenimente - utilizate în principal în Workflow. De exemplu, efectuați o trimitere către furnizori atunci când creați o comandă de achiziție.

BAPI - implementarea metodei obiect de afaceri, este un modul funcțional al RFC. BAPI pot fi numite atât sincron (COMMIT WORK ANDWAIT), cât și asincron, adică așteptând ca funcția să funcționeze sau nu.

BAPI pot reprezenta diferite acțiuni asupra unui obiect:

  • Creați un obiect
  • Solicitarea de atribute ale obiectelor
  • Schimbarea atributelor unui obiect

BAPI poate fi apelat din diverse aplicații: aplicații de birou (prin VBA), programe JAVA și C ++ etc.

Toate BAPI după operația lui returnează un tabel intern cu una dintre structurile: BAPIRETURN, BAPIRETURN1, BAPIRET1, BAPIRET2, BAPIRET1_FIX. În acest sens, BAPI nu se ocupă de tratarea excepțiilor în FM standard. Toate aceste structuri conțin următoarele câmpuri:

  • TYPE este tipul mesajului: S (uccess), E (rror), W (arning), I (nformation)
  • ID (clasa mesajelor)
  • NUMBER (numărul de mesaj din clasă)
  • MESAJ (corpul mesajului)
  • MESSAGE_V1, MESSAGE_V2, MESSAGE_V3, MESSAGE_V4 (variabile de mesaj)

Dacă tranzacția are succes, nu vor fi înregistrate în tabelul RETURN un tip de eroare "E". Trebuie să existe un mesaj cu tipul de eroare "S".

Cursul, care ia în considerare crearea propriului BAPI - BC417.

Navigare după înregistrări







Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: