SAP Web Application Server
Content
SAP –WEB Application Server
GhiĊ£un Oana Marina Cuprins: 1. Solutii SAP 2. SAP Netweaver 3. SAP Web Application Server a. Client Server Configuration b. Server Processes c. Procesarea requesturilor 4. Comunicarea cu baza de date 5. Tranzactii in SAP 6. Lock Management 7. Update processing a. Principiul update-urilor asincrone
1.Solutii SAP
SAP ofera un portofoliu de solutii software pentru diferite industrii. Solutiile SAP sunt in continuua optimizare si extindere si sunt cu precadere orientate spre a oferi companiilor mari solutii care se pliaza pe industriile in care respectiva companie activeaza.
SAP NetWeaver reprezinta infrasctructura tehnologica pentru toate solutiile SAP. mySAP Business Suite contine toate solutiile SAP care se bazeaza pe SAP NetWeaver. Ofera: -un spectrum complet de solutii business - o infrastructura tehnologica care combina stabilitatea si felxibilitatea -interfete pentru a facilita integrarea cu applicatii non SAP -componenet ce pot fi adaptate pentru a satisface diverse cerinte business -numeroase functii industry-specific
SAP xAPPS(Colaborative Cross Applications) permite integrarea aplicatiilor existente accesand seturi de date existente si functii folosind interfete. Pentru a justifica folosirea solutiilor SAP urmatoarele figuri sunt sugestive.
Exemplu de solutii oferite de SAP: ERP – enterprise Resource Management CRM- Customer Relationship Management
PLM- Product Lifecycle Management
2.SAP Netweaver
Repezinta infrastructura IT pe care se bazeaza toate solutiile SAP:
People Integration- folosing un enterprise Portal – un centru comun de access la informatii, aplicatii sau servicii intr-o companie. Information Integration – folosit pentru a oferi informatii relevante, pentru a oferi posibilitatea de a analiza in mod flexibil.Acest lucru e posibil folosind functii de cautare inteligente. Totodata creeare de informatii ce pot fi ulterior transportante in toate sistemele dependente. Process Integration – SAP XI - Exchange infrastructure folosit pentru a implementa procese business cross-system. Permite conexiune sistemelor non SAP. Ofera infrastructura runtime pentru schimbarea de mesaje intre sisteme, optiuni de configurare, controlul proceselor si al fluxului de mesaje intre sender si receiver.
3.SAP WEB Application Server
Sistemele SAP sunt folosite la maparea proceselor business sau a aplicatiilor. Aplicatiile trebuie implementate independent de harware-ul mediului folosit (system de operare, baze de date). SAP WEB Application Server dispune de 2 medii runtime: ABAP runtimen enviroment si JAVA runtime enviroment. ABAP- Advanced Business Programming Language e un limbaj de programare dezvoltat de SAP. Cele mai multe din aplicatiile sistemelor sunt scrise in ABAP.
a.Configurarea Client-Server pentru systeme SAP
Exista 3 procese necesare pentru operarea aplicatiilor software business: *Presentation Process – ex: afisare *Application Process ex: rularea programelor *Database Process > managementul bazelor de date Sistemele SAP pot fi configurate in diferite moduri:
In configurari single- toate procesele sunt realizate pe aceiasi masina( database, application si presentation). Sunt folosite pentru teste si demonstratii. Este ineficient cand mai multi useri trebuie sa foloseasca acest sistem Configurarea two-tier cu presentation processes distribuite ofera performanta buna cand un numar mai mare de utilizatori folosesc sistemul. Arhitectura care imbunatateste performanta si evita efectul de bottleneck este cea threetier.
b.Server Processes
Mediul runtime SAP consta intr-un numar de procese care lucreaza paralel. Pentru managementul proceselor, in mediile ce folosesc ABAP un dispatcher este folosit. Acesta este responsabil de diferitele tipuri de procese:dialog(user requests), update, background,locks. Pe langa aceste procese sistemul ofera servicii pentru comunicare *Server de mesaje – dinstre dispatchere diferite *Gateaway Server – comunicare intre sisteme SAP *Internet communication manager – cumunicare directa cu internetul Nivelul aplicatiei a unei arhitecturi SAP consta din mai multe instante. Insa sistemul are o instanta principala. Aceasta contine serverul de mesaje cu care comunica dispatcherele celorlalte instante.
Application server are mai multe roluri. Simultan poate fi si dialog server si background server.
b.Procesarea requesturilor
Un utilizator poate se poate loga in SAP GUI sau in browser. Dupa logare toate requesturil sunt procesate de ABAP runtime enviroment. Procesarea requesturilor din SAP GUI se face cu ajutorul Dispatcherului(ABAP). Rolul este de a: *distribui tranzactiile catre procese *integrarea nivelului de prezentare(presentation layer) *organizarea comunicarii tranzactiilor Distributia se face una dupa alta(requesturile sunt pastrate in cozi FIFO) catre procesele disponibile. Un utilizator nu este asignat unui singur process. transactiile utilizatorului sunt procesate de procese diferite in functie de disponibilitatea acestora. Dupa procesare rezultatul este trimis via dispacher inapoi in SAP GUI pentru a fi diponibil utilizatorului. Procesarea requesturilor via browser se face utilizand ICM – internet Communication Manager. Aici exista 2 dispatchere: pentru jAVA si ABAP. Fiecare server are propriul dispatcher. Un request este format practic din „ecrane”: PBO(process before output), PAI(Process After input). Acestea sunt evaluate de un Interpreter:
4.Comunicarea cu baza de date
SAP foloseste RDBMS. Pentru intereogare in limbajul ABAP se foloseste SAP Open SQL. SAP Web Application server transforma inteorgrile din limbaj ABAP in Open SQL(contine si elemente care nu sunt incluse in standard).
Datele care sunt cerute des sunt pastrate in buffere pentru a nu accesa baza de date de mai multe ori. Daca sunt folosite comenzi native SQL atunci se acceseaza direct baza de date fara a fi folosite buffere.
5 .Tranzactii in SAP
Tranzactiile sunt unitati de procesare grupate pentru a face disponibila o anumita functionalitate. Sunt caracterizate ACID. Tranzactii Data Base Schimbarile aduse bazei de date se fac cu ajutorul trazactiilor:
Tranzactiie SAP nu sunt neaparat rulate intr-un singur dialog work processs( D WP). Din acest motiv este nevoie de o tranzactie data base noua pentru fiecare work process.
6 .Lock Management
Pnetru a asigura consistenta datelor sistemele SAP are propriul concept de management al lockurilor. Database lock administration poate coordona numai tranzactiile de tip data base. Transactiile SAP sunt formate din mai multi pasi(screen-uri, dialoguri). Conceptul de lock management al tranzactiilor SAP este implementat utilizand inlantuirea procesor(work process). Programele SAP introduc record-uri intr-o tabela(lock table) in memoria principala a SAP WEB AS. Lock-urile pot fi introduse in tabela numai daca nu exista deja record-uri pentru obiectul ce urmeaza a fi blocat:
In cazul in care work process-urile sunt pe servere diferite si cer acess la aceiasi resursa atunci comunicare se face prin message server:
Lockurile sunt practic obiecte ce trebuie declarate in ABAP Dictionary. Exista mai multe tipuri de lockuri: *de scriere *de scriere extinsa (owner-ul poate adauga drepturi de scriere) *shared locks *optimistic locks( numai pentru afisarea datelor) Cand se cere blocarea unui obiect sistemul verifica tabela de lock-uri. Daca un lock exista atunci accesul la obiect este refuzat. Exista 2 module de functii care sunt folosite pentru a bloca si debloca un obiect: • ENQUEUE_<OBJNAME> • DEQUEUE_<OBJNAME> Lockurile sunt eliberate fie de programul care le-a cerut sau de update-uri. Lockurile eliberate de update sunt pastrate intr-un fisier pentru a putea fi reblocate in cazul in care sistemul pica.( De ex: serverul pica cand se lucreaza la un program, programul ramane in continuare blocat dupa revenire)
6 .Update processing
Principiul update-urilor asincrone: Folosirea comenzii COMMIT inaintea terminarii tranzatiei. Este la alegeare programatorului daca foloseste sau nu aceasta comanda. La intalnirea comenzii schimbarile sunt pastrare intr-o tabela temporara pana cand vor putea fi scrise in baza de date(adica la terminarea transactiei). La terminarea tranzactiei sunt
cititete tabelele temporare si scrise in baza de date. In cazul in care apare o eroare(duplicate key) triggers a roll back. Tabele temporare nu vor fi scrise in baza de date
GhiĊ£un Oana Marina Cuprins: 1. Solutii SAP 2. SAP Netweaver 3. SAP Web Application Server a. Client Server Configuration b. Server Processes c. Procesarea requesturilor 4. Comunicarea cu baza de date 5. Tranzactii in SAP 6. Lock Management 7. Update processing a. Principiul update-urilor asincrone
1.Solutii SAP
SAP ofera un portofoliu de solutii software pentru diferite industrii. Solutiile SAP sunt in continuua optimizare si extindere si sunt cu precadere orientate spre a oferi companiilor mari solutii care se pliaza pe industriile in care respectiva companie activeaza.
SAP NetWeaver reprezinta infrasctructura tehnologica pentru toate solutiile SAP. mySAP Business Suite contine toate solutiile SAP care se bazeaza pe SAP NetWeaver. Ofera: -un spectrum complet de solutii business - o infrastructura tehnologica care combina stabilitatea si felxibilitatea -interfete pentru a facilita integrarea cu applicatii non SAP -componenet ce pot fi adaptate pentru a satisface diverse cerinte business -numeroase functii industry-specific
SAP xAPPS(Colaborative Cross Applications) permite integrarea aplicatiilor existente accesand seturi de date existente si functii folosind interfete. Pentru a justifica folosirea solutiilor SAP urmatoarele figuri sunt sugestive.
Exemplu de solutii oferite de SAP: ERP – enterprise Resource Management CRM- Customer Relationship Management
PLM- Product Lifecycle Management
2.SAP Netweaver
Repezinta infrastructura IT pe care se bazeaza toate solutiile SAP:
People Integration- folosing un enterprise Portal – un centru comun de access la informatii, aplicatii sau servicii intr-o companie. Information Integration – folosit pentru a oferi informatii relevante, pentru a oferi posibilitatea de a analiza in mod flexibil.Acest lucru e posibil folosind functii de cautare inteligente. Totodata creeare de informatii ce pot fi ulterior transportante in toate sistemele dependente. Process Integration – SAP XI - Exchange infrastructure folosit pentru a implementa procese business cross-system. Permite conexiune sistemelor non SAP. Ofera infrastructura runtime pentru schimbarea de mesaje intre sisteme, optiuni de configurare, controlul proceselor si al fluxului de mesaje intre sender si receiver.
3.SAP WEB Application Server
Sistemele SAP sunt folosite la maparea proceselor business sau a aplicatiilor. Aplicatiile trebuie implementate independent de harware-ul mediului folosit (system de operare, baze de date). SAP WEB Application Server dispune de 2 medii runtime: ABAP runtimen enviroment si JAVA runtime enviroment. ABAP- Advanced Business Programming Language e un limbaj de programare dezvoltat de SAP. Cele mai multe din aplicatiile sistemelor sunt scrise in ABAP.
a.Configurarea Client-Server pentru systeme SAP
Exista 3 procese necesare pentru operarea aplicatiilor software business: *Presentation Process – ex: afisare *Application Process ex: rularea programelor *Database Process > managementul bazelor de date Sistemele SAP pot fi configurate in diferite moduri:
In configurari single- toate procesele sunt realizate pe aceiasi masina( database, application si presentation). Sunt folosite pentru teste si demonstratii. Este ineficient cand mai multi useri trebuie sa foloseasca acest sistem Configurarea two-tier cu presentation processes distribuite ofera performanta buna cand un numar mai mare de utilizatori folosesc sistemul. Arhitectura care imbunatateste performanta si evita efectul de bottleneck este cea threetier.
b.Server Processes
Mediul runtime SAP consta intr-un numar de procese care lucreaza paralel. Pentru managementul proceselor, in mediile ce folosesc ABAP un dispatcher este folosit. Acesta este responsabil de diferitele tipuri de procese:dialog(user requests), update, background,locks. Pe langa aceste procese sistemul ofera servicii pentru comunicare *Server de mesaje – dinstre dispatchere diferite *Gateaway Server – comunicare intre sisteme SAP *Internet communication manager – cumunicare directa cu internetul Nivelul aplicatiei a unei arhitecturi SAP consta din mai multe instante. Insa sistemul are o instanta principala. Aceasta contine serverul de mesaje cu care comunica dispatcherele celorlalte instante.
Application server are mai multe roluri. Simultan poate fi si dialog server si background server.
b.Procesarea requesturilor
Un utilizator poate se poate loga in SAP GUI sau in browser. Dupa logare toate requesturil sunt procesate de ABAP runtime enviroment. Procesarea requesturilor din SAP GUI se face cu ajutorul Dispatcherului(ABAP). Rolul este de a: *distribui tranzactiile catre procese *integrarea nivelului de prezentare(presentation layer) *organizarea comunicarii tranzactiilor Distributia se face una dupa alta(requesturile sunt pastrate in cozi FIFO) catre procesele disponibile. Un utilizator nu este asignat unui singur process. transactiile utilizatorului sunt procesate de procese diferite in functie de disponibilitatea acestora. Dupa procesare rezultatul este trimis via dispacher inapoi in SAP GUI pentru a fi diponibil utilizatorului. Procesarea requesturilor via browser se face utilizand ICM – internet Communication Manager. Aici exista 2 dispatchere: pentru jAVA si ABAP. Fiecare server are propriul dispatcher. Un request este format practic din „ecrane”: PBO(process before output), PAI(Process After input). Acestea sunt evaluate de un Interpreter:
4.Comunicarea cu baza de date
SAP foloseste RDBMS. Pentru intereogare in limbajul ABAP se foloseste SAP Open SQL. SAP Web Application server transforma inteorgrile din limbaj ABAP in Open SQL(contine si elemente care nu sunt incluse in standard).
Datele care sunt cerute des sunt pastrate in buffere pentru a nu accesa baza de date de mai multe ori. Daca sunt folosite comenzi native SQL atunci se acceseaza direct baza de date fara a fi folosite buffere.
5 .Tranzactii in SAP
Tranzactiile sunt unitati de procesare grupate pentru a face disponibila o anumita functionalitate. Sunt caracterizate ACID. Tranzactii Data Base Schimbarile aduse bazei de date se fac cu ajutorul trazactiilor:
Tranzactiie SAP nu sunt neaparat rulate intr-un singur dialog work processs( D WP). Din acest motiv este nevoie de o tranzactie data base noua pentru fiecare work process.
6 .Lock Management
Pnetru a asigura consistenta datelor sistemele SAP are propriul concept de management al lockurilor. Database lock administration poate coordona numai tranzactiile de tip data base. Transactiile SAP sunt formate din mai multi pasi(screen-uri, dialoguri). Conceptul de lock management al tranzactiilor SAP este implementat utilizand inlantuirea procesor(work process). Programele SAP introduc record-uri intr-o tabela(lock table) in memoria principala a SAP WEB AS. Lock-urile pot fi introduse in tabela numai daca nu exista deja record-uri pentru obiectul ce urmeaza a fi blocat:
In cazul in care work process-urile sunt pe servere diferite si cer acess la aceiasi resursa atunci comunicare se face prin message server:
Lockurile sunt practic obiecte ce trebuie declarate in ABAP Dictionary. Exista mai multe tipuri de lockuri: *de scriere *de scriere extinsa (owner-ul poate adauga drepturi de scriere) *shared locks *optimistic locks( numai pentru afisarea datelor) Cand se cere blocarea unui obiect sistemul verifica tabela de lock-uri. Daca un lock exista atunci accesul la obiect este refuzat. Exista 2 module de functii care sunt folosite pentru a bloca si debloca un obiect: • ENQUEUE_<OBJNAME> • DEQUEUE_<OBJNAME> Lockurile sunt eliberate fie de programul care le-a cerut sau de update-uri. Lockurile eliberate de update sunt pastrate intr-un fisier pentru a putea fi reblocate in cazul in care sistemul pica.( De ex: serverul pica cand se lucreaza la un program, programul ramane in continuare blocat dupa revenire)
6 .Update processing
Principiul update-urilor asincrone: Folosirea comenzii COMMIT inaintea terminarii tranzatiei. Este la alegeare programatorului daca foloseste sau nu aceasta comanda. La intalnirea comenzii schimbarile sunt pastrare intr-o tabela temporara pana cand vor putea fi scrise in baza de date(adica la terminarea transactiei). La terminarea tranzactiei sunt
cititete tabelele temporare si scrise in baza de date. In cazul in care apare o eroare(duplicate key) triggers a roll back. Tabele temporare nu vor fi scrise in baza de date
