Vissza az előzőleg látogatott oldalra (nem elérhető funkció)Vissza a modul kezdőlapjáraUgrás a tananyag előző oldaláraUgrás a tananyag következő oldaláraFogalom megjelenítés (nem elérhető funckió)Fogalmak listája (nem elérhető funkció)Oldal nyomtatása (nem elérhető funkció)Oldaltérkép megtekintéseSúgó megtekintése

Tanulási útmutató

Összefoglalás

Mielőtt elsajátítanánk az SAP programozás alapjait, meg kell ismerkedni a rendszer architektúrális felépítésével.

Követelmény

Nincsenek előzetes követelmények

Önállóan megoldható feladatok

Az SAP rendszer architektúrája

Mielőtt megismerkednénk az ABAP programozási nyelvvel, érdemes röviden áttekinteni az SAP rendszer felépítését.

Anélkül, hogy jelen jegyzetünkben ismertetnénk az SAP vállalatirányítási rendszert az olvasónak tudnia kell, hogy SAP-t valószínűleg nem fog használni a sarki ABC, ugyanakkor SAP segítségével kezeli vállalati adatait, optimalizálja vállalkozása működését például az Apple, az E.ON, az IBM, a MOL, a Mercedes, a Procter and Gamble, a PepsiCo, a Nike, és a Wal-Mart is. Piaci részesedése a világon 25,5 %-os (Forrás: Gartner: Market Share Analisys: ERP Software, Worldwide 2011).

Mivel egy ilyen rendszerben egyszerre több felhasználó is konkurensen dolgozik, az adatok mindenféleképpen szerveren kell, hogy tárolódjanak. Fontos szempont továbbá, hogy a vállalati információk, illetve az operatív munkához szükséges alkalmazások távolról, bármilyen eszközről elérhetőek legyenek.

Az SAP háromrétegű architektúrájaAz SAP architektúrája

Az SAP rendszerek háromrétegű kliens-szerver architektúrát használnak, a középpontban az alkalmazás-szerverrel. Az SAP kétféle alkalmazás-szervert szolgáltat, SAP NetWeaver Application Server ABAP illetve SAP NetWeaver Application Server Java néven. Jelen jegyzetünkben az SAP NetWeaver Application Server ABAP-al foglalkozunk. Egyrészt ehhez ABAP nyelven kell fejleszteni, másrészt történeti okokból is ez az elterjedtebb.

Megjegyezzük, hogy kialakítható olyan környezet is, melyben mindkét szerver elérhető.

A három-rétegű tagolás célja a skálázhatóság. Üzleti környezetben hatalmas adatmennyiség, több terra-byte kerül tárolásra és átdolgozásra napról napra, ezért egy nagy előnye az SAP-nak a szinte korlátlan számú, többször több 100 applikációs szerver használata, mely így tetszőlegesen skálázhatóvá teszi a rendszert.

A prezentációs réteg az interfész a felhasználók felé, a megjelenítésért felelős. Fogadja a felhasználók inputjait, továbbítja az applikációs szervernek. Megjeleníti az összeállított adatokat és képernyőket. Az üzleti környezetben legelterjedtebb képernyőfajtákat, SAP környezeten Dynpro-nak hívjuk.

SAP GUI a bejelentkezés utánSAP GUI a bejelentkezés után

A kernel és a bázis modulok alkotják (Alkalmazási szint) azt a résztét az applikációs szervernek, amelyek mind az adatbázis mind a prezentációs réteget érintik. Felelősek a felhasználók kezelésért, a munkafolyamatok kezelésért, más rendszerekkel való összeköttetésekért, mindamellett rendszer adminisztrációs folyamatokat is futtatnak. A kernel-ben futnak azok a folyamatok, vagy más néven virtual machine-ek amelyek értelmezik a byte kódot, ezáltal platform függetlenné téve a rendszert. Az alkalmazás-szerver hajtja végre a programokat.

Az alkalmazás-szerver többek között az alábbiakat biztosítja számunkra:

Az SAP rétegek szolgáltatásaiAz SAP rétegek szolgáltatásai

Applikációs szerverből korlátlan számú lehet, közöttük a diszpécser, mint forgalomirányító osztja szét a feladatokat. Az alkalmazás-szerver tartalmazza azon szoftverkomponenseket, melyeket a kliens szolgáltatásként elérhet, ezen futnak tehát a programok, itt hajtódnak végre az üzleti folyamatok. Az adatbázis-szerver felé is az alkalmazás-szerver csatlakozik. Azért, hogy az alkalmazás-szerver elrejtse előlünk az adatbázis-kezelő rendszert jellemzően nem natív SQL kódokat, hanem úgynevezett OpenSQL kódokat írunk, majd ezeket az alkalmazás-szerveren lévő adatbázis-interfész az adatbázis-szerverhez illeszkedő natív SQL kóddá alakítja. Noha lehetőségünk van natív SQL kódokat is futtatni a szerveren, az OpenSQL használata több szempontból előnyösebb. Ezekről később, a Táblakezelés ABAP-ban c. fejezetben lesz szó.

Adatbázis absztrakcióAdatbázis absztrakció

Az adatbázis réteg a rendszer lelke, minden itt tárolódik. Törzsadatok, mozgásadagok, a programunk kódjai, a használt képernyőink és még maga az fejlesztő környezet is.

Az architektúra egyik előnye, hogy az alkalmazás-szerverek és az adatbázis-szerverek tetszőlegesen skálázhatóak, nem terhelik a kliens erőforrásait csak a szükséges mértékben. Az adatbázis- illetve operációs rendszer szolgáltatásait pedig úgynevezett work processzeken keresztül érhetjük el, illetve éri el a szerver. ABAP programozási szempontból úgy, hogy nem kell azzal foglalkoznunk, hogy az alkalmazás-szerver milyen operációs rendszeren fut, illetve milyen adatbáziskezelő-rendszerben tárolja az adatokat, ezeket ugyanis a környezet elfedi előlünk.

A prezentációs rétegen egy úgynevezett SAP GUI-t kell telepíteni, melybe bejelentkezve elérhetőek az alkalmazás-szerver szolgáltatásai a diszpécser szálakon keresztül. A diszpécser (Dispatcher) feladata a prezentációs interfész és a munkafolyamatok közötti kapcsolattartás vezérlése, biztosítja a kapcsolatot a prezentációs szerverrel, megszervezi a kommunikációs folyamatokat, továbbá felel a tranzakció-megterhelés egyenletes elosztásáért a munkafolyamatok között.

További megoldás, ha a szerverre az SAP Enterprise Portal-t telepítjük, ekkor egy böngészőn keresztül is elérhetőek bizonyos szolgáltatások. A fejlesztőknek lehetőségük van mobil alkalmazásokat is fejleszteni az SAP Mobility szolgáltatásain keresztül. Fejlesztéshez azonban mindenféleképpen szükséges az SAP GUI telepítése a kliens gépre, mert a fejlesztői környezet csak azon keresztül érhető el. Ahogy később látni fogjuk az SAP felhasználói felülete teljesen eltér az eddig megszokottól, ennek lesz majd előnye is, hiszen mindent ABAP-ban írtak és bármilyen programnak megnézhetjük a forráskódját.

Általánosságban elmondható, hogy az ABAP fejlesztés is a központi szerveren történik a kliensen keresztül, noha arra van lehetőségünk, hogy a kliens oldali fejlesztői környezetet használjuk, sőt 2012-ben megjelent az ABAP Eclipse kiegészítés is. Ettől függetlenül minden, legyen az valamilyen üzleti folyamat logikája, vagy bármilyen fejlesztői eszköz, minden az alkalmazás-szerveren fut.

A programok a szerveren tárolódnak, a verziókezelés, a debuggolás, a futtatás még a legegyszerűbb program esetén is mind-mind az alkalmazás-szerveren történik. Nincs szükség tehát deployolásra sem, sőt az elkészült programot sem tudjuk lementeni a kliensünkre, erre azonban nincs is szükség, hiszen az alkalmazás-szerverek közötti program és egyéb obejktumok átvitelére az úgynevezett transzportálást használjuk.

Természetesen az SAP nem az ABAP kódot futtatja, sőt ahogy majd később látni fogjuk például a táblakezelésnél, több olyan beállítási lehetőségünk van, melyeket adatbázis-kezelő rendszerekben nem lehet eltárolni. A programok aktiválását követően az első futtatáskor egy platform-független bájtkód generálódik, melyet az interpreter lefuttat. Ezzel azonban fejlesztőként nem fogunk találkozni, nekünk mindig ABAP-ban kell módosításokat végrehajtanunk. Hasonlóan adatbázis-objektumok aktiválásakor történik például a tábla létrehozása, módosítása az adatbázisban, addig csupán az alkalmazás-szerver tárolja el számunkra a módosításokat (amennyiben azokaz elmentettük) a szerveren dolgozók azonban még a régi objektumokat használják. Ez azt is jelenti, hogy más környezetektől eltérően nincs szükség a módosítandó fejlesztési objektumok (programok, táblák, adattípusok, stb.) kivételére (chek-in), majd a módosítás elvégzése után a rendszerbe visszatöltésére (chekc-out), egyszerűen amennyiben jogunk van rá, módosíthatjuk az objektumot, majd aktiválást követően a felhasználók már a legújabb verziót használják majd.

Azzal is tisztában kell lennünk, hogy minden objektum, tehát például a programkódok – a teljes alkalmazás-szerver programjai is - (különböző verzióikkal), a vállalati adatok, a beállítások (customizing data) mind-mind az adatbázisban tárolódnak.

A diszpécser működése

Egy kérés feldolgozásának menete az alábbi:

1. A DIAG protokollon keresztül eljut a kérés a diszpécserig.

2. A diszpécser a kérést egy várakozósorba teszi, majd szétosztja a feladatokat a munkafolyamatok között.

3. A munkafolyamat értelmezi, és végrehajt egy dialóguslépést, majd visszateszi a várakozósorba, valamint ha van, akkor átadja a diszpécsernek a kért kisegítő feldolgozás azonosítóját, például UPD vagy SPOOL.

4. A diszpécser a feldolgozott lépés eredményét megjelenítésre továbbítja a kliensnek.

5. A SAP GUI értelmezi a kapott adatokat, és feltölti a képernyőt.

Diszpécser működéseDiszpécser működése

Vissza a tartalomjegyzékhez

Munkafolyamatok – Work Processes

A munkafolyamatok egymás utáni dialóguslépéseket hajtanak végre, egy képernyő feldolgozása vagy megjelenítése során. A munkafolyamatok száma a várható konkurens felhasználók száma szerint definiálható. Ha nincs szabad munkafolyamat, akkor a felhasználóknak várakozniuk kell. Sok felhasználó esetén ezért célszerű több alkalmazásszervert beállítani. Szintén munkafolyamatok felelősek az adatbázis-kapcsolatért, mindezt automatikusan, anélkül, hogy az adatbázis-felügyelettel foglalkozunk kellene.

Főbb részei:

Fontosabb munkafolyamatok:

Vissza a tartalomjegyzékhez

Fel a lap tetejére
Új Széchenyi terv
A projekt az Európai Unió támogatásával, az Európai Szociális Alap társfinanszirozásával valósul meg.