SAP R / 3 Architecture
Redaktionellt team
⚡ Smart sammanfattning
SAP R / 3 ArchiTecture är en klient-server-design i tre nivåer som separerar presentations-, applikations- och databasansvar. Den här artikeln förklarar varje lager, ABAP och Java komponentstacken, den dispatcherdrivna inloggningsprocessen och orsakerna SAP valde denna lagermodell.
SAP R / 3 ArchiStrukturen ligger till grund för nästan alla klassiker SAP ERP-distribution. Avsnitten nedan förklarar hur de tre nivåerna samverkar och hur ABAP och Java stackar delar upp arbetet mellan dispatcher, meddelandeserver och databas.
Vad är SAP R/3?
SAP R/3 är ett klient-server-företagssystem byggt på en trestegsarkitektur bestående av tre oberoende lager:
- Presentation
- Ansökan
- Databas
- R står för Realtid bearbetning.
- 3 står för 3-tier arkitektoniskt mönster.
Användarens dator (frontend): Användare får åtkomst till SAP systemet genom SAP GUI eller en webbläsare. Endast frontend-klienten installeras på användarens maskin; applikations- och databasservrar körs separat på dedikerad hårdvara.
Applikationsservrar: Applikationsservrar kör affärslogik. Arbetsbelastningen är fördelad över flera applikationsservrar så att användare får svar snabbare under hög belastning. Dessa servrar körs vanligtvis på fjärrinfrastruktur snarare än på användarnas arbetsstationer.
Databasserver: Databasservern lagrar och hämtar data som svar på SQL frågor genererade av ABAP och Java applikationer. Databasen och applikationstjänsterna kan köras på samma maskin eller på separata fysiska värdar beroende på kapacitetsbehov.
Varför gör SAP Använder R/3 en 3-nivåarkitektur?
Att separera presentation, affärslogik och lagring i tre oberoende nivåer ger SAP R/3 fyra praktiska fördelar jämfört med en- eller tvåvåningskonstruktioner:
- Oberoende skalbarhet: Varje lager kan skalas separat. En flaskhals i affärslogiken löses genom att lägga till applikationsservrar utan att vidröra databasens hårdvara.
- Arbetsbördafördelning: Meddelandeservern belastningsbalanserar inkommande sessioner över applikationsservrar, vilket förhindrar att en enskild server blir en enda tvistepunkt.
- Databasskydd: Slutanvändare ansluter aldrig direkt till databasen. Alla läs- och skrivoperationer går igenom applikationsserverns arbetsprocesser, vilka standardiserar auktoriseringskontroller, låsning och transaktionsloggning.
- Upgrade flexibilitet: Ocuco-landskapet SAP GUI-gränssnittet kan utvecklas (skrivbords-, webbläsar- eller mobilklienter via SAPUI5) utan att ändra applikations- eller databaskod.
Denna separation är också det som möjliggör SAP för att stödja flera databasbackends — inklusive SAP HANA, Oracle, IBM Db2, och Microsoft SQL Server — under samma applikationskodbas.
SAP R/2 vs SAP R/3: Hur ArchiTektur utvecklad
SAP R/2 kördes på en stordator och använde en tvåskiktsarkitektur där användarterminalen kommunicerade direkt med databasen. R/3, som lanserades 1992, infogade ett dedikerat applikationslager mellan klient och databas. De två sida vid sida:
| Aspect | SAP R / 2 | SAP R / 3 |
|---|---|---|
| Architecture | 2-nivåer (stordator + terminal) | 3-nivåer (presentation + applikation + databas) |
| hårdvara | Centraliserad stordator | Distribuerad Unix / Windows / Linux-servrar |
| Skalbarhet | Endast vertikal (större stordator) | Horisontell (lägg till applikationsservrar) |
| Databasåtkomst | Direkt från användarsessionen | Medierad av arbetsprocesser för applikationsservern |
| Programmeringsmodell | Endast ABAP/4 | ABAP och Java sida vid sida |
De återstående avsnitten förklarar vart och ett av de tre R/3-lagren i detalj.
Förstå annorlunda SAP skikt
Figur 1: De tre SAP R/3-lager och trafiken som flyter mellan dem.
Presentationslager
Ocuco-landskapet Presentationslager innehåller de programvarukomponenter som utgör SAP GUI — det grafiska gränssnittet för R/3-systemet. Det är gränssnittet mellan systemet och dess användare och ger en intuitiv layout för att mata in och visa data.
Detta lager vidarebefordrar användarinmatning till applikationsservern och renderar den data den tar emot som svar. Medan SAP Om det grafiska användargränssnittet körs förblir det länkat till en användares terminalsession i R/3-systemet under hela sessionen.
Applikationslager
Ocuco-landskapet Applikationslager består av en eller flera applikationsservrar och en meddelandeserverVarje applikationsserver kör en uppsättning tjänster som kör R/3-affärslogik. I teorin räcker det med en enda applikationsserver; i praktiken distribueras tjänsterna över flera servrar för kapacitet och redundans.
Meddelandeservern koordinerar kommunikationen mellan applikationsservrar. Den vidarebefordrar förfrågningar, tracks applikationsservergrupper och tilldelar en lämplig server när en användare loggar in baserat på aktuell belastning. Det är detta som möjliggör horisontell skalning.
Databaslager
Ocuco-landskapet Databaslager innehåller ett centralt databassystem som lagrar all data som används av R/3-systemet. Databasstacken har två komponenter – databashanteringssystemet (DBMS) och själva databasen. SAP levererar sitt eget DBMS, SAP HANA, och stöder även alla större kommersiella databaser (Oracle, IBM Db2, Microsoft SQL Server).
All R/3-data – anpassning av inställningar, applikationskod, skärmdefinitioner, menyer, funktionsmoduler och runtime-data – finns i den här databasen. Programkod och designobjekt finns i en särskild sektion som kallas R/3-arkivet; dessa "förrådsobjekt" är vad ABAP Workbench läser, skriver och transporterar mellan system.
Förstå komponenterna i SAP R/3 3-lager Architecture
Figur 2: ABAP + Java systemarkitektur som visar hur de två stackarna delar infrastruktur.
En modern SAP NetWeaver-instansen kan vara värd för både ABAP och Java stackar. Komponenterna nedan visar hur varje stack hanterar sin egen dispatching samtidigt som den delar gateway-, ICM- och JCO-bryggan för kommunikation mellan stackar.
| Komponent | Stack | Roll |
|---|---|---|
| Meddelandeserver (ABAP) | ABAP | Koordinerar kommunikationen mellan distribuerade dispatchers i ABAP-system och balanserar belastningen mellan instanser. |
| Avsändarkö | ABAP | Buffer som håller inkommande förfrågningar tills en arbetsprocess blir ledig. |
| Avsändare | ABAP | Hämtar förfrågningar från kön och tilldelar var och en till lämplig arbetsprocesstyp. |
| ABAP-arbetsprocesser | ABAP | Utför dialogrutesteg i R/3-applikationer. Typer inkluderar dialog, uppdatering, bakgrund, spool och köläggning. |
| Gateway | Delade | Möjliggör kommunikation mellan SAP system och mellan SAP och externa system via RFC. |
| Minnesrör | Delade | Överför data mellan Internet Communication Manager (ICM) och ABAP-arbetsprocesser. |
| Meddelandeserver (Java) | Java | koordinater Java avsändare och serverprocesser; möjliggör kommunikation inom Java körtidskluster. |
| Köa servern | Java | Hanterar logiska lås som ställts in av Java applikationskod som körs inuti en serverprocess. |
| Centrala tjänster | Java | En speciell Java klusterinstans som hanterar låsning och meddelanden mellan processer. En ”instans” är en grupp resurser (minne, arbetsprocesser etc.). |
| Java Avsändare | Java | Tar emot kundförfrågningar och vidarebefordrar dem till Java serverprocesser. |
| SDM | Java | Software Deployment Manager — installerar J2EE-komponenter på Java stack. |
| Java Serverprocesser | Java | Bearbeta ett stort antal förfrågningar samtidigt med hjälp av multi-threading. |
| ICM | Delade | Internet Communication Manager — aktiverar HTTP-, HTTPS- och SMTP-trafik så att SAP kan nås från en webbläsare. |
| JCO | bro | Java Kontakt — hanterar kommunikationen mellan Java dispatchern och ABAP-dispatchern när båda stackarna körs sida vid sida. |
Figur 3: Kategorier av ABAP-arbetsprocesser (Dialog, Uppdatering, Bakgrund, Spool, Enqueue).
Hur SAP Fungerar inloggningsprocessen?
Figur 4: Steg-för-steg-flöde för en användarinloggning genom SAP R/3-dispatcher och arbetsprocesslager.
Steg 1) Användaren klickar på SAP system från SAP GUI; begäran vidarebefordras till avsändare.
Steg 2) Begäran hamnar i förfrågningskön. Ledaren följer en först in, först ut regel och tilldelar begäran till nästa tillgängliga arbetsprocess.
Steg 3) En arbetsprocess av lämplig typ tilldelas. En användare som loggar in får en Dialog-arbetsprocess; en bakgrundsrapport får en Bakgrundsarbetsprocess; en UPDATE-sats skickas till en Uppdatera-arbetsprocess. Åtgärden avgör typen av arbetsprocess.
Steg 4) När dialogarbetsprocessen har tilldelats sparas användarens behörigheter och aktuella inställningar. rullade in till delat minne så att arbetsprocessen kan agera på användarens data. När dialogsteget är klart, är dessa data utrullad för att frigöra minne för nästa användare. Ett "dialogsteg" är förflyttningen från en skärm till en annan inuti en transaktion.
Steg 5) Arbetsprocessen letar först efter den begärda datan i bufferten. Att hitta den där kallas en slå och undviker en databas-tur och retur, vilket förbättrar svarstiden. Att inte hitta den utlöser en Fröken och en databasläsning. En hög träff-till-miss-kvot är den enskilt största bidragande faktorn till SAP prestanda.
Steg 6) Eventuell återstående data hämtas från databasen och det kombinerade resultatet skickas tillbaka till SAP GUI via dispatchern.
Steg 7) Användarens sessionsdata tas bort från det delade minnet i en slutlig utrullning, vilket frigör minnesområdet för nästa begäran.
Samma avsändare → kö → arbetsprocess → buffert → utrullningscykel upprepas för varje användarinteraktion, oavsett om begäran kommer från SAP GUI, en webbläsare via ICM eller ett externt system via gatewayen.
