SAP PI pentru începători

obiectiv

Obiectivul acestui tutorial este de a vă face să înțelegeți – ce este integrarea procesului SAP? Nu vom intra în nitty-curajos a subiectului, dar vom discuta despre arhitectura și diferite caracteristici ale SAP PI. Vom acoperi doar caracteristicile de bază și vom evita discutarea tuturor caracteristicilor din acest tutorial.

în continuare există un set de studii de caz care vă vor oferi o idee despre utilizarea la nivel de industrie a SAP PI. Odată ce vă familiarizați mai mult cu subiectul, ar trebui să încercați să le rezolvați. Cazurile de testare sunt pregătite într-o manieră astfel încât să vă ducă în jos în subiect de la simplu la mai multe complexe cu fiecare lecție și vă va oferi o idee generală a subiectului.

ce este SAP ERP?

pentru orice afacere – mare sau mică, acestea sunt funcționalitățile standard de afaceri pe care trebuie să le îndeplinească, adică gestionarea materialelor, vânzări și distribuție, finanțe, resurse umane etc. Există multe software-uri pe piață care sunt utilizate de industrie. Veți observa cea mai simplă – bancomatul care generează factură de vânzare dacă vizitați un mic magazin la o rețea de calculatoare dintr-un magazin mare de vânzare cu amănuntul, hotel etc. care funcționează pe un ERP.

planificarea resurselor întreprinderii, adică ERP este o abordare eficientă pe care majoritatea întreprinderilor o implementează pentru a-și spori productivitatea și performanța. SAP ERP este planificarea resurselor întreprinderii SAP AG, o soluție software integrată care încorporează funcțiile cheie de afaceri ale organizației. Funcționalitățile de bază, adică HR, MM, SD, FICO etc., se numesc module de afaceri în SAP. SAP le construiește ca produse și le vinde pe piață. Există încă două module care nu acceptă direct funcțiile de afaceri, dar sunt utilizate pentru prezentare și integrare. Primul se numește EP (Enterprise Portal), iar cel de-al doilea se numește PI (Process Integration). Toate modulele de afaceri sunt dezvoltate în ABAP, în timp ce EP și PI sunt dezvoltate mai ales în Java. Aceste module nu sunt executabile, dar trebuie să fie implementate într-un server de aplicații, adică server de aplicații web ABAP pentru module ABAP și servere de aplicații Web Java pentru module Java.

există câteva puncte pe care ar trebui să le cunoaștem înainte de a sări în subiect.

• SAP reprezintă sisteme, aplicații și produse în prelucrarea datelor.

• SAP AG este o corporație germană multinațională de software care produce software pentru întreprinderi pentru a gestiona operațiunile de afaceri și relațiile cu clienții. SAP ERP este Enterprise Resource Planning a corporației, o soluție software integrată care încorporează funcțiile cheie de afaceri ale organizației.

• SAP NetWeaver Process Integration (SAP PI) este un software SAP enterprise application integration (EAI), o componentă a grupului de produse NetWeaver utilizat pentru a facilita schimbul de informații între software-ul și sistemele interne ale unei companii și cele ale părților externe.

sistem vechi

în timp ce implementați SAP ERP într-o unitate de afaceri mare, se constată că nu toate secțiunile pot fi aduse sub SAP ERP. Multe dintre secțiunile de afaceri pot avea propriile lor instrumente de proprietate, care sunt extrem de complexe și nu pot fi înlocuite. Ele rulează paralel cu sistemul SAP. Ele sunt numite sisteme moștenite. Apoi devine necesar să se integreze între sistemele SAP și un astfel de sistem preexistent non-SAP. Aici intră în joc SAP PI.

de ce avem nevoie de SAP PI în afară de sistemele vechi, într-o unitate de afaceri mare, SAP ERP nu constă dintr-un singur sistem, ci mai multe sisteme integrate, adică CRM, SRM și FICO etc. Pentru a gestiona cu astfel de complexități, SAP a introdus integrarea proceselor o platformă pentru a oferi un singur punct de integrare pentru toate sistemele fără a atinge rețeaua complexă existentă de sisteme vechi. Acesta este un middleware puternic de SAP pentru a oferi o integrare perfectă între aplicațiile SAP și non-SAP în interiorul și în afara graniței corporative. SAP PI acceptă schimburile B2B, precum și A2A, acceptă schimbul de mesaje sincrone și asincrone și include motorul încorporat pentru proiectarea și executarea proceselor de integrare.

arhitectura SAP PI

SAP PI constă dintr-o structură hub și spițe; spițele se conectează cu sisteme externe în timp ce hub-ul schimbă mesaje între ele. Sistemul sursă este cunoscut sub numele de sistem expeditor, iar sistemul țintă este cunoscut sub numele de sistem receptor. PI nu este o singură componentă, ci mai degrabă o colecție de componente care lucrează împreună flexibil pentru a implementa scenarii de integrare. Arhitectura include componente care urmează să fie utilizate la momentul proiectării, la momentul configurării și la momentul rulării.

putem împărți SAP PI în mai multe zone

1. Integration Server
2. Integration Builder
3. System Landscape
4. configurare și monitorizare

Integration Server este motorul central de procesare al SAP PI. Toate mesajele sunt procesate aici într-un mod consecvent. Se compune din trei motoare separate

1. motor de integrare
2. motor Adaptor
3. motor de proces de afaceri

motor de integrare poate fi considerat a fi hub-ul și motorul Adaptor spița. În ceea ce privește motorul procesului de afaceri, îl voi explica mai târziu.

Integration Builder este un cadru client-server pentru accesarea și editarea obiectelor de integrare și constă din două instrumente conexe:

1. Enterprise Service Repository – pentru a proiecta și dezvolta obiecte pentru a fi utilizate în scenarii
2. director de integrare – pentru a configura obiectele ESR pentru a dezvolta scenarii

două împreună, am construit procese de integrare care sunt denumite în mod obișnuit scenarii.

peisajul de sistem este un depozit central de informații despre software și sisteme în centrul de date și simplifică administrarea peisajului de sistem.

în configurare și monitorizare putem monitoriza mesajele și adaptoarele.

single stack și dual stack

când PI a fost lansat pentru prima dată, nu toate componentele au fost construite pe aceeași platformă. Motorul de integrare și motorul procesului de afaceri au fost construite în ABAP, în timp ce motorul adaptorului, constructorul de integrare, SL, CM și Mapping Runtime au fost construite în Java. Deci PI are nevoie atât de mediul Java, cât și de mediul ABAP pentru a rula și este cunoscut sub numele de dual stack.

ABAP Stack	Java Stack
motor de integrare motor de proces de afaceri constructor de integrare	Enterprise Service Repository director de integrare Runtime Workbench sistem peisaj Director Adaptor motor cartografiere Runtime

dar în versiunea ulterioară toate componentele sunt construite în Java. Unele dintre componentele dual-stack sunt fie distribuite, fie modificate pentru a funcționa pe stiva Java. Deci PI are nevoie doar de mediul Java pentru a rula și este cunoscut sub numele de stivă unică.

există argumente pro și contra între cele două stive, dar acestea nu sunt acoperite în acest tutorial.

Motor De Integrare

motorul de integrare este responsabil pentru serviciile serverului central de integrare, adică pașii conductei-linie-rutare și cartografiere. Dacă structura mesajului sursă este diferită de structura mesajului țintă, atunci integration engine apelează timpul de rulare a mapării, unde structura sursă este convertită în structura țintă. Runtime de cartografiere se bazează pe stiva Java. Motorul de integrare poate utiliza, de asemenea, un program ABAP pentru conversie, care se bazează pe stiva ABAP.

un mesaj poate fi de două tipuri

1. sincron – are atât partea cerere-răspuns
2. asincron – are fie cererea, fie partea de răspuns numai

în PI, mesajul este reprezentat de o interfață.

interfață -> structura mesajului în format XML + direcție

pe baza criteriilor de mai sus, există trei tipuri de interfețe

1. interfață de ieșire – conectați – vă la sistemul expeditor
2. interfață de intrare – conectați-vă la sistemul receptor
3. interfață abstractă-conectați-vă la BPE

când configurăm logica de integrare (scenariu) în SAP PI conform cerințelor noastre de afaceri, motorul de integrare este cel care execută acea configurație într-un mod pas cu pas. Pipeline este termenul folosit pentru a se referi la toate etapele care sunt efectuate în timpul procesării unui mesaj XML. Etapele conductei constau din următoarele:

1. identificarea receptorului-determină sistemul care participă la schimbul mesajului.
2. determinarea interfeței-determinați ce interfață va primi mesajul.
3. Message Split – în cazul în care se găsesc mai mult de un receptor, PI va instantia mesaj nou pentru fiecare receptor.
4. mapare mesaje – mapare pentru a transforma mesajul sursă în formatul mesajului destinație.
5. rutare tehnică-legați o destinație specifică și un protocol de mesaj.
6. Adaptor apel – trimiteți mesajul transformat la adaptor sau la un proxy.

Adaptor motor

trebuie să fi observat mai devreme că motorul de integrare se ocupă de mesaje în protocolul XML-SOAP numai. Dar dacă avem un sistem de afaceri expeditor și receptor în care datele nu sunt în același format. Folosim diferitele Adaptoare din motorul adaptorului pentru a converti mesajele bazate pe XML și HTTP în protocolul și formatul specific cerute de aceste sisteme și invers.

așa cum am discutat mai devreme, SAP PI este un hub și a vorbit structura în cazul în care motorul adaptor poate fi considerat ca a vorbit. Folosim motorul adaptorului pentru a conecta motorul de integrare (Hub) la sistemele externe. Cadrul adaptorului este baza motorului adaptorului. Cadrul adaptorului se bazează pe motorul SAP J2EE (ca parte a serverului de aplicații web SAP) și pe arhitectura conectorului J2EE (JCA). Cadrul adaptorului oferă interfețe pentru configurarea, gestionarea și monitorizarea adaptoarelor.

într-un sistem dual stivă, cele mai multe dintre adaptoarele în cazul în care se bazează pe stiva Java restricționarea două adaptoare care se bazează pe stiva ABAP.

Java Stack	adaptor RFC, adaptor Conector SAP Business, adaptor fișier / FTP, adaptor JDBC, adaptor JMS, adaptor SOAP, Adaptor Marketplace, adaptor Mail, adaptor RNIF, adaptor CIDX
ABAP stack	adaptor IDOC și adaptor HTTP

când SAP PI s-a mutat de la stivă dublă la stivă unică, atunci aceste două adaptoare au devenit parte a stivei Java. Motorul adaptorului modificat este cunoscut sub numele de motorul adaptorului Advance, iar cele două adaptoare sunt numite adaptorul IDOC_AAE și respectiv adaptorul HTTP_AAE.

Motor De Proces De Afaceri

motorul procesului de afaceri este responsabil pentru executarea și persistența proceselor de integrare.

BPM standuri pentru Cross-component Business Process Management sau ccBPM și este, de asemenea, numit procesul de integrare. Un proces de integrare este un proces executabil, cross-system pentru procesarea mesajelor. Într-un proces de integrare definiți toți pașii de proces care urmează să fie executați și parametrii relevanți pentru controlul procesului. Managementul proceselor de afaceri oferă infrastructura SAP Exchange cu următoarele funcții:

1. Stat-full message processing: starea unui proces de integrare este persistat pe serverul de integrare.
2. puteți utiliza, de asemenea, corelații pentru a stabili relații semantice între mesaje.
3. implementați procese de integrare atunci când doriți să definiți, să controlați și să monitorizați procese complexe de integrare care se extind peste limitele întreprinderii și ale aplicațiilor, adică collect/Merge, Split, Multicast

în timpul rulării, Business Process Engine execută procesele de integrare. Procesul de integrare poate trimite și primi mesaje folosind doar interfețe abstracte.

construiți un scenariu în SAP PI

pornim de la pagina de pornire dacă trebuie să construim un scenariu în PI.

pagina de start va arata similar cu cel de mai jos:

Figura 6 – Pagina de pornire pentru SAP PI Java Stack

pagina de pornire are hyperlink-uri către următoarele 4 zone de lucru

1. Enterprise Services Repository(ESR)
2. Integration Directory (ID)
3. System Landscape (SL)
4. configurare și monitorizare (CM)

fiecare hyperlink va deschide o aplicație. Toate aceste patru sunt aplicații Java. ESR și ID sunt aplicații swing. Acestea sunt lansate din browser pe baza JNLP. Deci, pentru prima dată este nevoie de mai mult timp, deoarece descarcă întregul fișier bibliotecă. Dar începând cu a doua oară, este nevoie de mai puțin timp pentru lansare. SL și CM sunt aplicații web pure și rulează pe browser.

Enterprise Services Repository

aici proiectăm și creăm obiecte pentru a fi utilizate în realizarea unui scenariu de integrare. Fluxul de date din PI va arăta similar cu cel prezentat mai jos:

găsim opțiunea de a proiecta următoarele

1. obiecte de interfață – interfață de serviciu, tip de mesaj, tip de date
2. procese de integrare

PI folosește depozitul de integrare pentru a proiecta structura mesajelor atât pentru sistemele de expeditor, cât și pentru receptor și pentru a dezvolta un mesaj de interfață folosind structuri de mesaje corespunzătoare care acționează ca punct de interacțiune cu lumea exterioară. Tipul de date și tipul de mesaj sunt utilizate pentru a simplifica și modula proiectarea unei interfețe complexe.

Operation Mapping permite transformarea structurii sursă la structura țintă atunci când cele două structuri sunt diferite. Dar dacă sursa și structura țintă sunt aceleași, atunci cartografierea operațiunii poate fi eliminată. Similar cu interfața de serviciu, maparea mesajelor este utilizată pentru a simplifica și modula proiectarea unei mapări complexe a operațiilor. Maparea mesajelor poate fi implementată în 4 moduri

1. mapare grafică
2. mapare Java
3. mapare XSLT
4. mapare ABAP

maparea grafică este cea mai utilizată, deoarece permite dezvoltatorului să mapeze atributele ambelor structuri grafic pentru a transmite date folosind interfețe de serviciu. Pentru celelalte trei, trebuie să dezvoltăm cartografierea scriind cod. Dacă este un singur server de stivă, atunci maparea ABAP nu va fi disponibilă.

există și alte domenii, dar acestea nu sunt acoperite în acest tutorial.

integrare Director

aici vom face pașii de țeavă-linie prin configurarea obiectelor ESR create anterior. Acești pași sunt executați de motorul de integrare în timpul rulării.

înainte de a începe configurația, trebuie să creăm/să importăm următoarele obiecte în DIR.

1. serviciu – sistem de afaceri/ Serviciu de afaceri/ proces de integrare
2. canal de comunicare

un serviciu vă permite să vă adresați unui expeditor sau receptor de mesaje. În funcție de modul în care doriți să utilizați serviciul, puteți selecta dintre următoarele tipuri de servicii.

1. sistem de afaceri – dacă doriți să vă adresați unui anumit sistem de afaceri ca expeditor sau receptor al mesajelor, alegeți acest tip de serviciu. Un sistem de afaceri este un sistem de aplicare real într-un peisaj de sistem.
2. serviciu de afaceri – dacă doriți să vă adresați unei entități de afaceri abstracte ca expeditor sau receptor al mesajelor, alegeți acest tip de serviciu. Un serviciu de afaceri nu este definit în peisajul sistemului.
3. serviciul procesului de integrare – dacă doriți să abordați un proces de integrare ca expeditor sau receptor al mesajelor, alegeți acest tip de serviciu. În timpul rulării, aceste procese de integrare sunt controlate de mesaje și pot trimite ele însele mesaje.

canalul de comunicare determină procesarea de intrare și ieșire a mesajelor. Mesajele sunt convertite din format nativ în format de mesaj specific soap-xml și invers prin adaptor. În general, există două tipuri de canale de comunicare într-un scenariu

1. canal de comunicare expeditor
2. canal de comunicare receptor

trebuie să atribuiți un canal de comunicare unui serviciu. În funcție de faptul dacă serviciul este adresat ca expeditor sau receptor de mesaje, canalul de comunicare atribuit are rolul fie de expeditor, fie de canal receptor și trebuie configurat în consecință. Nu puteți atribui un canal de comunicare unui serviciu de proces de integrare.

pașii liniei de țeavă sunt creați prin crearea următoarei configurații 4 în DIR

găsim următoarele opțiuni:

1. acordul expeditorului
2. determinarea receptorului
3. determinarea interfeței
4. acordul receptorului

acordul expeditorului definește modul în care mesajul unui expeditor trebuie transformat astfel încât să poată fi procesat de serverul de integrare. Se compune din următoarele

1. componenta expeditor
2. interfață expeditor
3. canal de comunicare expeditor

acordul expeditor este similar cu cheia primară în tabel. Nu pot exista cele două acorduri similare ale expeditorilor într-un singur peisaj.

acordul receptorului definește modul în care mesajul trebuie transformat astfel încât să poată fi procesat de un receptor. Se compune din

1. componentă expeditor
2. componentă receptor
3. interfață receptor
4. canal de comunicare receptor

utilizați o determinare receptor pentru a specifica care receptoare un mesaj este de a fi trimis. Aveți opțiunea de a defini condițiile pentru redirecționarea mesajului către receptoare. Se compune din

1. componenta expeditorului
2. interfața expeditorului
3. componenta receptorului

determinarea receptorului este de două tipuri – Standard sau extins, în funcție de dacă doriți să specificați receptorul manual sau dinamic printr-o mapare în timpul rulării.

utilizați o determinare a interfeței pentru a specifica care interfață de intrare a unui receptor; mesajul trebuie redirecționat către. De asemenea, puteți specifica ce mapare de interfață din depozitul de integrare va fi utilizată pentru procesarea mesajului, adică. dacă expeditorul și interfața receptorului nu sunt de același format, atunci există o mapare operațională pentru a schimba formatul. Definiți o determinare a interfeței pentru un expeditor, o interfață de ieșire și un receptor. Se compune din

1. componentă expeditor
2. interfață expeditor
3. componentă receptor
4. interfață receptor

determinarea interfeței este de două tipuri – Standard sau îmbunătățită, în funcție de faptul dacă doriți să specificați interfața receptor manual sau prin split mesaj bazat pe mapare.

determinarea receptorului și determinarea interfeței – cele două împreună sunt cunoscute în mod obișnuit ca rutare logică. Acordul expeditorului și Acordul receptorului – cele două împreună sunt cunoscute în mod obișnuit ca acordul de colaborare.

peisaj sistem

directorul peisaj sistem SAP (SLD) este furnizorul central de informații într-un peisaj sistem. În pagina web veți găsi următoarele link-uri:

1. sistem tehnic – sistemele tehnice sunt sisteme de aplicații care sunt instalate în peisajul de sistem.
2. Business System-sistemele de afaceri sunt sisteme logice, care funcționează ca expeditori sau receptoare în cadrul PI. Sistemele de afaceri au o dependență unu-la-unu cu sistemul tehnic asociat.
3. produse și Componente – acestea sunt informații despre toate produsele și componentele SAP disponibile, inclusiv versiunile acestora. Dacă există produse terțe în peisajul sistemului, acestea sunt înregistrate și aici.

SLD va arăta similar cu cel prezentat mai jos:

Figura 11-peisaj sistem

produsele și componentele sunt denumite în mod obișnuit informațiile componente

sistemul tehnic și sistemul de afaceri sunt denumite în mod obișnuit descrierea peisajului.

un sistem de afaceri poate fi configurat ca un server de integrare sau sistem de aplicații.

1. Integration Server – serverul de integrare execută numai logica de integrare configurată în constructorul de integrare. Ele pot fi, de asemenea, identificate ca pași de linie de țeavă. Acesta primește un mesaj XML, determină receptorul, execută mapările și direcționează mesajul XML către sistemele receptoare corespunzătoare. Astfel, motorul de integrare configurat este identificat ca fiind motorul central de integrare configurat.
2. sistem de aplicații – Sistemul de aplicații nu va executa logica de integrare. La rândul său, apelează serverul de integrare pentru a executa logica de integrare, dacă este necesar. Acesta acționează ca expeditor sau receptor de mesaje XML. Deci, sistemul de aplicații cu un motor de integrare locală necesită serverul de integrare pentru a executa logica de integrare.

un singur client al sistemului SAP poate fi configurat ca server de integrare.

următoarele informații sunt extrase din SLD în ESR și DIR

1. informații componente sunt utilizate în ESR pentru a defini produsul și SWCV
2. sistem de afaceri sunt utilizate în directorul pentru definirea expeditor și receptor de mesaje

configurare și monitorizare

este punctul central de intrare în scopuri de monitorizare. Acest lucru vă oferă opțiunea de a naviga la funcțiile de monitorizare ale motorului de integrare, precum și integrarea cu sistemul de Management al Centrului de calcul (CCMS) și infrastructura de monitorizare a proceselor (PMI) a SAP.

configurația și monitorizarea vor arăta similar cu cele prezentate mai jos:

Figura 13-configurare și monitorizare

cu configurarea și monitorizarea sunt acceptate următoarele funcții de monitorizare:

1. Component monitoring-monitorizarea diferitelor componente SAP PI (piese Java și ABAP).
2. monitorizarea mesajelor – urmărirea stării de procesare a mesajelor într-o componentă SAP PI și detectarea și analiza erorilor.
3. monitorizare End-to-end – monitorizarea unui ciclu de viață al mesajului din punctul de vedere SAP PI.
4. monitorizarea performanței – statistici despre diferite aspecte de performanță ale SAP PI pot fi accesate prin RWB. Aici, puteți selecta și agrega date de performanță, de exemplu, după componente, interval de timp sau atribute de mesaj.
5. administrarea indexului – prin administrarea și monitorizarea indexării mesajelor pe componenta SAP PI, activați o căutare de mesaje bazată pe index pe care o puteți utiliza în monitorizarea mesajelor. Acest tip de căutare de mesaje vă oferă criterii de selecție îmbunătățite, inclusiv atribute de mesaj specifice adaptorului și termeni sau fraze din sarcina utilă a mesajului.
6. configurare alertă – prin utilizarea cadrului de alertă, monitorizarea centrală în PI poate fi furnizată cu toate erorile raportate în timpul procesării mesajelor în ABAP și Java. Acest lucru permite o reacție îmbunătățită la astfel de erori atât în timpul de rulare ABAP, cât și în motorul adaptorului bazat pe Java. În acest scop, cadrul de alertă este prevăzut cu reguli bazate pe anumite evenimente și pe informații din antetul protocolului de mesaje PI. Aceste Reguli determină dacă alertele sunt trimise sau nu. Dacă este trimisă o alertă, aceasta poate fi utilizată pentru analiza erorilor.
7. inbox de alertă – inbox-ul de alertă este specific utilizatorului și afișează toate alertele pentru fiecare server de alertă care a fost generat pe baza configurației de alertă.
8. monitorizare Cache – monitorizarea cache afișează obiectele care sunt în prezent în memoria cache de rulare. Diferite obiecte cache sunt monitorizate în funcție de instanța cache în cauză.

comunicare sincronă vs.asincronă

un proces poate fi definit ca sincron sau asincron.

• un proces sincron este invocat de o operație de solicitare/răspuns, iar rezultatul procesului este returnat apelantului imediat prin această operație.
• un proces asincron este invocat de o operație unidirecțională, iar rezultatul și eventualele defecțiuni sunt returnate prin invocarea altor operații unidirecționale. Rezultatul este returnat apelantului printr-o operație de apel invers.

în lumea computerelor, nu există comunicare asincronă. Toate comunicările între două sisteme sunt întotdeauna prin apel de metodă (operație de solicitare/răspuns). Deci, cum o facem asincron? Răspunsul constă în introducerea unui al treilea sistem între funcția apelată și cea a apelantului.

să presupunem că există două sisteme-A și B. Toată comunicarea dintre A și B se face printr-un apel de metodă și, prin urmare, acestea sunt sincrone. Introducem un al treilea sistem între a și B și l – am numit sistemul intermediar-I. comunicarea dintre a și I se face prin apel de metodă și, în mod similar, între I și B se face și prin apel de metodă. Dar comunicarea dintre a și B poate fi numită asincronă, deoarece A nu trebuie să aștepte răspunsul de la B.

aceasta este baza comunicării asincrone și care este acest sistem intermediar? Aceasta este coada. A se numește expeditor și B se numește receptor. Mesajul de la A este adăugat mai întâi la coadă și apoi este din nou tras din coadă și trimis la B. răspunsul de la B ajunge la A într-un mod similar. În anumite situații, cerința de afaceri are nevoie ca mesajele să fie livrate către B în aceeași ordine în care sunt declanșate de la A. în acest caz, urmăm o politică first-in și first-out. Dacă nu există astfel de cerințe, atunci mesajele sunt trimise de la coadă la B, în orice ordine.

cu comunicarea asincronă, obținem o livrare garantată, adică sistemul B nu este disponibil atunci când sistemul a trimite mesajul. Mesajul este adăugat la coadă și rămâne acolo atâta timp cât B nu este disponibil. Odată ce B este disponibil, mesajul este tras din coadă și trimite la B.

astfel încât să putem clasifica comunicarea noastră mesaj în trei moduri:

1. sincron
2. asincron cu ordine neținută
3. asincron cu ordine menținută

în PI, le identificăm ca: sincron – BE (cel mai bun efort), asincron cu ordine neținută – EO (exact o dată), asincron cu ordine menținută – EOIO (exact o dată în ordine).

recunoașterea

recunoașterea este rădăcina comunicării asincrone. De ce?

pentru comunicarea sincronă, sistemul a apelează sistemul B și dacă B nu trimite răspunsul, procesul a eșuat. Dar într-o comunicare asincronă, sistemul a apelează sistemul I și Sistemul i apelează sistemul B. Deci, să presupunem că comunicarea dintre a și I are succes, dar între I și B eșuează. Cum ar trebui să-și dea seama că livrarea către B a eșuat? Acest lucru se realizează printr-o confirmare care este trimisă înapoi la A Prin B pe același traseu ca și mesajul de la a dus la B. Dacă confirmarea de la B nu ajunge la A, atunci a consideră că procesul a eșuat și va trimite din nou mesajul.

în timp ce am discutat despre comunicarea asincronă în PI, am folosit termenul – ‘exact o dată’ atât pentru EO, cât și pentru EOIO. Exact o dată înseamnă că un mesaj livrat o dată nu poate fi livrat din nou. Pentru a realiza acest lucru, există o confirmare pentru fiecare mesaj trimis de la A la B. adaptoarele se află la sfârșitul comunicării. Deci adaptoarele trebuie să accepte confirmarea.

toate adaptoarele asigură recunoașterea sistemului i.e. confirmare de livrare. Acele adaptoare care acceptă comunicarea sincronă acceptă recunoașterea aplicației în plus față de confirmarea sistemului.

deci, în PI, următoarele sunt tipul de confirmare

1. confirmare de sistem – Confirmări de sistem utilizate de mediul de rulare pentru a confirma că un mesaj asincron a ajuns la receptor.

apel de funcție la distanță

în timp ce lucrați în PI, veți întâlni termenul – RFC. Ce sunt? Pentru a stabili comunicarea între două sisteme SAP, adică un R/3 și PI, creăm destinația RFC. Acesta este configurat de următoarele

1. Tip conexiune
2. adresa IP și portul receptorului

Tip conexiune spune tipul de conexiune de sistem adică R/3, TCP/IP, intern etc.

destinația RFC pe care o creăm este clasificată în funcție de modul de comunicare necesar, adică. dacă ar trebui să sprijine comunicarea sincronă sau asincronă.

1. pentru comunicarea sincronă – RFC sincron
2. pentru comunicarea asincronă cu ordinul neținut – RFC tranzacțional
3. pentru comunicarea asincronă cu ordinul menținut – RFC în coadă

sunt identificate prin sRFC, tRFC și qRFC.

studii de caz – 1

să presupunem că sunteți într-o sală de clasă și există 10 elevi în ea. Instructorul cere apoi fiecărui elev să-și pregătească următoarele detalii personale și să le salveze într-un fișier XML. Detaliile sunt următoarele:

1. ID Student
2. nume
3. mobil
4. e-mail
5. gen

vor fi 10 fișiere și fișierele sunt denumite cv_1, 2, 3….10. Fișierele sunt salvate în directorul sursă. Pentru scopuri de testare următoarele directoare sunt create:

director sursă: c:\ibm\sap\training\input

director arhivă:c:\ibm\sap\training\archive

director de eroare: c:\ ibm \ SAP \ training \ eroare

director țintă: c:\ibm\sap\training\target

vi se cere să dezvoltați scenarii în SAP PI care vor citi fișierele sursă din directorul sursă și le vor scrie în directorul țintă. Odată ce un fișier este citit cu succes din directorul sursă, acesta ar trebui să fie mutat în directorul de arhivă și dacă fișierul nu poate fi citit pentru o anumită eroare, adică formatul xml nu este menținut, acesta ar trebui mutat în directorul de eroare. Fișierele mutate în arhivă, eroare sau director țintă ar trebui să aibă o ștampilă de timp adăugați la numele fișierului.

1. adică. Nume fișier + <ștampila de timp>.

Lecția-1

pregătiți un scenariu pentru a citi un singur fișier, adică fișierul cv_1.xml din directorul sursă și scrieți-l în directorul țintă. Numele fișierului țintă ar trebui să fie, de asemenea, cv_1.xml cu ștampila de timp se adaugă la numele.

Lecția-2

pregătiți un scenariu pentru a citi toate fișierele din directorul sursă și a le scrie în directorul țintă. În mod similar, fișierele țintă ar trebui să fie, de asemenea, numit ca cv_1, 2 ..xml cu ștampila de timp se adaugă la fiecare dintre ele.

Lecția-3

instructorul vă cere apoi să adăugați următoarea validare la date.

1. numărul mobil ar trebui să aibă 10 cifre numerice – dacă numărul mobil nu este de 10 cifre, atunci înlocuiți-l cu ‘eroare’
2. e-mailul ar trebui să aibă un caracter ‘@’ și unul ‘.’caracter – dacă e-mailul nu are ‘@’ sau ‘.’caracter, apoi înlocuiți-l cu ‘eroare’

înainte de a rula scenariul, în unele dintre fișierele sursă, modificați telefonul mobil și e-mailul, astfel încât acestea să fie greșite conform logicii date mai sus.

Lecția-4

pregătiți un scenariu pentru a citi toate fișierele sursă și a le clasifica în funcție de sexul lor. Fișierele pentru bărbați vor fi scrise într-un director și pentru doamne într-un alt director. Două directoare sunt create pentru scopul de mai sus:

director țintă pentru bărbați: c:\ibm\sap\training\target\men

director țintă pentru femei: c:\ ibm \ sap \ training \ target \ women

să presupunem că există 6 bărbați și 4 femei în clasă, atunci dacă toate fișierele sursă sunt citite cu succes, atunci directorul țintă pentru bărbați ar trebui să aibă 6 fișiere și directorul țintă pentru femei ar trebui să aibă 4 fișiere.

studii de caz – 2

instructorul vă cere apoi să pregătiți un singur fișier cu datele personale ale fiecărui elev în segmente separate.

Lectia-5

scrie un scenariu care va citi acest fișier și produce 10 fișiere țintă în cazul în care fiecare fișier ar trebui să corespundă cu datele personale ale fiecărui angajat. Fișierele țintă ar trebui să fie numit ca cv_<emp_ID>_<timestamp>

Lection-6

modifica scenariul de mai sus, astfel încât să producă 2 fișiere țintă în loc de 10 în cazul în care un fișier țintă pentru bărbați și un alt fișier țintă pentru doamne. Fișierul țintă pentru bărbați ar trebui să aibă 6 segmente pentru 6 bărbați, iar fișierul țintă pentru femei ar trebui să aibă 4 segmente pentru 4 femei.

fișierele țintă ar trebui să fie numit ca

pentru bărbați – men_<timp-timbru>

pentru femei – women_<time_stamp>

studiu de caz -3

la fel ca studiu de caz – 1, instructorul cere fiecărui elev să se pregătească lui/ei detaliile personale și salvați-le într-un fișier XML. Vor fi 10 dosare. Fișierele sunt salvate în directorul sursă.

Lecția-7

pregătiți un scenariu pentru a citi toate fișierele sursă din directorul sursă și pentru a crea un singur fișier în directorul țintă. Numele fișierului țintă va fi afișat.xml cu ștampila de timp se adaugă la numele fișierului. Fișierul țintă va avea toate detaliile fiecărui fișier sursă ca sub-segment.

Lecția-8

pregătiți un scenariu pentru a citi fișierele sursă întregi din directorul sursă și creați două fișiere în directorul țintă – unul pentru bărbați și celălalt pentru doamne. Pentru 6 bărbați, fișierul pentru bărbați ar trebui să aibă șase segmente cu detaliile fiecărui bărbat, iar pentru 4 femei, în mod similar, ar trebui să existe 4 segmente cu detaliile fiecărei doamne.

studiu de Caz – 4

instructorul cere acum fiecăruia dintre studenți să pregătească un alt set de detalii care vor consta din următoarele detalii academice:

1. ID Student
2. numele școlii
3. numele colegiului
4. Numele departamentului
5. Anul admiterii

vor fi 10 fișiere și fișierele sunt denumite ad_1, 2, 3….10. Fișierele sunt salvate în directorul sursă. Deci, fiecare student va avea acum o pereche de fișiere – unul pentru detaliile personale și celălalt pentru detaliile academice. Două fișiere sunt corelate cu ID-ul elevului. Directorul de intrare este format acum din 10 fișiere personale și 10 fișiere academice.

Lection – 9

vi se cere să dezvolte un scenariu care va alege fișierele sursă și le va procesa în pereche. Scenariul va genera 10 fișiere țintă. Fiecare fișier țintă va consta din detaliile personale și academice ale unui student în segmente separate. Fișierele țintă vor fi denumite ca res_1, 2, 10.

fișierele țintă vor arăta ca:

Lecția – 10

vi se cere apoi să schimbați ID-ul elevului în unele dintre fișiere, astfel încât să nu aibă fișiere academice sau personale potrivite și invers. Scenariul ar trebui să ruleze și dacă a găsit orice fișiere care nu are un fișier corespunzător de potrivire, atunci procesul ar trebui să se încheie după o anumită perioadă de timp, adică 2 min și aceste fișiere vor fi mutate în directorul de eroare și nu vor exista fișiere țintă corespunzătoare pentru ei.