SAP R / 3 Architectură

SAP R / 3 ArchiTextura stă la baza aproape fiecărui clasic SAP Implementare ERP. Secțiunile de mai jos explică modul în care interacționează cele trei niveluri și cum funcționează ABAP și Java Stivele împart munca între dispecer, serverul de mesaje și baza de date.

Ce Este SAP R/3?

SAP R/3 este un sistem client-server pentru întreprinderi construit pe un arhitectura pe trei niveluri alcătuită din trei straturi independente:

1. Despre Institutul Bruno Comby
2. Aplicatii
3. Baza de date

• R standuri pentru În timp real prelucrare.
• 3 înseamnă „ Pe 3 niveluri model arhitectural.

PC-ul utilizatorului (front-end): Utilizatorii accesează SAP sistem prin SAP Interfață grafică sau un browser web. Pe mașina utilizatorului este instalat doar clientul front-end; serverele de aplicații și baze de date rulează separat pe hardware dedicat.

Servere de aplicații: Serverele de aplicații execută logica de business. Volumul de lucru este distribuit pe mai multe servere de aplicații, astfel încât utilizatorii primesc răspunsuri mai rapid în condiții de încărcare mare. Aceste servere rulează de obicei pe infrastructură la distanță, mai degrabă decât pe stațiile de lucru ale utilizatorilor.

Serverul bazei de date: Serverul de baze de date stochează și preia date ca răspuns la SQL interogări generate de ABAP și Java aplicații. Serviciile de baze de date și aplicații pot rula pe aceeași mașină sau pe gazde fizice separate, în funcție de nevoile de capacitate.

De ce? SAP R/3 folosește o arhitectură pe 3 niveluri?

Separarea prezentării, logicii de business și stocării în trei niveluri independente oferă SAP Patru avantaje practice ale R/3 față de modelele cu un singur nivel sau cu două niveluri:

• Scalabilitate independentă: Fiecare strat poate fi scalat separat. O problemă în logica de business este rezolvată prin adăugarea de servere de aplicații fără a atinge hardware-ul bazei de date.
• Distribuția volumului de muncă: Serverul de mesaje echilibrează sarcina sesiunilor primite pe serverele de aplicații, împiedicând orice server să devină un singur punct de dispută.
• Protecția bazei de date: Utilizatorii finali nu se conectează niciodată direct la baza de date. Toate operațiunile de citire și scriere se desfășoară prin procesele de lucru ale serverului de aplicații, care standardizează verificările de autorizare, blocarea și înregistrarea în jurnal a tranzacțiilor.
• Upgrade flexibilitate: SAP Interfața grafică interfacială poate evolua (clienți desktop, browser sau mobil prin intermediul SAPUI5) fără a modifica codul aplicației sau al bazei de date.

Această separare este, de asemenea, ceea ce permite SAP pentru a suporta mai multe backend-uri de baze de date — inclusiv SAP HANA, Oracle, IBM Db2 și Microsoft SQL Server — sub aceeași bază de cod a aplicației.

SAP R/2 vs. SAP R/3: Cum ArchiTextură evoluată

SAP R/2 rula pe un mainframe și folosea o arhitectură pe două niveluri în care terminalul utilizatorului comunica direct cu baza de date. R/3, lansat în 1992, a introdus un strat de aplicație dedicat între client și baza de date. Cele două, alăturate:

Aspect	SAP R / 2	SAP R / 3
Architectură	2 niveluri (mainframe + terminal)	3 niveluri (prezentare + aplicație + bază de date)
Piese metalice	Mainframe centralizat	Unix distribuit / Windows / Servere Linux
Scalabilitate	Numai vertical (mainframe mai mare)	Orizontal (adăugați servere de aplicații)
Acces la baza de date	Direct din sesiunea utilizatorului	Mediat de procesele de lucru ale serverului de aplicații
Model de programare	Doar ABAP/4	ABAP și Java unul lângă altul

Secțiunile rămase explică în detaliu fiecare dintre cele trei straturi R/3.

Înțelegerea diferită SAP straturi

Figura 1: Cei trei SAP Straturile R/3 și traficul care circulă între ele.

Strat de prezentare

Strat de prezentare conține componentele software care alcătuiesc SAP GUI — interfața grafică a sistemului R/3. Este interfața dintre sistem și utilizatorii săi, oferind un aspect intuitiv pentru introducerea și afișarea datelor.

Acest strat transmite datele introduse de utilizator către serverul de aplicații și redă datele pe care le primește ca răspuns. În timp ce SAP În timp ce interfața grafică rulează, aceasta rămâne legată de sesiunea terminală a utilizatorului în sistemul R/3 pe durata acelei sesiuni.

Strat de aplicație

Strat de aplicație constă dintr-unul sau mai multe servere de aplicații și un server de mesajeFiecare server de aplicații rulează un set de servicii care execută logica de business R/3. În teorie, un singur server de aplicații este suficient; în practică, serviciile sunt distribuite pe mai multe servere pentru capacitate și redundanță.

Serverul de mesaje coordonează comunicarea dintre serverele de aplicații. Acesta transmite cereri, tracks grupuri de servere de aplicații și atribuie un server corespunzător atunci când un utilizator se conectează, pe baza încărcării curente. Acest lucru face posibilă scalarea orizontală.

Stratul bazei de date

Stratul bazei de date găzduiește un sistem central de baze de date care stochează toate datele utilizate de sistemul R/3. Stiva bazei de date are două componente - sistemul de gestionare a bazelor de date (DBMS) și baza de date în sine. SAP livrează propriul SGBD, SAP HANAși, de asemenea, acceptă toate bazele de date comerciale importante (Oracle, IBM Db2, Microsoft SQL Server).

Toate datele R/3 — setările de personalizare, codul aplicației, definițiile ecranului, meniurile, modulele funcționale și datele de execuție — se află în această bază de date. Codul programului și obiectele de proiectare se află într-o secțiune specială numită Depozit R/3aceste „obiecte de repozitoriu” sunt ceea ce ABAP Workbench citește, scrie și transportă între sisteme.

Înțelegerea componentelor SAP R/3 3-nivel Architectură

Figura 2: ABAP + Java arhitectura sistemului care arată modul în care cele două stive partajează infrastructura.

Un modern SAP Instanța NetWeaver poate găzdui atât ABAP, cât și Java stive. Componentele de mai jos arată cum își gestionează fiecare stivă propria dispecerizare, partajând gateway-ul, ICM-ul și puntea JCO pentru comunicarea între stive.

Component	Stivui	Rol
Server de mesaje (ABAP)	ABAP	Coordonează comunicarea între dispecerii distribuiți din Sistem ABAP și echilibrează sarcina între instanțe.
Coadă de așteptare pentru dispecer	ABAP	Buffer care reține cererile primite până când un proces de lucru devine liber.
dispecer	ABAP	Extrage cereri din coadă și le atribuie pe fiecare tip de proces de lucru corespunzător.
Procese de lucru ABAP	ABAP	Executați pași de dialog în aplicațiile R/3. Tipurile includ Dialog, Actualizare, Fundal, Spool și Coadă.
Poartă	Shared	Permite comunicarea între SAP sisteme și între SAP și sisteme externe prin RFC.
Țevi de memorie	Shared	Transportă date între Internet Communication Manager (ICM) și procesele de lucru ABAP.
Server de mesaje (Java)	Java	coordonate Java dispeceri și procese server; permite comunicarea în interiorul Java cluster de execuție.
Server de coadă	Java	Gestionează blocările logice setate de Java codul aplicației care rulează în interiorul unui proces server.
Servicii Centrale	Java	Un special Java instanță de cluster care gestionează blocarea și mesageria interproces. O „instanță” este un grup de resurse (memorie, procese de lucru etc.).
Java dispecer	Java	Preia solicitările clienților și le transmite către Java procese ale serverului.
SDM	Java	Software Deployment Manager — instalează componente J2EE pe Java grămadă.
Java Procese server	Java	Procesează simultan un număr mare de cereri folosind multi-threading.
ICM	Shared	Manager de comunicare prin Internet — activează traficul HTTP, HTTPS și SMTP, astfel încât SAP poate fi accesat dintr-un browser.
JCO	Bridge	Java Conector — gestionează comunicarea dintre Java dispecer și dispecerul ABAP atunci când ambele stive rulează una lângă alta.

Figura 3: Categorii de procese de lucru ABAP (Dialog, Actualizare, În fundal, Spool, Coadă).

Cum SAP Procesul de conectare funcționează?

Figura 4: Fluxul pas cu pas al conectării unui utilizator prin SAP dispecer R/3 și straturi de proces de lucru.

Pas 1) Utilizatorul dă clic pe SAP sistem de la SAP GUI; cererea este transmisă către dispecer.

Pas 2) Cererea ajunge în coadă de cereriDispecerul urmează o primul intrat, primul ieşit regulă și atribuie cererea următorului proces de lucru disponibil.

Pas 3) Este atribuit un proces de lucru de tipul corespunzător. Un utilizator care se conectează primește un proces de lucru de tip Dialog; un raport de fundal primește un proces de lucru de tip Background; o instrucțiune UPDATE este transmisă unui proces de lucru Update. Acțiunea dictează tipul de proces de lucru.

Pas 4) Odată ce procesul de lucru Dialog este atribuit, autorizațiile utilizatorului și setările curente sunt rostogolit în în memoria partajată, astfel încât procesul de lucru să poată acționa asupra datelor utilizatorului. Când pasul de dialog se termină, acele date sunt a ieșit pentru a elibera memoria pentru următorul utilizator. Un „pas de dialog” este trecerea de la un ecran la altul în cadrul unei tranzacții.

Pas 5) Procesul de lucru caută mai întâi datele solicitate în buffer. Găsirea lor acolo se numește... lovit și evită o călătorie dus-întors prin baza de date, îmbunătățind timpul de răspuns. Negăsirea acestuia declanșează o rata și o citire a bazei de date. Un raport ridicat de rezultate pozitive și negative este cel mai mare factor care contribuie la SAP performanță.

Pas 6) Orice date rămase sunt interogate din baza de date, iar rezultatul combinat este trimis înapoi către SAP Interfață grafică (GUI) prin intermediul dispecerului.

Pas 7) Datele sesiunii utilizatorului sunt eliminate din memoria partajată într-o etapă finală roll-out, eliberând zona de memorie pentru următoarea solicitare.

Același dispecer → coadă → proces de lucru → buffer → ciclu de lansare se repetă pentru fiecare interacțiune a utilizatorului, indiferent dacă solicitarea provine de la SAP GUI, un browser prin ICM sau un sistem extern prin gateway.

Întrebări frecvente