SAP R / 3 Architecture
Jessica Blake
⚡ Smart opsummering
SAP R / 3 ArchiTektur er et trelags klient-server-design, der adskiller præsentations-, applikations- og databaseansvar. Denne artikel forklarer hvert lag, ABAP og Java komponentstakken, den dispatcher-drevne logonproces og årsagerne SAP valgte denne lagdelte model.
SAP R / 3 ArchiTeksturen ligger til grund for næsten alle klassikere SAP ERP-implementering. Afsnittene nedenfor forklarer, hvordan de tre niveauer interagerer, og hvordan ABAP og Java Stakke deler arbejdet mellem dispatcher, meddelelsesserver og database.
Hvad er SAP R/3?
SAP R/3 er et klient-server-virksomhedssystem bygget på en trelagsarkitektur bestående af tre uafhængige lag:
- Præsentation
- Anvendelse
- Database
- R står for Realtid forarbejdning.
- 3 står for 3-lags arkitektonisk mønster.
Brugerens pc (frontend): Brugere får adgang til SAP systemet gennem SAP GUI eller en webbrowser. Kun frontend-klienten er installeret på brugerens maskine; applikations- og databaseservere kører separat på dedikeret hardware.
Applikationsservere: Applikationsservere udfører forretningslogik. Arbejdsbyrden er fordelt på tværs af flere applikationsservere, så brugerne modtager svar hurtigere under tung belastning. Disse servere kører typisk på fjerninfrastruktur i stedet for brugerarbejdsstationer.
Databaseserver: Databaseserveren lagrer og henter data som svar på SQL forespørgsler genereret af ABAP og Java applikationer. Databasen og applikationstjenesterne kan køre på den samme maskine eller på separate fysiske værter afhængigt af kapacitetsbehov.
Hvorfor gør SAP Bruger R/3 en 3-lags arkitektur?
Ved at opdele præsentation, forretningslogik og lagring i tre uafhængige niveauer får man SAP R/3 fire praktiske fordele i forhold til design med én eller to niveauer:
- Uafhængig skalerbarhed: Hvert lag kan skaleres separat. En flaskehals i forretningslogik løses ved at tilføje applikationsservere uden at røre ved databasehardwaren.
- Fordeling af arbejdsbyrde: Meddelelsesserveren belastningsfordeler indgående sessioner på tværs af applikationsservere og forhindrer dermed, at en enkelt server bliver et enkelt stridspunkt.
- Databasebeskyttelse: Slutbrugere opretter aldrig direkte forbindelse til databasen. Alle læse- og skriveoperationer går gennem applikationsserverens arbejdsprocesser, som standardiserer godkendelseskontroller, låsning og transaktionslogning.
- Upgrade fleksibilitet: SAP GUI-frontend kan udvikles (desktop-, browser- eller mobilklienter via SAPUI5) uden at ændre applikations- eller databasekode.
Denne adskillelse er også det, der tillader SAP at understøtte flere database-backends — inklusive SAP HANA, Oracle, IBM Db2, og Microsoft SQL Server — under den samme applikationskodebase.
SAP R/2 vs. SAP R/3: Hvordan ArchiTektur udviklet
SAP R/2 kørte på en mainframe og brugte en todelt arkitektur, hvor brugerterminalen kommunikerede direkte med databasen. R/3, lanceret i 1992, indsatte et dedikeret applikationslag mellem klient og database. De to side om side:
| Aspect | SAP R / 2 | SAP R / 3 |
|---|---|---|
| Architecture | 2-lags (mainframe + terminal) | 3-lags (præsentation + applikation + database) |
| Hardware | Centraliseret mainframe | Distribueret Unix / Windows / Linux-servere |
| Skalerbarhed | Kun vertikal (større mainframe) | Horisontal (tilføj applikationsservere) |
| Adgang til database | Direkte fra brugersessionen | Medieret af arbejdsprocesser på applikationsserveren |
| Programmeringsmodel | Kun ABAP/4 | ABAP og Java side om side |
De resterende afsnit forklarer hvert af de tre R/3-lag i detaljer.
Forståelse anderledes SAP lag
Figur 1: De tre SAP R/3-lagene og den trafik, der flyder mellem dem.
Præsentationslag
Præsentationslag indeholder de softwarekomponenter, der udgør SAP GUI — den grafiske brugerflade på R/3-systemet. Det er grænsefladen mellem systemet og dets brugere og giver et intuitivt layout til indtastning og visning af data.
Dette lag videresender brugerinput til applikationsserveren og gengiver de data, det modtager som svar. Mens SAP Hvis den grafiske brugergrænseflade kører, forbliver den knyttet til en brugers terminalsession i R/3-systemet, så længe sessionen varer.
Applikationslag
Applikationslag består af en eller flere applikationsservere og en beskedserverHver applikationsserver kører et sæt tjenester, der udfører R/3-forretningslogik. I teorien er en enkelt applikationsserver tilstrækkelig; i praksis er tjenester fordelt på tværs af flere servere af kapacitet og redundanshensyn.
Meddelelsesserveren koordinerer kommunikationen mellem applikationsservere. Den videresender anmodninger, tracks applikationsservergrupper og tildeler en passende server, når en bruger logger på, baseret på den aktuelle belastning. Dette er det, der muliggør horisontal skalering.
Database lag
Database lag huser et centralt databasesystem, der lagrer alle data, der bruges af R/3-systemet. Databasestakken har to komponenter - databasestyringssystemet (DBMS) og selve databasen. SAP sender sit eget DBMS, SAP HANA, og understøtter også alle større kommercielle databaser (Oracle, IBM Db2, Microsoft SQL Server).
Alle R/3-data – tilpasning af indstillinger, programkode, skærmdefinitioner, menuer, funktionsmoduler og runtime-data – findes i denne database. Programkode og designobjekter findes i en særlig sektion kaldet R/3-arkivDisse "repository-objekter" er det, som ABAP Workbench læser, skriver og transporterer mellem systemer.
Forstå komponenterne i SAP R/3 3-lags Architecture
Figur 2: ABAP + Java Systemarkitektur, der viser, hvordan de to stakke deler infrastruktur.
Et moderne SAP NetWeaver-instansen kan være vært for både ABAP og Java stakke. Komponenterne nedenfor viser, hvordan hver stak håndterer sin egen forsendelse, mens den deler gateway-, ICM- og JCO-broen til kommunikation på tværs af stakker.
| Component | Stak | roller |
|---|---|---|
| Meddelelsesserver (ABAP) | ABAP | Koordinerer kommunikationen mellem distribuerede dispatchere i ABAP system og balancerer belastningen på tværs af instanser. |
| Dispatcherkø | ABAP | Buffer der tilbageholder indgående anmodninger, indtil en arbejdsproces bliver ledig. |
| Dispatcher | ABAP | Henter anmodninger fra køen og tildeler hver enkelt til den relevante arbejdsprocestype. |
| ABAP-arbejdsprocesser | ABAP | Udfør dialogtrin i R/3-applikationer. Typer omfatter Dialog, Opdatering, Baggrund, Spool og Enqueue. |
| Gateway | delt | Muliggør kommunikation mellem SAP systemer og mellem SAP og eksterne systemer via RFC. |
| Hukommelsesrør | delt | Overfør data mellem Internet Communication Manager (ICM) og ABAP-arbejdsprocesser. |
| Meddelelsesserver (Java) | Java | koordinater Java dispatchere og serverprocesser; muliggør kommunikation inden for Java runtime-klynge. |
| Sæt serveren i kø | Java | Administrerer logiske låse indstillet af Java applikationskode, der kører inde i en serverproces. |
| Centrale tjenester | Java | En speciel Java klyngeinstans, der håndterer låsning og meddelelser mellem processer. En "instans" er en gruppe af ressourcer (hukommelse, arbejdsprocesser osv.). |
| Java Dispatcher | Java | Modtager kundehenvendelser og videresender dem til Java serverprocesser. |
| SDM | Java | Software Deployment Manager — installerer J2EE-komponenter på Java stak. |
| Java Serverprocesser | Java | Behandl et stort antal anmodninger samtidigt ved hjælp af multi-threading. |
| ICM | delt | Internet Communication Manager — aktiverer HTTP-, HTTPS- og SMTP-trafik, så SAP kan nås fra en browser. |
| JCO | Bro | Java Stik — håndterer kommunikationen mellem Java dispatcheren og ABAP-dispatcheren, når begge stakke kører side om side. |
Figur 3: Kategorier af ABAP-arbejdsprocesser (Dialog, Opdatering, Baggrund, Spool, Enqueue).
Hvordan SAP Virker logon-processen?
Figur 4: Trinvis brugerloginproces gennem SAP R/3-dispatcher og arbejdsproceslag.
Trin 1) Brugeren klikker på SAP system fra SAP GUI; anmodningen videresendes til afsender.
Trin 2) Anmodningen lander i anmodningskø. Disponenten følger en først ind, først ud regel og tildeler anmodningen til den næste tilgængelige arbejdsproces.
Trin 3) En arbejdsproces af den relevante type tildeles. En bruger, der logger på, modtager en Dialog-arbejdsproces; en baggrundsrapport modtager en Baggrundsarbejdsproces; en UPDATE-erklæring sendes til en Opdater-arbejdsproces. Handlingen dikterer typen af arbejdsproces.
Trin 4) Når Dialog-arbejdsprocessen er tildelt, gemmes brugerens autorisationer og aktuelle indstillinger. rullet ind til delt hukommelse, så arbejdsprocessen kan reagere på brugerens data. Når dialogtrinnet er afsluttet, overføres disse data rullet ud for at frigøre hukommelse til den næste bruger. Et "dialogtrin" er bevægelsen fra én skærm til en anden i en transaktion.
Trin 5) Arbejdsprocessen søger først efter de ønskede data i bufferen. At finde dem der kaldes en ramt og undgår en databasetur rundt, hvilket forbedrer svartid. Hvis man ikke finder den, udløser det en glip af og en databaselæsning. En høj hit-to-miss-ratio er den største enkeltstående bidragyder til SAP ydelse.
Trin 6) Eventuelle resterende data forespørges fra databasen, og det kombinerede resultat sendes tilbage til SAP GUI via dispatcheren.
Trin 7) Brugerens sessionsdata fjernes fra den delte hukommelse i en endelig Rul ud, hvilket frigiver hukommelsesområdet til den næste anmodning.
Den samme dispatcher → kø → arbejdsproces → buffer → udrulningscyklus gentages for hver brugerinteraktion, uanset om anmodningen stammer fra SAP GUI, en browser via ICM eller et eksternt system via gatewayen.
