SAP Arch Selmeci AMK

ALBA REGIA MŰSZAKI KAR
Selmeci Attila
SAP technológiai architektúra
ÓE-AREK 8014
Budapest, 2015.
SAP technológiai architektúra Bevezetés
Tartalom
1 BEVEZETÉS ................................................................................................................................................6
2 SAP ERP RENDSZER JELLEMZŐI..........................................................................................................7
2.1 SAP RENDSZERJELLEMZŐK ......................................................................................................................7

2.1.1 MODULÁRIS FELÉPÍTÉS ............................................................................................................................................ 7
2.1.2 VALÓS IDEJŰ MŰKÖDÉS ............................................................................................................................................ 8
2.1.3 RUGALMASSÁG ........................................................................................................................................................... 9
2.1.4 EGYSÉGES FELÜLET ................................................................................................................................................ 10
2.1.5 FOLYAMATOK AUTOMATIZÁLÁSA (WORKFLOW) ............................................................................................ 11
2.1.6 VÁLTOZÁSOK KÖVETÉSE ....................................................................................................................................... 12
2.1.7 NYELVFÜGGETLENSÉG .......................................................................................................................................... 12
2.1.8 ARCHIVÁLÁS ÁLTALÁBAN ..................................................................................................................................... 13
2.1.9 ADATTÁROLÁS, PBS TÁMOGATÁS....................................................................................................................... 14
2.1.10 RENDSZERFÜGGETLENSÉG................................................................................................................................. 14
2.1.11 ADMINISZTRÁCIÓ ................................................................................................................................................ 15
2.1.12 SZTENDERD SAP MONITOROZÁS ...................................................................................................................... 15
2.1.13 DOKUMENTUMKEZELÉS ..................................................................................................................................... 16
2.1.14 MIGRÁCIÓT TÁMOGATÓ ESZKÖZÖK AZ SAP-BAN .......................................................................................... 17
2.2 SAP RENDSZERHASZNÁLAT - GUI ........................................................................................................ 20
2.3 NETWEAVER ALAP KOMPONENSEK....................................................................................................... 31
2.3.1 WEB APPLICATION SERVER ................................................................................................................................. 33
2.3.2 SAP PROCESS INTEGRATION ............................................................................................................................... 35
2.3.3 SAP MASTER DATA MANAGEMENT ................................................................................................................... 36
2.3.4 SAP MOBILE INFRASTRUCTURE ......................................................................................................................... 36
2.3.5 SAP NETWEAVER PORTAL .................................................................................................................................. 37
2.3.6 SAP COMPOSITE APPLICATION FRAMEWORK .................................................................................................. 37
3 SAP NETWEAVER TECHNOLÓGIAI FELÉPÍTÉSE ......................................................................... 38
3.1 HÁROM RÉTEGŰ KLIEN-SZERVER ARCHITEKTÚRA ............................................................................... 38

3.2 WEBAS JELLEMZŐK ............................................................................................................................... 42
3.3 AZ SAP BŐVÍTÉSI LEHETŐSÉGEI HARDVER SZEMPONTBÓL ................................................................. 51
4 FEJLESZTÉS AZ SAP KÖRNYEZETBEN ............................................................................................ 54
4.1 SAP ADATSTRUKTÚRA (ABAP)........................................................................................................... 54
Selmeci Attila Óbudai Egyetem

Alba Regia Műszaki Kar
2
4.2 BŐVÍTHETŐSÉG, FEJLESZTÉSI LEHETŐSÉGEK........................................................................................ 61

4.3 FEJLESZTÉSI ESZKÖZÖK.......................................................................................................................... 66
4.3.1 AZ ABAP FEJLESZTÉSI ESZKÖZÖK LEGFONTOSABB JELLEMZŐI..................................................................... 66
4.3.1.1 Standard fejlesztési lehetőségek ............................................................................................................. 71
4.3.1.2 Web fejlesztési lehetőségek ...................................................................................................................... 74
4.3.2 TESZTELÉSI, OPTIMALIZÁLÁSI STANDARD MECHANIZMUSOK........................................................................ 86
4.4 SZOFTVERLOGISZTIKA ........................................................................................................................... 87
4.4.1 ÁLTALÁNOS JELLEMZŐK........................................................................................................................................ 88
4.4.2 MANDANTOK........................................................................................................................................................... 91
4.4.2.1 Definíció és mandantkiosztás................................................................................................................... 92
4.4.2.2 Mandant kialakítása és azok attribútomai ......................................................................................... 99
4.4.2.3 Létrehozási/engedélyezési felelősségek .......................................................................................... 101
4.4.2.4 Változásmanagement................................................................................................................................ 102
4.4.2.5 Mandant másolás ........................................................................................................................................ 102
4.4.2.6 Mandantok kialakítása ............................................................................................................................. 104
4.4.3 ABAP TRANSZPORTRENDSZER ........................................................................................................................ 105
4.4.4 SAP JAVA ALKALMAZÁSOK SZOFTVERLOGISZTIKÁJA .................................................................................... 108
4.4.5 KÖZPONTI SZOFTVERLOGISZTIKA .................................................................................................................... 114
4.5 PATCHELÉS, VERZIÓ KÖVETÉS ............................................................................................................ 116
4.5.1 SUPPORT PACKAGEK .......................................................................................................................................... 116
4.5.2 KERNEL PATCH-EK .............................................................................................................................................. 121
4.5.3 ADATBÁZIS- ÉS OPERÁCIÓSRENDSZER PATCH-EK ......................................................................................... 122
4.5.4 VERZIÓVÁLTÁS .................................................................................................................................................... 122
5 JOGOSULTSÁG- ÉS FELHASZNÁLÓKEZELÉS, AUTHENTIKÁCIÓ........................................... 124
5.1 SAP FELHASZNÁLÓ ADMINISZTRÁCIÓ ................................................................................................ 124

5.2 AZ SAP JOGOSULTSÁGI RENDSZERE ................................................................................................... 131
5.2.1 ÁLTALÁNOS TULAJDONSÁGOK .......................................................................................................................... 131
5.2.2 A JOGOSULTSÁGI RENDSZER ELEMEI................................................................................................................ 131
5.2.3 JOGOSULTSÁGOK AZ SAP KÖRNYEZETBEN ..................................................................................................... 134
5.2.4 JOGOSULTSÁGVIZSGÁLAT ................................................................................................................................... 135
5.3 FELHASZNÁLÓ AZONOSÍTÁS (AUTHENTIKÁCIÓ) ÉS SINGLE SIGN-ON .............................................. 138
5.3.1.1 Az SAP NW Portál Single Sing-On megoldása ................................................................................ 144
5.3.1.2 Web AS JAVA authentikációs modulok ............................................................................................. 147
5.4 A SAP IDM ARCHITEKTÚRÁJA ........................................................................................................... 149

3
5.4.1 IDENTITY CENTER ............................................................................................................................................... 150

5.4.2 AZ IDM KONNEKTOROK .................................................................................................................................... 153
5.4.3 VIRTUAL DIRECTORY SERVER - VDS .............................................................................................................. 155
5.4.4 SAP IDENTITY PROVIDER.................................................................................................................................. 157
5.4.5 AZ IDM ÁLTALÁNOS SZOLGÁLTATÁSAI........................................................................................................... 159
5.4.6 AZ SAP IDM SZEREPEK KIALAKÍTÁSÁNAK IRÁNYELVEI .............................................................................. 159
6 INTEGRÁCIÓS LEHETŐSÉGEK ........................................................................................................ 168
6.1 ADATKINYERÉSEK ............................................................................................................................... 168

6.1.1 PC FÁJL LETÖLTÉS............................................................................................................................................... 168
6.1.2 ELEKTRONIKUS ADATCSERE RENDSZEREK KÖZÖTT (ALE, BAPI) ............................................................ 170
6.1.3 VÉGFELHASZNÁLÓI FUNKCIÓK .......................................................................................................................... 171
6.1.4 SQL ADATKINYERÉS ........................................................................................................................................... 172
6.2 ADATKOMMUNIKÁCIÓK ...................................................................................................................... 175
6.2.1 FÁJL ALAPÚ KOMMUNIKÁCIÓK .......................................................................................................................... 175
6.2.2 RFC KOMMUNIKÁCIÓ ......................................................................................................................................... 176
6.2.3 BAPI ÉS IDOC ..................................................................................................................................................... 181
6.2.4 WEBSERVICE-EK ................................................................................................................................................. 184
6.3 SAP PROCESS INTEGRATION, PROCESS ORCHESTRATION ............................................................... 185
6.4 SAP HELPDESK ................................................................................................................................... 191
7 ÁLTALÁNOS ADMINISZTRÁCIÓ ..................................................................................................... 194
7.1 ÁLTALÁNOS ABAP RENDSZERÜZEMELTETÉS.................................................................................... 194

7.1.1 ÁTTEKINTÉS ......................................................................................................................................................... 194
7.1.2 NAPI FELADATOK ................................................................................................................................................ 195
7.1.2.1 Rendszernapló ellenőrzése (SM21): .................................................................................................. 195
7.1.2.2 Nyomtatási rendszer ellenőrzése (SP01): ....................................................................................... 196
7.1.2.3 Workprocesszek ellenőrzése (SM50, SM51, SM66) .................................................................... 197
7.1.2.4 Zárolási objektumok ellenőrzése (SM12): ....................................................................................... 198
7.1.2.5 Jobok ellenőrzése (SM37): ...................................................................................................................... 199
7.1.2.6 ABAP dump-ok ellenőrzése (ST22): ................................................................................................... 199
7.1.2.7 Adatbázis műveletek (DBACOCKPIT) ................................................................................................ 200
7.1.3 HETI FELADATOK ................................................................................................................................................ 201
7.1.3.1 Rendszer teljesítmény ellenőrzése (ST03n):.................................................................................. 201
7.1.3.2 Terheléselosztás (SMLG) ......................................................................................................................... 202
7.1.3.3 Temse ellenőrzése (SP12): ..................................................................................................................... 202
4
7.1.3.4 SAP pufferek ellenőrzése (ST02): ........................................................................................................ 203

7.2 SAP RENDSZEREK NAPLÓI ÉS AUDITÁLHATÓSÁGA............................................................................ 204
7.2.1 AUDITÁLHATÓSÁG .............................................................................................................................................. 204
7.2.1.1 Rendszeradatok naplózása, audit lehetőségek .............................................................................. 205
7.2.1.2 Üzleti adatok naplózása, audit lehetőségek .................................................................................... 206
7.2.2 ÁLTALÁNOS NAPLÓK .......................................................................................................................................... 206
7.2.2.1 Rendszernapló ............................................................................................................................................. 207
7.2.2.2 Az audit információs rendszer .............................................................................................................. 207
7.2.2.3 Biztonsági audit napló .............................................................................................................................. 207
7.2.2.4 Statisztikák .................................................................................................................................................... 208
7.2.2.5 Alkalmazásnapló ......................................................................................................................................... 208
7.2.2.6 Változási bizonylatok naplózása .......................................................................................................... 208
7.2.2.7 Táblamódosítások naplózása ................................................................................................................ 208
7.2.2.8 Felhasználói törzsrekordban történt módosítások naplózása ............................................... 208
7.2.2.9 Hálózati napló .............................................................................................................................................. 209
7.3 SAP ADATVÉDELEM............................................................................................................................ 209
7.3.1 OPERÁCIÓS RENDSZER SZINTŰ VÉDELEM ....................................................................................................... 210
7.3.2 ADATBÁZIS-KEZELŐ SZINTŰ VÉDELEM ........................................................................................................... 210
7.3.3 HÁLÓZAT SZINTŰ VÉDELEM .............................................................................................................................. 211
7.3.4 TITKOSÍTÁS, HITELESÍTÉS ................................................................................................................................. 213
7.3.5 HÁLÓZATI ELÉRÉS BIZTONSÁGA ....................................................................................................................... 214
7.3.5.1 SAP Web Dispatcher .................................................................................................................................. 214
7.3.5.2 SAProuter ....................................................................................................................................................... 216

5
1 Bevezetés
A jegyzet az SAP NetWeaver alapú rendszerek alap felépítésének, üzleti és
bevezetési szempontból fontos részeit, jellemzőit, illetve a rendszerben végzendő
tevékenységeket mutatja be.
Számos egyéb SAP komponens, ami az SAP portfolion szerepel, itt nem kerül
bemutatásra, lévén nem SAP NetWeaver alapon működnek.
(Mivel az SAP rendszerek fejlesztése folyamatos, így a jegyzet tartalma is változhat,
bővülhet ennek megfelelően.)

6
SAP technológiai architektúra SAP ERP rendszer jellemzői
2 SAP ERP rendszer jellemzői

Alábbi fejezet az SAP rendszerek általános jellemzőit írja le.
2.1 SAP Rendszerjellemzők
2.1.1 Moduláris felépítés

A programcsomag egy úgynevezett bázisrendszerből (BC modul, ill. újabb nevén
Web Application Server) és az erre épülő modulokból áll. A bázisrendszer
tartalmazza a teljes adatbázist, a működést biztosító eszközöket, az ABAP
fejlesztőkörnyezetet, teljes irodaautomatizálási rendszert, Web kezelést és a külső
rendszerek kapcsolódását lehetővé tevő interfészeket.
A bázisrendszerre épülő modulok különböző gazdálkodási területeket fednek le. A
modulok önállóan is alkalmazhatók, bevezetésüknek sem a sorrendje, sem az
időzítése nem kötött.
A modularitásból származó legfontosabb üzleti előnyök:
Szabadon eldönthető, hogy mely modulokra, azon belül mely komponensekre van
szükség és melyekre nem.
Lehetővé teszi, hogy a legfontosabb modulokkal lehessen elkezdeni a rendszer
használatbavételét, a legsürgősebb feladatokra koncentrálva.
A rendszerhez bármikor újabb modulok integrálhatók anélkül, hogy az a meglévő
modulok működését zavarná.
Az újabb verziók rendelkeznek a Web Application Server Java verziójával is, ami egy
teljes érékű J2EE platformot biztosít. Az SAP NetWeaver környezet technológiai
komponensei nem ABAP, hanem Java környezetben készülnek. A Java és ABAP
platformok teljes mértékben együtt tudnak működni, közel azonos a felépítésük és
alkalmazás szinten képesek kommunikálni egymással (JCo, Java Connector
segítségével).
Integráltság
Az SAP rendszer teljes körűen – egyetlen logikai egységként – integráltan, zárt
rendszerként biztosítja a tevékenységekkel összefüggő adatfeldolgozást és a vezetői
információszolgáltatást.
A rendszer moduljai közös adatbázison dolgoznak és egységes felhasználói felülettel
rendelkeznek. Nincsenek inkonzisztens adathalmazok, nincs szükség az egyes

7
funkciókat ellátó modulok között külön adatátvitelre. Egy felhasználó szemszögéből

nézve az integráció egyrészt a különböző alkalmazási területek (pl. előirányzat
nyilvántartás, kötelezettségvállalás, bankszámlavezetés) integrált együttműködését
jelenti, másrészt a területileg, szervezetileg elkülönülő felhasználó csoportok
adatainak egységes kezelését.
Az integráció középpontja egy olyan egységes adatállomány, mely lehetővé teszi,
hogy a szervezet valamennyi egysége automatikusan például ugyanazt a
számlakeretet, KTK kódokat, partner azonosítót használja. A rendszer egyszerre
biztosítja a szervezet egységes információigényét és a szervezeti egységek önálló
gazdálkodását.
Az SAP integrálságából következően minden adatot csak egyszer kell rögzíteni, ami
minden szükséges helyen lekérdezhető, az adott személy jogosultságától függően.
2.1.2 Valós idejű működés

A rendszer valós idejű voltából következik, hogy a rendszerbe bevitt adatok
gyakorlatilag azonnal, a bevitel pillanatában kerülnek ellenőrzésre és jutnak be a
közös adatbázisba. Így egyrészt a rendszerben mindig az aktuális állapot látható,
másrészt az ellenőrzést a rendszer a teljes körű adatállomány birtokában alapján
tudja elvégezni. (Pl.: új üzleti partner rögzítésekor és annak engedélyezésekor mind
a számlavezetés, mind a kötelezettségvállalás modul számára azonnal elérhetővé
válnak az adatok)
A rendszerbe az adatokat keletkezésük helyén viszik be a felhasználók, és az
információ a bevitel pillanatában automatikusan eljut a gazdálkodás valamennyi
érintett területére. Ezzel szükségtelenné válik a rendszer moduljai között a bonyolult
csatlakozási felületek definiálása és az adatok utólagos áttöltése. (Pl.: Az előirányzat
adatok közvetlenül bekerülhetnek a főkönyvi rendszerbe).
A rendszer valós idejű működéséből számos előny származik:
• Az adatok ilyen módon történő feldolgozása lecsökkenti a papírmunka
mennyiségét, lecsökkenti a beérkező bizonylatok feldolgozási idejét, így nagy
mennyiségű munkaidőt szabadít fel és felgyorsítja az adatok feldolgozását.
• Az adatok gyorsabb feldolgozása jelentős lépéselőnyhöz juttatja a
döntéshozókat.

8
• Az adatok azonnali széleskörű ellenőrzése minimalizálja az adatbevitelkor

elkövetett hibák esélyét. Azonnali, megbízható adatokkal támogatott döntések
meghozatalát teszi lehetővé a végrehajtói szinten. (Pl.: keretfigyelés,
törzsadatok megengedett jellemzői, törzsadatok érvényessége.).
2.1.3 Rugalmasság
A rendszert alkalmazó szervezetek tevékenységi köre, a különböző országok
törvényi előírásai, az egyes intézmények szervezeti struktúrái egészen eltérőek
lehetnek, amit a szoftvernek programmódosítások nélkül követnie kell.
A rendszer egy működő mintaszervezettel, felparaméterezve kerül szállításra, mely
referenciát képez a paraméterezési folyamathoz. A testre szabást (customizing)
külön menürendszeren keresztül végezhetjük, áttekinthető módon. A customizing
folyamaton keresztül érhető el, hogy a rendszer működési logikája a felhasználó
igényeit kövesse, de ezekben adható meg a által használt kódrendszer, szervezeti
struktúra, stb. Néhány példa: a Törvényi sorok struktúrái, a mérleg felépítése, a
használatos valutanemek rövidítései, ezek átváltási árfolyamai, a különböző banki
jogcímekhez tartozó automatikus főkönyvi kontírozás, fizetési módok (átutalás,
készpénzes, postai), stb.
Természetesen minden szervezetnél vannak olyan speciális igények, - elsősorban
különböző kimutatások - melyek a sztenderd rendszernek nem képezik részét.
Ebben az esetben kap szerepet a rendszerrel együtt szállított 4. generációs fejlesztői
környezet, melynek segítségével ezek egyszerűen elkészíthetők.
A paraméterezhetőségből származó nagy előny az, hogy a kipróbált és bevált módon
működő rendszert úgy lehet az egyedi igényekhez igazítani, hogy nem a
programkódban kell változtatni, ami ezernyi hibalehetőséget jelentene rövid és
hosszú távon egyaránt, hanem a módosítást a rendszer által ellenőrzött körülmények
között végezhetjük el úgy, hogy az végül is a rendszer alapvető működőképességét
nem befolyásolja. Az egyszer beállított paraméter táblák átvehetők a rendszer újabb
verzióiban is, míg az esetleges programkód módosítást minden egyes verziónál újra
és újra el kellene végezni.

9
2.1.4 Egységes felület

A rendszerben meglévő, sztenderd képernyők, listák képei egy ún. SAP Style Guide
szerint készültek, melyek egységes megjelenést biztosítanak a végfelhasználói
felületen (SAPGUI) keresztül. Amennyiben az ügyfél saját fejlesztéseket hoz létre a
rendszerben, javasolt követni az SAP ergonómiai példákat, hogy a rendszer
felhasználóbarát és könnyen kezelhető felépítése ne sérüljön azonban maguk a
felületek széles körben testre szabhatóak.
Tetszés szerint, vagy tranzakciós kódokkal („gyorsmenü”), vagy menürendszerben
való navigálással érhető el a kívánt funkció. A sztenderd menürendszeren kívül, a
felhasználókhoz, a munkakörökhöz saját menürendszer készül.
A rögzítési képernyők az adott feladathoz szükséges és elégséges adatokat
tartalmazzák. Paraméterezéssel meghatározható, hogy az adott tranzakció, funkció
használatakor mely mezők, adatok jelenjenek meg. A képernyőkön az input és
output / kötelezően kitöltendő mezők egyértelműen megkülönböztethetőek. A
képernyőkön adatbeviteleknél a kurzor a logikailag első inputképes mezőre áll.
Az alfa numerikus mezők esetében mind az ékezetes nagy- és kisbetűk is
bevihetőek.
A különböző képernyőkön az azonos műveletek azonos módon, illetve kóddal
kiválaszthatók.
A dátumok, összegek a felhasználókhoz egyedileg definiált szerkezetben a magyar
szabályoknak megfelelően jelennek meg.
Az értékkészlettel rendelkező input mezők felöltése a mező mellett legördülő
táblázatból választható. Az értékkészlet táblák tartalmazzák a kódok megnevezéseit,
legfontosabb jellemzőit. A táblákhoz kapcsolt dokumentációt és ’súgó’-t az SAP
Infopack megoldása valósítja meg.
A törzsadatok többszörös rögzítésének megelőzését az SAP rendszer lehetővé teszi
a különböző beépített, belső automatizmusaival (pl. partner törzs ellenőrzés).
Az SAP rendszerben beállításra kerülnek CDV ellenőrzések (pl. adószám,
bankszámlaszám).
Az SAP megerősítést vár a mentett adatok törlésekor, lényeges adatok
módosításakor, bevitelekor. A releváns adatok a beviteli képernyőn megjelennek,
megjeleníthetőek.

10
Egy tranzakción belül a beviteli képernyők az adott funkciónak, munkafolyamatnak

megfelelően követik egymást.
Egyes mezőknél beállíthatóak alapértelmezettként a leggyakrabban használt
értékek. Lehetőség van arra, hogy a mezőbevitelkor az utoljára bevitt értékeket a
rendszer felajánlja. Ezek beállítása felhasználóspecifikus, beállításuk igény esetén
megtörténik.
Tetszőleges helyen segítséget (help-et) is kérhetünk a rendszertől. A rövid szöveges
üzenetek mögött részletesebb hibaleírással, magyarázattal, javaslattal rendelkezik az
SAP rendszer.
Az SAP speciális ország specifikus jellemzőkkel is rendelkezik, tehát nem csak egy
egyszerű fordítása a német verziónak. Itt kiemelnénk a magyar irányítószámok
használatát, a magyar bankszámla hosszt és ellenőrzőjegyeket, az ÁFA kerekítési
szabályokat, a zárlati könyveléseket (elhatárolás, átértékelés stb.), a felszólítás és
kamatszámítás menetét, bonusz, skontó, rabatt magyar előírások szerinti kezelését,
stb.
A rendszer Windows-os felülete rendkívül könnyen kezelhető. Az SAP komoly
ergonómiai kutatást követően alakította ki az ún. Enjoy (Élvezetes) felhasználói
felületét, amely valóban kellemessé teszi a rendszerhasználatot: kényelmes
menüelérés, hatékony adatbeviteli felület, szépen vizualizálható riportok.
A rendszer saját levelező funkcióval rendelkezik, amely alkalmas az egyszerű
levelezés és saját futtatású riportok küldésétől kezdve a Workflow lépések
lekezeléséig.
2.1.5 Folyamatok automatizálása (Workflow)

SAP az egyik alapítója és ma is aktív tagja az olyan nyílt szervezeteknek, mint a
Workflow Management Coalition (WFMC), vagy Business Process Management
Initiative (BMPI), ezzel nem csak a sztenderdokat támogatva, de azok
megvalósítását ill. a rendszerek közötti működését is szem elé tűzi ki. Ezek a célok
vezették az SAP-t és a Business Process Technology kezdeményezésből kinőtt az
SAP Business Workflow és annak legújabb eleme, a WebAS részét képző WebFlow.
A Webflow az alább tárgyalt lényegi workflow funkcionalitásokat kibővítette a SOAP,
XML üzenetküldés, Web szerviz kezelés és új felhasználói interfész támogatásával.

11
Az SAP workflow funkcionalitása lehetővé teszi a papír alapú bizonylatok kiváltását,

számosságuk csökkentését.
2.1.6 Változások követése

A dokumentált államháztartási adatmodell és a rendelkezésre bocsátott eszközök,
valamint a megjelenő új verziókban megvalósuló új funkciók lehetővé teszik, hogy az
SAP rendszerrel gyorsan követni tudják az ügyfél szervezetében fellépő
változásokat. A struktúraváltozások esetén is paraméterek átállítására van szükség,
mely a produktív rendszer üzemeltetésében nem okoz fennakadást.
2.1.7 Nyelvfüggetlenség
Az SAP rendszer a világ több mint 120 országában üzemel, hivatalosan már 16
különböző nyelvű verziója létezik és továbbiak vannak kidolgozás alatt. A rendszer
minden megjelenő szöveget nyelvi kulcs szerint rendezett adatbázis relációban tárol,
így biztosított, hogy ugyanazt az alkalmazást egyszerre több nyelven is lehessen
használni.
Ábra 2-1 Unicode, nyelvi csoportok, átfedések
Az SAP jelenleg unicode szabvány szerint kezeli az eltérő nyelvi verziókat. Egy
unicode alapú rendszerben lényegében egy karakterkészlet van, maga a „unicode
code page“. A Unicode Konzorcium (http://www.unicode.org) a több, mint 10 évvel

12
ezelőtti alapítása óta folytatja a unicode sztenderd fejlesztését és kiterjesztését,

ugyanakkor támogatja a unicode használatát a szoftver alkalmazásokban.
A mai elvárásoknak köszönhetően a unicode nem csak egy technikailag tökéletes
megoldás a Világ összes nyelvének reprezentálására, hanem elengedhetetlen a
modern üzleti folyamatok és fejlesztői platformok számára. Egy SAP rendszeren
belül a felhasználók egyéni profiljuktól függően akár különböző nyelvű felületeken,
egységes folyamatokkal is dolgozhatnak.
2.1.8 Archiválás általában

Adatarchiválás az SAP technológia részeként
Az adat archiválás az SAP sztenderd funkcionalitása, melyet a rendszer előzetesen
létrehozott archív objektumokkal és archív fejlesztői környezettel (ADK) támogat. Az
SAP ezen eszközök segítségével támogatja a zárt folyamatokhoz tartozó adatok
áthelyezését az adatbázisból, egy archív környezetbe anélkül, hogy a rendszer
integritása sérülne.
Ezeket az adatokat olyan archiválási objektumokon keresztül azonosítják, amelyek
előre meghatározott technikai reprezentánsai tényleges objektumoknak, mint
nemzetgazdasági könyvelések bizonylatai. Ezeket az objektumokat a felhasználó
által meghatározott szelektálási követelmények szerint választják ki és egy olyan
fájlrendszerbe írják sűrített formában, ami archív fájlokat is használ. A már archivált
bizonylatok adatbázisból törlésre kerülnek, de az archív rendszerből
visszaolvashatók.
A kiterjedt ellenőrzés biztosítja, hogy mielőtt az objektumokat archiválják és törlik,
teljesek legyenek és ne legyen szükség rájuk más tranzakciókhoz, illetve, hogy a
kapcsolódó objektumok már előzetesen archiválva legyenek. Az adatok meta
formátumban történő tárolása biztosítja, hogy ezen adatokhoz a jövőben hozzá
lehessen férni, még későbbi SAP verziók esetén is.
Az egyedileg kialakított objektumok esetén lehetőség van – az archív fejlesztői
környezet adta lehetőségeket kihasználva - saját archiválási objektumok
kialakítására, majd az ezeknek a sztenderd archiválási folyamatba történő
beillesztésére.

13
2.1.9 Adattárolás, PBS támogatás

Az archivált adatok tárolására az SAP számos lehetőséget kínál az Archive Link
felületen keresztül, mely képes fájlrendszerekkel, hierarchikus tárolórendszerekkel és
archív rendszerekkel is – akár párhuzamosan – aktív kapcsolatok fenntartani.
Ábra 2-2 Archiválás PBS technika © PBS
A hierarchikus tároló-rendszerek és archív rendszerek alkalmazásának előnye a

független adatbiztonság és performancia, ami az archív rendszerek esetében
általában kiegészül a dokumentum és adatarchiválást támogató SAP vagy külső
rendszer oldali eszközökkel.
A rendszerben lévő állományok, adatok, törzsadatok archiválása szigorú feltételek
mellett biztosított. Az archivált adatok szükség esetén visszatölthetőek a rendszerbe.
Archiválási tevékenység elvégzését, tapasztalat szerint a rendszer több éves
használatát követően javasolt elvégezni. A jelenlegi rendszerek archiválását az
azokat szállító/üzemeltető szervezeteknek kell elvégezniük. Természetesen ez nem
érinti az új rendszerbe átmigrálásra kerülő adatköröket.
2.1.10 Rendszerfüggetlenség
Az SAP rendszerarchitektúrájának kialakításakor fontos szempont volt, hogy a
rendszer lehetőleg minden elterjedt és megfelelő teljesítményt biztosító hardveren,
operációs rendszeren és adatbázis-kezelőn működőképes legyen.
Ennek biztosítása céljából az alkalmazói programok és a rendszerprogramok közé
egy közbenső szintet építettek be, az ún. bázis rendszert (Web AS). Így érhető el,
hogy az alkalmazás-változtatások nélkül mozgatható mindazon rendszerkörnyezetek
között, melyekre a bázisrendszernek van kidolgozott verziója.

14
Az SAP transzport rendszere lehetővé teszi beállítási és fejlesztési objektumok

rendszerkörnyezettől független módon történő mozgatását SAP rendszerek között.
2.1.11 Adminisztráció
Annak érdekében, hogy az installált SAP rendszerek minél megbízhatóbban, minél
jobb teljesítményt nyújtva tudjanak működni, az üzemeltető személyzetnek az adott
rendszer típusától függő gyakorisággal bizonyos napi, heti, havi és eseti analíziseket
kell a rendszerben elvégezni. Ezek a rendszeres analízisek lehetővé teszik, hogy a
rendszerben bizonyos problémák kiteljesedése az időben történő beavatkozás
következtében megakadályozásra kerüljön.
Különösen a rendszer teljesítménye tekintetében előfordul azonban olyan eset,
amikor a rendszeresen végzett analízisek ellenére is drasztikus teljesítményromlás
következik be. Ebben az esetben a napi analízisek jelentősége fokozottabban
megnövekszik, mivel a hangolással járó paramétermódosítások rendszerre gyakorolt
hatását nagyon pontosan és precízen rögzíteni kell.
Az analízisek az alábbi főbb területekre bomlanak:
• Operációs rendszer és hálózat
• Adatbázis kezelő
• SAP rendszer
Az analíziseket a fenti területeknek megfelelő analizáló lépéseket tartalmazó
ellenőrző listák alapján kell elkészíteni.
Célszerű ezeket az analíziseket elektronikus formában tárolni és egy megfelelő
elévülési időt figyelembe véve, ezeket törölni. Abban az esetben, ha az analízisekből
egy, a rendszer későbbi üzemeltetése számára tanulságos esettanulmányt lehet
összeállítani, akkor azt célszerű egy külön tároló helyen tartani és az elévülési időn
túl is megtartani.
2.1.12 Sztenderd SAP monitorozás

Az analíziseket a feladatokhoz rendelt személyzetnek kell rendszerenként megadott
gyakorisággal (napi, heti, alkalmankénti) elvégeznie.
A napi analízisek végrehajtását az alábbi típusú feladatokra kell szétbontani:
• Operációs rendszer vizsgálatok
• Hálózati vizsgálatok

15
• Adatbázis kezelő vizsgálatok

• SAP rendszer vizsgálatok
Az SAP különböző analizáló eszközöket bocsát rendelkezésre, melyek
nagymértékben megkönnyítik a feladatok elvégzését.
Computing Center Management System (CCMS) segít az SAP rendszer
monitorozásában, vezérlésében és konfigurálásában. A CCMS funkciói között
találhatóak az SAP rendszerek (instanciák) leállítása, elindítása, műszakváltások,
rendszermonitorozás és alertek automatikus jelzése, terheléselosztás,
profilkarbantartás, háttérfeldolgozások kezelése, adatbázis adminisztráció és adat
archiválás.
Az SAP egyre inkább bevonja az adminisztrálást az SAP rendszer felülete alá, hogy
a rendszergazdának csak speciális esetekben (pl. táblatér bővítés, fájlrendszer
módosítás) kelljen az operációs rendszer, illetve az adatbáziskezelő eszközeit
használnia. Ezért a 4.0-ás verzió óta a monitorozó rendszer is megújult és az un.
CCMS monitorozó architektúra nevet kapta. Az SAP az újabb verzióval kiszállítja az
SAP System Administration Assistant (SSAA) megoldást, ami lehetőséget biztosít az
operátorok és rendszergazdák feladatainak egy felületről történő végrehajtására.
2.1.13 Dokumentumkezelés
Az államháztartási szintű tranzakciók kifogástalan feldolgozása és értékelése függ a
dokumentumok tartalmának naprakész ismeretétől, és a dokumentum tartalom
további sorsától. Akár jóváhagyási vagy engedélyezési folyamatról, akár határozat
nyilvántartási, feladatfinanszírozási, vagy más alkalmazási eljárásról van szó, az
információnak rendelkezésre kell állnia, eredeti formájában, jogi szempontból
biztonságosan. Ezért az eredeti dokumentumok integrációjának teljes mértékben
biztosítottnak kell lennie.
Faxok, e-mail-ek, vagy szkennelt adatok beérkezésükkor azonnal eltárolhatók és
hozzárendelhetők egy létező üzleti objektumhoz, vagy egy olyan üzleti objektumhoz,
ami a feldolgozás során jön létre. Ezzel a technikával olyan időigényes
munkafolyamatok, mint pl. fénymásolás és az eredeti dokumentumok szétosztása,
adat keresés és egyéb papír alapú archiválási tevékenységek elkerülhetők. A
dokumentumok bárhol, bárki számára, bármikor rendelkezésre állnak,

16
megtekinthetők. Az integrált dokumentumok kellő időben garantálják a szükséges

üzleti információkat. Az ArchiveLink ezeket az eredeti üzleti dokumentumokat
digitális és változatlan formában teszi elérhetővé.
Az ArchiveLink sztenderd megoldásai alapvetőek a dokumentumintegrálás könnyebb
bevezetéséhez:
• Felhasználók számára egy központi belépési pontot biztosít a dokumentumok
visszakeresésére elosztott, heterogén környezetben.
• WebFlow alapú bejövő dokumentumok automatizált tárolása és kezelése.
• Bejövő dokumentumok vonalkód alapú automatikus csatolása és tárolása.
• Bejövő dokumentumok ad-hoc feldolgozása.
• Kimenő dokumentumok tárolása: SmartForms alapú dokumentumok (űrlapok)
nyomtatásakor, faxon vagy e-mailen történő küldésekor, az űrlap
automatikusan eltárolható és egy üzleti objektumhoz csatolható.
• Nyomtatási listák (riportok) eltárolhatók későbbi felülvizsgálás, nyomtatás
végett a nyomtatott verzióval vagy anélkül.
• SAP adat archiválásából keletkezett fájlok tárolása.
A dokumentumok elektronikus kezelése és tárolása lehetővé teszi a jelenlegi
nagymennyiségű papír alapú bizonylat áramlás jelentős csökkentését.
2.1.14 Migrációt támogató eszközök az SAP-ban

Migráció alatt a régi rendszerekben tárolt törzs- és mozgásadatok átvételét értjük az
új rendszerbe. A migráció során alapvető követelmény, hogy minden szükséges adat
hiánytalanul átkerüljön az új rendszerbe.
A migrációs folyamatot az alábbi lépésekre bonthatjuk:
• Adatok kitárolása a régi rendszerből
• Adatok előkészítése az SAP rendszerbe való betöltéshez
• Adatok betöltése az SAP rendszerbe

17
Az LSMW működési modellje
Egy vagy több

adatállomány
Adatállomány
PC-n
Beolvasott Adat olvasás
adatok
Struktúrák Adatállomány
relációk alkalmazás
szerveren
Mező szintű
megfeleltetés Adat konvertálás
SAP standard
Batch Input
Konverziós feldolgozás
szabályok
Konvertált Direct Input
adatok feldolgozás
bejövő IDoc
feldolgozás
Ábra 2-3 Általános BatchInput feldolgozási folyamat (LSMW) © SAP

© SAP AG 2004, Internal FI-CA Info session 03/2004 / Friedrich Keller / 12
Mivel a migráció kritikus fontosságú egy új informatikai rendszer üzembe állítása

során, ennek megfelelően az SAP is biztosít megfelelő eszközt ennek a feladatnak a
megoldására, amit LSMW-nek (Legacy System Migration Workbench) nevez. Az
LSMW egy olyan eszköz, ami teljes körű menedzsment funkciókat biztosít az adatok
átvételére, konvertálására, az SAP-ba való betöltésére, mégpedig úgy, hogy a
manuálisan végrehajtandó feladatok aránya minimális.
Az eszköz későbbi migrációs feladatok elvégzéséhez programozási vagy fejlesztési
ráfordítás nélkül alkalmazható.Az adatmigrációt – sokéves, kipróbált projekt
tapasztalatok alapján – az alábbi szempontok figyelembevételével állítottuk össze:
• A régi rendszer(ek)ben nem szükséges semmilyen bővítési, fejlesztési feladat
elvégzése, mert a régi rendszerben tárolt adatokat a minden rendszer által
standard módon biztosított adatlekérdező eszközökkel kell majd kinyerni és
egyszerű szöveges formátumú adatállományokban letárolni.
• A régi rendszerből kinyert adatokat elő kell készíteni (kód konvertálás,
automatizált adattisztítás) az SAP-ba való betöltés számára. Ezt az
előkészítést SAP programokkal végezzük, a konvertáláshoz szükséges
táblázatokat, szótárakat az SAP standard fejlesztési eszközeivel valósítjuk
meg.

18
• A betöltésre előkészített adatokat standard betöltő programokkal töltjük be az

SAP rendszerbe. Az adatbetöltés során minden olyan adatellenőrzésre sor
kerül, ami a kézi adatbevitelkor is megtörténik.
• A konvertálásra, betöltésre használt algoritmusok, konvertálási szabályok,
programok, a betöltés menedzselését biztosító eszközök mind az SAP
rendszerben vannak, ott is maradnak az éles üzem indulása után is, ezért
természetesen felhasználhatók a későbbi adatmigráció(k) során is. Az LSMW
a teljes folyamatot naplózza, bármikor visszakereshető, hogy milyen input
állományból milyen konvertálási szabályokon keresztül milyen adatok lettek
betöltve.
A következőkben részletesen is kifejtjük az egyes migrációs lépésekben elvégzendő
feladatokat.
• Adatok kinyerése a régi rendszerből.
• A régi rendszerből a munkavállalók törzs- és mozgásadatait mindenféle
konvertálás nélkül, a beépített adatlekérdező funkciókkal (végső esetben a
meglévő riportok kimenetének külső adatállományba való átirányításával)
kívánjuk előállítani. Ezáltal nincs szükség a régi rendszerben fejlesztésre, ami
sok esetben nem, vagy csak nagy költséggel megvalósítható tevékenység. A
régi rendszerek katalógusait, kódtábláit szintén letöltjük szöveges
állományokba, mert ezekre a konvertálási szabályok, algoritmusok,
kódszótárak kialakításánál lesz szükség. Mivel a konvertálás az SAP-ban,
illetve SAP eszközökkel történik, fontos megjegyezni, hogy a kódtáblákat,
katalógusokat a migrációs folyamat során többször is szinkronizálni kell.
Az SAP-ba való adatbevitelhez elsősorban a Batch Input technológiát fogjuk
alkalmazni. Ez egy olyan speciális eljárás amely során ugyanazok az adatbeviteli
ellenőrzések történnek meg, mint a kézi adatbevitel során. (Gyakorlatilag az
adatbeviteli képernyők gépi úton való kitöltéséről van szó.) Ennek a technológiának a
következő előnyei vannak a közvetlen táblába történő adatbevitelhez képest:
• adatbeviteli képernyőkön dolgozik, teljes ellenőrzéssel
• képes a szinkron update műveletre
• párhuzamosan több taszkban is futtatható
• teljeskörű hibakezeléssel rendelkezik.

19
Az LSMW, mint migrációs eszköz a betöltési folyamat nagyfokú automatizálását teszi

lehetővé, egyrészt maga a szoftver is integráns módon, automatizmusokkal
támogatja az adatmigrációt (az előkészítéstől az éles környezetbe történő betöltésig),
adattisztítást és a kapcsolódó tevékenységeket.
2.2 SAP Rendszerhasználat - GUI

Az SAP az R/3 4.6-os verzióitól kezdve háromféle GUI megjelenítést tesz lehetővé.
Az összes platformon futtatható Platin (PLATform INdependent) GUI, vagy más
néven JavaGUI megfelelő futtató Java környezettel minden esetben alkalmazható. A
kezdetektől használt, Microsoft Windows operációsrendszereken futó SAPGUI for
Windows (WinGui) 4.6-tól már csak 32 bites formában létezik, pontosabban az új
operációs rendszerek esetében már támogatja a 64bit-et is. Az Internet és a Web
alapú technológiák elterjedésével párhuzamosan megjelent a tisztán web-es, csak
egy böngészőt igénylő (zero-footprint) ún. SAPGui for HTML vagy másnéven
WebGui.
Mind a JavaGui és WebGui lokálisan telepítendő kliens alkalmazás, mely a SAP
alkalmazás szerverrel – ún. dispatcher – processzével - a SAP specifickus DIAG és
RFC protokollon keresztül kommunikálnak. Lévén, hogy kifejezetten a SAP
képernyők (ún. Dynpro-k) kezeléséhez írták őket, így – különösen a WinGui – igen
hatékony megjelenítő eszköz, mint a PC-vel szembeni alacsony erőforrás igényt
tekintve, mind a szükséges hálózati sávszélesség szempontjából, hiszen csak a
„hasznos” adatátivtelére van szükség, a grafikus megjelenítés a megfelelő vezérlő
utasításokon keresztül történik.

20
Ábra 2-4 SAPGUI family / SAPGUI típusok (service.sap.com)
A WebGui megoldás viszont nem közvetlenül az alkalmazás szerver dispatcher

processzéhez kapcsolódik a SAP DIAG és RFC protokollján, hanem http/https
protokollal az alkalmazás szerver beépített Web-szerver szolgáltatásának
segítségével (SAP Internet Communication Manager – ún. ICM procesz) a SAP
Internet Transaction Server (SAP ITS) moduljához.
A SAP ITS feladata, hogy a felhasználó felöl érkező http/https kéréseket átültesse a
DIAG protokollra és továbbítsa azt a SAP AS dispatcher processzének, illetve a
dispatcher processzétől válaszként kapott SAP képernyőket (Dynpro-kat) HTML
oldalakká konvertálja és http/https-en keresztül megjelenítse azokat a felhasználó
web-böngészőjében. A SAP ICM és a SAP ITS integrált része a SAP Web-
alkalmazás szervernek, tehát nem külön licenszelendő vagy külön telepítendő
komponensről van szó. A 3 Gui megoldás 99%-ban funkciónálisan egyenértékű
felhasználói felület ad a SAP felhasználónak, a kisebb különbségek leginkább a
képernyő elemek kezelésében (copy-paste funkciók, listák másolása, tabulátor vagy
hot-key használat) illetve az ún. front-end-en keresztüli nyomtatásban van.
Az ún. front-end nyomtatás funkció - tehát amikor az alkalmazás szerverről a
bejelentkezett felhasználó munkaállomásán definiált nyomtatóra szeretnék nyomtatni
– ún. PDF nyomtatáson keresztül valósul meg: A kinyomtatandó oldalakat a
böngésző PDF formában kapja meg, melyet egy PDF megjelenítővel (minimálisan
Adobe Acrobar Reader 8 verzióval) a felhasználó lementhet a PC-re egy file-ba vagy
kinyomtathatja a PC-n értelmezett nyomtatón.

21
Szintén különbség, ahogy HTMLgui megoldás nem támogatja a SAPGui for

Windows-ban használt OLE Automation technológiát, mivel hogy az, csak a
Windows opercáiós rendszeren működik, böngészőkben nem. Természetesen
valamilyen szintű Office integrációt – pl. dokumentum-ok Excel, Word vagy pdf
formában történő megjelenítése, letöltése – a WebGui is nyújt a felhasználónak, de
pl. SAP-os dokumentumok közvetlen - a Gui-n belüli – szerkesztését nem.
A rendszer felhasználói felület elvárt funkcióinak szempontjából azonban ezek a
különbségek nem relevánsak, és a felhasználók számára egyenértékű megoldást
nyújt mindkét frontend-típus. Ezeknél a különbségeknél sokkal nagyobb különbséget
jelent, hogy a WebGui használatának lényegesen kisebb extra adminisztrációs
költsége van, hiszen lényegében csak az alap operácáiós rendszer részeként is
elérhető böngészőt igényel a futtatása, így – szemben a Windows-os SAPGui-val –
nem kell külön SAP vagy egyéb infrastruktúra a központi telepítéshez és frissítéshez,
mindez a szerver oldalon történik és a front-endre – a browser által cache-el
objektumok kivételével – nem töltődik le semmilyen permanensen kód, alkalmazás
(pl. Java Webstart technológiával futtatandó kliens komponens). Azonban a WebGui
hálózati kommunikációja kb. tízszerese a SAPGUI for Windows megoldásnak.
A fentiek alapján összességében a SAPGUI for Windows klienst javasolt belső
felhasználóknak. (A külső intézményi felhasználók portál-on keresztül, web felületen
(SAP WebDynpro, BPS, JSP, stb.) érik el a számukra kialakított funkciókat.).
Az SAP különböző megjelenítésű felületeket alakított ki:
• „Classic”’, „light”: Két név ugyanarra a megjelenítésre, ahol a SAPGUI úgy néz
ki, mint a régi Windows-os stílusban használták, így több csökkentett erőforrás
igényekkel lép fel, pl. a képernyő felbontást (színmélység) tekintetében.
• „New visual design”, „Enjoy design”: Szinonimák az általánosan használt
SAPGUI felületre. 2000 körül az Enjoy SAP megoldáshoz (ActiveX kontrolok
használata a Windows felületen) alakította ki az SAP.
• „SAP Signature”: Az új, harmonizált, vagyis Web felülethez illeszkedő SAP
felület.
Mindhárom felület elérhető, a frontend installáció egyben telepíti, áttérés esetén újra
kell indítani a GUI környezetet. A 26417-es SAP OSS útmutató írja le az erőforrásbeli
különbségeket. Az SAP által javasolt a legigényesebb, SAP Signature design

22
változat erőforrásigényét tekinteni. A javasolt SAP megoldások mindegyike a 7.20-

as, jelenleg elérhető SAP frontend megoldást használják.
A frontend használatához a minimális és a javasolt PC konfigurációt az alábbi
táblázat tartalmazza:
SAPGUI Windows 2000 Windows 2003 / XP
Minimum Javasolt Minimum Javasolt
CPU Classic: 200+ MHz 500+ MHz 233 MHz 500+ MHz
CPU Signature: 500+ MHz 1+ GHz 500+ MHz 1+ GHz
Szín Classic: 256 256 256 256
Szín Signature: 64K 64K 64K 64K
Képfelbontás C. 800x600 1024x768 800x600 1024x768
Képfelbontás S. 1024x768 1280x1024 1024x768 1280x1024
Monitor méret C. 14” 17” 14” 17”
Monitor méret S. 17” 17” 17” 17”
RAM Classic: 128 MB 192 MB 128 MB 192 MB
RAM Signature: 192 MB 256 MB 192 MB 256 MB
Táblázat 2-1 SAPGUI erőforrások - régi Windows
SAPGUI Windows Vista / 2008

Server / Windows 7, 8.1
Minimum Javasolt
CPU Classic: 800+ MHz 1+ GHz
CPU Signature: 1+ GHz 2+ GHz
Szín Classic: 256 256
Szín Signature: 64K 64K
Képfelbontás C. 800x600 1024x768
Képfelbontás S. 1024x768 1280x1024
Monitor méret C. 14” 17”
Monitor méret S. 17” 17”
RAM Classic: 512 MB 1 GB
RAM Signature: 512 MB 1 GB
Táblázat 2-2 SAPGUI erőforrások modern Windows esetén
Alapvetően a telepített SAPGUI nem igényel több erőforrást a Vista, Windows7 vagy
XP környezetben, mint a korábbi Windows operációs rendszereken, de maga az
23
operációs-rendszer nagyobb erőforrásigénnyel lép fel, így ügyelni kell, hogy az

magasabb verziójú operációs rendszerre való áttérés esetén, a PC rendelkezzen az
elegendő teljesítménnyel. A WinGui MS Office integrációja miatt figyelembe kell
venni a gépen futtatandó irodai alkalmazások erőforrásigényét is.
A SAPGui for Windows front-end-et telepíteni kell a PC-re. A telepítés előfeltétel,
hogy az adott PC-n minimum Internet Explorer 7.0 legyen, IE 8, 9, 10 szintén
támogatott. A telepített WinGui esetén számolni kell még némi a helyigénnyel a PC
lokális diszkjein: ez minden Windows platformon 110 és 510 MB között van, ami függ
a kiválasztott komponensektől.
A telepítés során néhány paraméter bekérése történik: pl. a cél-meghajtó, ahova a
telepítés történjen, a SAPGui telepítés módja (minimál csomag, tipikus csomag,
egyéni kiválasztás alapján). Ezen felül azonban a telepítés automatikusan történik.
A SAPGui for Windows program telepítése nagymértékben automatizálható és
központilag is végrehajtható, azaz a szoftver telepítése és frissítése megoldható
szoftver disztribúciós eljárással (pl. SMS) is. A frissítések végfelhasználók felé
történő elosztás előtt javasolt tesztelni az új verziót, mint minden szoftver esetében.
A frontend több kötelező vagy opcionálisan választható komponensből áll, melyek
kiválaszthatók a telepítés során, a SAP rendszerben használni kívánt funkcionalitás
függvényében.
Az adminisztrátorok előállíthatnak ún. elő-custimizált telepítési csomagokat, mely
aztán akár az indításkor megadott paraméterek segítségével vagy teljes mértékben
az előre rögzített értékek alapján hajtja végre a front-end szoftver „néma” (vagy
silent) módú telepítését, mely alatt egyáltalán nincs vagy minimális felhasználói
inputra van szükség, így a telepítés különösebb előképzettséget nem igényel, a PC-
jén lokális adminisztrátori jogosultság birtokában akár a végfelhasználó is
végrehajthatja.
A fejlesztők számára érdemes az összes front-end komponenst tartalmazó csomag
összeállítása.
A front-end számára kiadott javító csak upgrade csomagok automatikusan csak az
adott gépen telepített komponensekre futnak meg, tehát ezekből nem kell testre-
szabott csomagot készíteni.

24
Akár a sztenderd SAPGui telepítő csomag, akár az előre testre-szabott telepítő

csomag, de még az egyes javító csomagok is terjeszthetők központilag, táv-
management eszközök segítségével (pl. SMS).
Amennyiben ilyen központi, kliens-gép-adminisztrációs infrastruktúra nincs kiépítve,
de egy intézményen belül van legalább egy, a PC-k által elérhető „file-server”, a
SAPGui telepítő csomag segítségével - külön szoftver vagy licensz igénye nélkül –
tudunk kiépíteni ún. központi SAPGui telepítő és frissítő szerver(eke)t, ahonnan az
egyes frissítéseket vagy a teljes telepítő csomagot a SAPGui-k a hálózaton keresztül
letölthetik. Ez tipikusan akkor jelent megoldást, ha a PC és a file-szerver között LAN
szintű kapcsolat áll rendelkezésre.
Ahol ez lehetőség sem áll rendelkezésre – pl. a WAN típusú hálózati kapcsolat nem
teszi lehetővé egy teljes telepítő csomag letöltését -, az említett testre-szabott
telepítő csomag CD-n vagy DVD-n is terjeszthető.
Felhasználói felület (SAPGUI)
A telepített SAPGui esetén lehetőségünk van választani a SAPGui-n értelmezett
különböző megjelenítési típusok között. A régi típusú megjelenítés (ún. „Classic
Design”) esetén az SAPgui képe hasonló a régebbi SAP verzióknál
megszokottakhoz. Bár ennek a szerényebb megjelenítés által kisebb erőforrás
igénye van, SAP funkcionalitásban nem tér el az újabb Enjoy felülettől. Az Enjoy R/3
verzióval az SAP javította a képernyők vizuális megjelenítését, kidolgozott egy új
interaktív technikát és személyre szabási lehetőséget. Az új eszköz segítségével
csökkent az egyes tranzakciók képernyőinek a száma, de ezzel szemben nőtt az
alkalmazásszerver és a megjelenítő munkaállomás közötti adatkommunikáció (a
lehetséges képek, valamint a képernyőkhöz tartozó vezérlő információk mennyisége
miatt).
A WebGui használata esetén az egyetlen megjelenítési mód az újabb verziójú
„Enjoy” felület.
Egy SAP felületen többféle képernyő elem szerepelhet, mint pl. nyomógomb, beviteli
mező, szöveges, megjelenítő mező, választó kapcsoló (radio button), jelölő mező
(checkbox), ikonok, szimbólumok, táblázatos megjelenítés (table control), regiszteres
megjelenítés (tab-ok), valamint ún. Enjoy kontrolok, mint pl. hierarchikus
megjelenítés (mint a mellékelt ábrán is látható), editor, html viewer, kép megjelenítési
lehetőség, valamint az ún. ABAP List Viewer. (Alábbi példa tartalmaz
25
nyomógombokat, beviteli mezőt, választókapcsolókat, táblázatot, keretet, regiszteres

megjelenítést, valamint a bal oldalán toolbar-t, hierarchikus megjelenítőt is.).
Ábra 2-5 SAPGUI for Windows © SAP

26
Ábra 2-6 SAPGUI for HTML (WebGUI) ©SAP
Az egyes SAP képernyőkön számos lista megjelenítési formátumaként használják az

ún. ALV lista-formátumot, mint olyan táblázatos megjelenítési formát, amit
dinamikusan lehet átállítani rendezés, szűrés, összegzés, mező sorrend, stb. szerint.
Mindamellett közvetlenül Excel file-ba történő letöltési lehetőséggel is bír.
Nyomtatás esetén az ALV listák sztenderd lista formátumra konvertálódnak és az
kerül kivitelre. (Egy egyszerű ALV listát mutat az alábbi kép.)

27
Ábra 2-7 ALV (ABAP List Viewer) lista ©SAP
Az SAP képernyők tetején mindig elhelyezkedik a menüsor, alatta a sztenderd

toolbar, amit a korábban említett cím követ. Maga a címsor (mint az ábrán is látható)
kiemelve tartalmazza a futó megnevezését. Bizonyos esetekben (alkalmazástól
függően) a cím kiegészülhet adatokkal (pl. törzsszám) is. Ezalatt helyezkedik el az
ún. alkalmazói toolbar, vagyis a programfüggő nyomógombsor. A sztenderd
nyomógombsor mindig ugyanazokat a funkciókat látják el, azonban alkalmazástól
függően le vannak, ill. le lehet tiltani a nem kívántakat. A sztenderd nyomógombsor
elején helyezkedik el az ún. parancs mező, melybe tranzakciókódokat írhatunk, ezzel
gyorsítva egyes funkciók elérését a jogosultság alapú felhasználói menühöz képest.
Az SAP Easy Access, vagyis a bejelentkezési, hierarchikus szervezésű felület
használatakor a felhasználó maga dönthet arról, hogy a teljes SAP menüt, vagy a
jogosultsági szerepek által hozzárendelt funkciókat menübe foglaló ún. felhasználói
menüt kívánja használni a hozzárendelt funkciók eléréséhez. A sztenderd menü
tartalmazza a kiszállítás összes funkcióját, azonban a bevezetés során esetlegesen
kifejlesztésre kerülő tranzakciók csak azon felhasználók menüiben jelennek meg,
28
akiknek a jogosultsági hozzárendelésében fellelhetők a tranzakciókat tartalmazó

szerepek. Alapértelmezetten a jogosultságfüggő felhasználói menü látható.
A képernyőn elhelyezkedő különböző mezőknél szabályozható (tranzakciók esetén
alapvetően paraméterezéssel is) az, hogy kötelező-e, vagy csak beviteli
lehetőségként szerepel, esetleg csak megjelenítésre szolgál. A megjelenítésben
különböznek ezek az állapotok egyértelműen. A nem módosítható mező más színnel
(sztenderd módon szürkén) jelenik meg, a kötelező beviteli mezők esetén egy külön
jel található a mezőben (és a rendszer nem enged tovább, amíg ki nincs minden
ilyen mező töltve). Az értéklistás bevitel esetén lehetőség van legördülő lista
(comboBox) vagy ún. keresési segítség (külön nyomógomb a mező végén). A
beviteli mezők esetén nem csak a mező segítség (ún. F1 help), hanem az ún. beviteli
segítség (F4 help) is rendelkezésre állhat. Azon mezők esetén, ahol fix értékek
állnak rendelkezésre, legördülő listaként is lehet definiálni a beviteli segítséget, ami
látható a mezőn. A dátum mezők speciális keresési segítséget biztosítanak a
Gergely naptár megjelenítésével. Azon beviteli segítséggel rendelkező mezők
esetén, ahol az adatok egy vagy több táblában található értékekkel kiegészítve
kereshetők kényelmesen, ill. táblatartalom határozza meg az értékhalmazukat, ún.
keresési segítségek állnak rendelkezésre.
Ábra 2-8 Keresési segítség példa ©SAP
Az ábrán látható, hogy a törzsszám mezőn kérve keresési segítséget számos (jelen
konfiguráció szerint 5) különböző információ szerint kereshetünk, melyek
29
mindegyikénél más és más szűrési feltétel szerint kapunk lehetséges listát, melyből
választva a szükséges mező, (ill. beállítás szerint) esetleg mezők töltődnek vissza a
keresett mezőbe (mezőkbe).
Az eddigiek lényegében az adatbeviteleket támogató képernyőket írta le, viszont
meg kell emlékezni arról is, hogy a rendszer az ALV mellett sztenderd listákat is meg
tud jeleníteni, melyek kifejezetten a nagy mennyiségű adat kezelhető megjelenítését,
nyomtatását támogatja. A listákon alapvetően csak néhány szín használható,
azonban a pénzügyi, ill. mennyiségi számértékek megjelenítésekor figyelembe veszi
a referenciaként megadott pénznem, ill. mennyiségi egység adatokat is, valamint a
felhasználónál beállítottak szerint a számértékek tizedesjel és ezres csoportosítása
is megjelenik. A felhasználói adatok között a dátum formátum is beállítható. (A
számértékek, ill. dátumok persze a tranzakciók megjelenítő és beviteli képernyőin is
ugyanúgy megfelelően láthatók, ill. bevitelnél figyelmeztet a rendszer a használandó
formátumra.) A listákon ikonok, szimbólumok, jelölőmezők (checkbox), valamint
egyszerű színek és kiemelések is megadhatók, akár hyperlink-ek használatával. Ez
utóbbi lehetővé tesz az ún. interaktív listák kezelését, ami akár lefúrásos
részletezésekre is teret biztosít. A listákon szereplő szöveges rendezés során
figyelembe veszi a rendszer az adott ABC betűsorrendjét. A rendezési elvet az
alkalmazás szerveren elhelyezkedő operációs-rendszer locale (lényegében
betűkészlet) adja meg. A képernyők, riportok felső sorában a menü alatt helyezkedik
el a cím rész, ami minden esetben (paraméterezetten) tartalmazza a futó funkció
megnevezését. A SAPGUI környezetből a nyomtatás az SAP rendszerben definiált
nyomtatókra közvetlenül történhet jogosultságtól függően. Minden nyomtatás
rendelkezik fedőlappal, ahol a kötelező mezők feltüntetésre kerülnek. A közvetlen
nyomtatás sztenderd a rendszerben, vagyis nem kíván meg külön exportálást
nyomtatás előtt. A listák mellett külön gonddal kell kezelni az űrlapokat, amiknek a
tartalma és formátuma a bevezetés során alakul ki. Az űrlapok esetén további
elemeket lehet definiálni, mint pl. címer, logo elhelyezése. A nyomtatás, megjelenítés
és bevitel során is figyel a rendszer a betűhelyességre, vagyis a magyar ÁBC betűit
megfelelően tárolja, jeleníti meg és nyomtatja.
Felhasználói felület (Web)
A Web felületekre is igaz, hogy unicode alapokon futnak, így a magyar nyelv,
aszerinti helyes megjelenítés és az azt megjelenítő, tároló kódlap támogatott. A Web
30
felület támogatja a nagyobb Internet Böngészők használatát. A felületek

rendelkezésre bocsátják a magyar nyelvű súgót is a végfelhasználók számára.
2.3 NetWeaver alap komponensek
Az SAP üzleti rendszerinél a technológiai alapot az alább részletezett SAP

NetWeaver Integrációs és Alkalmazási Platform adja. Ebben a fejezetben ennek a
leírását részletezzük. Mivel az SAP megoldás központi funkciói közül a
legfontosabbakat az SAP ERP komponens, az alábbiakban is legfőképpen ebből a
megoldási komponensből indulunk ki.
Az folyamati változások mai felgyorsult ritmusa mellett nem engedhetjük meg
magunknak, hogy merev informatikai stratégiában bástyázzuk el magunkat.
Folyamatosan módosítani kell az üzleti, gazdálkodási folyamatokat ésszerű
költséghatárokon belül. Ezért az SAP üzleti megoldásait, így a SAP ERP-t is az SAP
NetWeaver™ nyitott integrációs és applikációs platformmal szállítja, melynek
feladata a teljes tulajdonosi költség (TCO) csökkentése a komplett informatikai
környezetben.
Az SAP NetWeaver rugalmas üzleti stratégiákat, valamint innovatív üzleti folyamatok
alkalmazását teszi lehetővé a meglévő szoftverek és rendszerek felhasználásával.
Nyílt szabványok és technológiák alkalmazásával integrálja és összehangolja az
embereket, az információkat és az üzleti folyamatokat a különböző technológiákban
és szervezetekben. Ez az átfogó technológiai platform olyan előre konfigurált üzleti
tartalmat biztosít, ami mérsékli az ügyfélspecifikus integráció szükségességét, és mi
bővíthető az általánosan használt fejlesztő eszközökkel, például Java 2 Platform
Enterprise Edition (J2EE); Microsoft .NET; IBM WebSphere.
Az SAP NetWeaver az alapja az Intézményi szolgáltatások architektúrájának
(Enterprise Services Architecture). Az ESA jelenti az SAP fogalmak szerint, a
nemzetközi informatikai életben szolgáltatás-orientált architektúrának (SOA)
keresztelt IT rendszerfelépítést az SAP által szokásosan hozzáadott üzleti értékekkel
és tartalommal. Az eddigi fejlesztőmunka eredményei alapján pedig látszik, hogy
sikerülni fog az ESA-t a terveknek megfelelően elkészíteni. Egy szervezet azért él és
dolgozik, hogy végrehajtsa a saját stratégiáját, amelynek célkeresztjében elsősorban

31
az ügyfelek, igényeik teljesítése szerepel egy meghatározott gazdasági és törvényi

közegben. A teljesítés minden esetben egy gazdálkodási folyamatot indukál. Az
igények esetleges változása a folyamatok megváltozását is jelenti. Az informatika
kialakítása nem lehet az ilyen változások gátja, holott ez kevés kivételtől eltekintve, a
legtöbb szervezetben így fest és az informatika jelenti több szervezetben is a
változások szűk keresztmetszetét. Az informatika kell, hogy igazodjon a szakmai
területek elvárásaihoz. Az ESA kifejlesztése szolgálja ezt a célt az SAP-nál. A
változásokat lehetővé tevő informatikai rendszerkörnyezet megteremtése tehát a
végső cél, hogy az államháztartás szervezeteinél rugalmas stratégiák
születhessenek, hogy az innováció felgyorsulhasson, illetve, hogy az informatikai
költségek is fenntartható mértékűek és szerkezetűek legyenek.
Ábra 2-9 SAP Netweaver áttekintő ábra (SAP HU)
Amint feljebb olvasható, az SAP NetWeaver integrációs és alkalmazási platform több

szinten támogatja egy intézménynél futó komponensek csatolását, valamint a
felhasználók integrációját, kollaborációs szinteken. Az alábbi fejezet részletesebben
tárgyalja a NetWeaver megoldásban rejlő lehetőségeket, kiemelve az komponensek,
így az SAP ERP 6.0 alapját képző Web Application Server (Web AS) alkalmazási
platformot.

32
Az alábbiakban a NW alap komponenseit soroljuk fel röviden, kiemelve az

alkalmazási platformot (Web AS) közüllük. (Az alábbi komponensek nem mindegyike
szerepel ajánlatunkban, csak a teljesség kedvéért említjük itt meg őket, hogy a
NetWeaver környezet általános leírása egységes legyen.)
2.3.1 Web Application Server

Az SAP újdimenziós termékeinek bevezetésekor a jól bevált, általánosan használt
SAP R/3 rendszerek bázis részét (ún basis release, az ábrán „Alkalmazásplatform”)
használta fel. A bázis rendszer leválasztása a 4.6C ill. 4.6D verzióknál történt meg.
Addig az R/3 és a bázis rendszer teljesen egységként élt. A technológiai fejlődések
további bázis verziókat hoztak, melyek a WEB technológiát, később pedig a J2EE
megoldást is tartalmazták. Ezeket a bázis rendszereket az SAP WEB Application
Server-eknek (WebAS) nevezi.
Az SAP ERP a legújabb SAP-technológiát, a Web Application Server-t tartalmazza,
amely az SAP már bevált technológiáit összekapcsolja az új E-Business
technológiákkal. Az SAP Web applikációs szerver egyrészt tartalmazza a lényeges
protokollokat és nyelveket (mint pl. HTML, XML, Javascript, Java (InQMy), HTTP,
HTTPS, SMTP, RFC, SOAP, UDDI, WSDL, WebDAV) és ezáltal biztosítja a
kommunikációt a többi technikai komponenssel, ill. az egyéb nem SAP szoftverekkel
is. Másrészt bővített formában támogatja web-alkalmazások és web szolgáltatások
fejlesztését és karbantartását, valamint jobb kommunikációt biztosít a meglévő
alkalmazásokkal. A már ismert területeken is további optimalizálási intézkedésekre
került sor, mint pl. az alert-monitoring továbbfejlesztése vagy a unicode-képesség.
Az ajánlatunkban szereplő ERP mellett SAP BI (Business Intelligence), SAP CRM ill.
a SAP Solution Manager rendszerek alapja is a fent leírt Web AS ABAP környezet. A
NW Portal, SAP PI, SAP BO GRC megoldások a WebAS 7.0 Java (J2EE) motoron
futnak. Az SAP ERP technológiai bázisa összekapcsolja a már bevált technológiákat
az E-Business területéről származó új fejlesztésekkel. Az SAP ERP ezáltal optimális
kiindulási platformot jelent az Intézményeket átfogó üzleti folyamatok bevezetéséhez.
Az SAP ERPaz ábrán feltüntetett és alább részletezett elemekből épül fel.

33
Ábra 2-10 SAP ERP komponens alapú felépítése (service.sap.com)
A bázis rendszerre (WebAS) épül az ABAP nyelven megírt alkalmazás (az ábrán
„SAP ECC”), amibe a beállítás szerinti adatok kerülnek, valamint ez hordozza az
üzleti logikát is. Az SAP ERP 6.0-ás verzió teljes egészében a megelőző verziók
alkalmazásainak (Application Core) funkcióira épülnek. A stabilitás és a teljesítmény
tovább javult, továbbá nőtt a user exitek, BAdI-k és a BAPI-k száma is. Az SAP
folyamatosan frissíti, szükség esetén javítja, ill. bővíti a core alkalmazásokat.
Speciális, új funkcionalitásokkal azonban nem bővíti a core rendszert.
Az Enhancement csomagok a teljes rendszerkörnyezetre épülő új szintet jelentenek
és nagyobb verzióváltás helyett folyamatos, kis lépésekben bővíthető velük a
rendszer funkcionalitása. Az SAP ezzel egy sima, leállás nélküli verzióváltási
technológiát céloz meg. Amint az ábra is jelzi, az Enhancement Package
megoldással az Enterprise-SOA technológia felé teszünk lépéseket, hiszen az SAP
közvetlenül szállítja ki az Enterprise Service-ket, ugyanakkor biztosítja a meglevő
alkalmazások fölötti újabb, composite alkalmazások készítését Enterprise Service-
kből.

34
Ábra 2-11 NetWeaver szoftver bővítése (SAP HU)
Az SAP ERP ugyanakkor új funkcionális fejlesztéseket tartalmaz néhány

üzemgazdasági területen (pénzügy, számvitel, emberi erőforrások, utazás, PLM,
SCM). Ezek a fejlesztések egymástól független, ún. bővítésekben jelennek meg, és
egyenként ill. tetszés szerint aktiválhatók az SAP ERP Core moduljaihoz. Az SAP
ERP bővítése a jövőben a meglévő bővítések továbbfejlesztése vagy új bővítések
kiszállítása révén történik majd. Valamint az ábrán szereplő ún Enhancement
Package-k formájában.
Az SAP ERP 6.0 verziójától kezdve a switch framework gondoskodik arról, hogy a
rendszerkörnyezetbe bármelyik igény szerinti iparági megoldás egy egyszerű
bekapcsolással alkalmazhatóvá váljék és ne kelljen speciális add-on installációkat és
konfliktuskezelő javításokat betölteni, amik a sztenderd és az iparági megoldás
közötti különbséget hivatott volt feloldani. A switch framework gondoskodik arról,
hogy akár több Extension set és iparági megoldás is együtt tudjon dolgozni a
rendszerben egymás kódjának megzavarása nélkül.
2.3.2 SAP Process Integration

Az SAP PI (illetve SAP PO) az XML üzenetek cseréjén alapuló folyamatok
integrálására szolgáló platform. Az SAP PI rugalmasságát és nyitottságát, az egyes

35
rendszerek, alkalmazások – akár SAP alapúak, akár más szállítók rendszerei –

„nyelvezetének” értése, a velük kiépíthető kommunikációs képesség adja.
Különböző technológiákon alapuló rendszerek integrációjánál alapvető fontosságú,
hogy az integrációs folyamat minden résztvevőjét meg tudjuk szólítani, az összes
rendszer számára lehetővé tegyük az adatok küldését és fogadását. Az Adapter
Framework, és az ehhez kapcsolódó alkalmazási és technikai adapterek feladata,
hogy a különböző protokollon és különböző formátumban érkező üzeneteket az
Integration Server saját belső SOAP/XML formátumára alakítsák és az IS-be küldjék
azokat.
A SAP PI a technikai adapterek segítségével képes fogadni és továbbítani az RFC,
IDOC, FTP, JMS, http és https, JDBC sztenderdok szerinti üzeneteket, és az
azokban foglalt adatokat, üzleti tartalmat.
SAP Business Intelligence
A SAP Business Intelligence (SAP BI) lehetővé teszi, hogy a szervezet hozzájusson
a gazdaságban rendelkezésre álló információkhoz, és azt rendkívül gyorsan valós, a
döntésekhez és intézkedésekhez felhasználható ismeretté alakítsa. Segít bevezetni
az ágazati élvonalat megtestesítő mérési technológiákat. Keretet biztosít a főbb
teljesítménymutatók megértéséhez és az üzemelés optimalizálásához.
2.3.3 SAP Master Data Management

Az SAP Netweaver egyik komponense a törzsadatkezelést szolgálja, így az egyes
szervezeteknél mindenki ugyanahhoz az információhoz fér hozzá a több rendszert
magában foglaló gazdálkodási folyamatokban és elemzésekben. Az MDM
komponenssel teljes törzsadat konszolidáció érhető el, kezdve az azonos adatok
összerendelésétől, a központilag vezérelt törzsadatkezelésig.
2.3.4 SAP Mobile Infrastructure

A mobilitás egy stratégiai téma. A mobil megoldással a dolgozók elérhetik az üzleti
megoldást bárhol és bármikor, ha szükséges. Az SAP MI megoldással a folyamatok
gyorsan mobilizálhatók, figyelembe véve a meglevő IT infrastruktúra előnyeit és
kiterjesztve a rendszer felhasználását az irodán kívülre. Az SAP MI három mobil
kliens technológiát foglal magába, melyekkel elérhetővé tesz sztenderdizált mobil

36
üzleti megoldásokat, valamint felhasználói szerepekre és cél eszközökre optimalizált

ügyfél-specifikus fejlesztéseket.
Az újabb verziók esetén az SAP NetWeaver Gateway átveszi az MI
szolgáltatásainak egy részét, mellyekkel az SAP rendszerekben, mint backend-ben
készült adatok funkciók mobil publikálását végzi oData protokol használatával.
2.3.5 SAP NetWeaver Portal

A SAP NetWeaver Portal megoldás a klasszikus integrált webes keretrendszerekhez
képest jelentős újdonságokkal bír. Ez az innovatív céges portál egy adott ponton
teszi hozzáférhetővé az ember számára az információt, az alkalmazásokat és a
szolgáltatásokat – vagyis a többi SAP Business Suite megoldástól a Web tartalmon
keresztül az on-line adatcseréig és intézményi rendszerekig mindent. Így gyorsan és
könnyen jutunk hozzá mindahhoz, amire a munkánk végzése során szükségünk van.
2.3.6 SAP Composite Application Framework

Az SAP CAF eszközöket és környezetet nyújt összetett alkalmazások (composite)
fejlesztésére és implementálására. Az összetett alkalmazások célja, hogy lehetővé
tegyék olyan új alkalmazások hatékony fejlesztését, melyeket az ügyfelek könnyedén
fogadnak el, és flexibilis kapcsolatokkal rendelkeznek a backend rendszerek felé.
Ezek az alkalmazások az adatokat és funkciókat a backend rendszerek és egyéb
háttéralkalmazások által rendelkezésre bocsátott szolgáltatásokon keresztül érik el,
és ezeket egyesíti felhasználó-centrikus folyamatok és oldalak halmazává, melyet
saját rendszer logika és speciális felhasználói interfész (UI) vezérel.
Az SAP NetWeaver nem csak összeköti az IT rendszereket, hanem kiaknázza a
létező IT infrastruktúrát összekapcsolva a felhasználókat, információkat és üzleti
folyamatokat technológiai és szervezeti határok között.

37
SAP technológiai architektúra SAP NetWeaver technológiai felépítése
3 SAP NetWeaver technológiai felépítése

A fejezet kifejti a kliens-szerver architektúra használatát SAP környezetben, valamint
betekintést nyújt a Java és ABAP környezetek felépítésébe, illetve az ABAP kernel
alap máködésébe.
3.1 Három rétegű klien-szerver architektúra

Mivel a rendszerkörnyezet magját alapvetően az SAP alapú rendszerek képzik, így a
hardver leképezés előtt fontosnak tartjuk megemlíteni a több rétegű architektúra alap
elemeit.
A SAP Web Alkalmazás szerver (SAP Web AS) a központi alapja az egész SAP
szoftver portfoliónak, így ez képezi alapját a rendszerbe rakható szoftver
komponensnek, legyenek az ABAP vagy JAVA alapú megoldások. A Web AS által
megvalósított JAVA architektúra teljesen kompatibilis az általános J2EE ajánlással,
az annak a SAP által tovább fejlesztett és kibővített változata.
A Web AS architektúra megalkotásánál alapvető cél volt egy kimagaslóan robusztus
és minden elemében skálázható architektúra megalkotása.
Egy SAP rendszeren belül, mint klasszikus kliens-szerver architektúrában - élesen
elválasztható egymástól a I. megjelenítési (vagy prezentációs) réteg, II. az
alkalmazási réteg és az III. adatbázis szint.
Ábra 3-1 SAP rendszer (ABAP, Java) technikai felépítése

38
I. Prezentációs réteg
Az architektúra (a fenti ábrán a legfelső) szintje, az ún. prezentációs- vagy
megjelenítési réteg. Az általánosan használt megoldás az SAP vastag kliense az
SAPGui. Ennek három fő megjelenése használható:
• SAPGui for Windows (Microsoft Windows alapú rendszerekre)
• SAPGui for Java (nem Windows felületekre, Mac, Linux, stb.)
• SAPGui fot HTML (vagy WebGUI, böngészős használatra), ez vékony kliens
A SAPGUI program SAP-s protokolon (DIAG, RFC) kommunikál a rendszerrel és
megjeleníti az adatokat. Emellett számos Web alapú megjelenítés lehetséges ITS,
BSP, WebDynpro alapokon (lásd később), valamint a modern irányokat is
támogatandó megjelent az SAPUI5, vagyis a HTML5 alapú kliens.
Ábra 3-2 SAP Fiori használata
Az ábrán szerepel a SAP Fiori komponens, ami az SAP által gyártott és szállított
SAPUI5 alapú termékek technológiája, gyűjtőnekve. Mint látható itt már egy
tényleges (középen álló) negyedik réteg is becsatlakozik, mint frontend szerver.
A megoldással mobil eszközön is használhatjuk az alkalmazásokat.
II. Alkalmazási réteg

Az SAP rendszerek által megvalósított üzleti logika teljes egészében az alkalmazási
rétegben került megvalósításra. Az alkalmazási réteg egy komplett fejlesztői
környezetet is tartalmaz és így ebben a rétegben egyszerre lehetséges az általános
üzleti alkalmazások fejlesztése, telepítése és futtatása. Természetesen az SAP

39
rendszer részeként kiszállított megoldás tartalmazza a továbbiakban részletesen is

ismertetett fejlesztői környezetet és széles körű támogatást biztosít a fejlesztők
munkájának megkönnyítéséhez. Az itt futó platform független alkalmazói programok
és funkciók lehetnek ABAP vagy JAVA alapúak, illetve megvalósíthatnak Web
Service-eket.
Az alkalmazói rétegben van megvalósítva SAP felhasználó és jogosultság rendszere
is (részletek a biztonsági fejezetben):
• Itt definiáljuk egy SAP rendszerhez hozzáférő felhasználókat és azok
authentikációs paramétereit, pl. a jelszót.
• A SAP felhasználók jogosultság beállításait és a jogosultság ellenőrzéséhez
szükséges eljárásokat
• A jogosultságok kezeléséhez, kiosztásához létrehozott szerepeket.
A SAP rendszerek alkalmazási rétege a SAP rendszer típusától függően vagy csak
ABAP (AS ABAP) vagy csak JAVA (AS JAVA) vagy mindkettő futtatókörnyezetet
tartalmazza. A két futtatókörnyezet egymástól függetlenül létezhet, azaz
mindkettőnek egymástól független, az önálló processzei vannak, önálló memória
területet használnak és önálló adatbázis sémába tárolja a rendszer az adatokat. A
két futtatókörnyezet között a SAP standard RFC/JCo (Remote Function Call/Java
Connector) interfész segítségével van alkalmazás szintű kapcsolat, azaz a két
futtatókörnyezet egymás adatbázis tábláihoz közvetlenül nem férhet hozzá, csakis az
erre a célra kialakított függvényeken keresztül.
Ez a felépítés nagyfokú rugalmasságot biztosít abban a tekintetben, hogy az adott
rendszer környezeten beül, hogyan alakítjuk ki az alkalmazási réteget: pl. – bizonyos
megkötésekkel de – lehetőség van az összes JAVA alapú funkció összevonására
egyetlen JAVA AS-be, de vannak pl. olyan ABAP komponensek is melyekről a
tervezés során elég eldönteni, hogy külön vagy közös ABAP AS-re legyen telepítve
más ABAP funkciókkal. Az architektúra kialakításában ez a nagyfokú szabadság
lehetővé teszi, hogy a konkrét funkcionális igényekhez, adat és hálózat biztonsági
megkötésekhez vagy a rendelkezésre álló erőforrások-hoz legjobban illeszkedő
architektúrát alakítsunk ki.
Az alkalmazói programok akár ABAP akár JAVA nyelven kerültek megvalósítása,
ugyanúgy futnak, bármilyen operációs rendszer legyen is a rendszer alatt. Az ABAP
– JAVA-hoz hasonlón – interpretált nyelvként, a funkciók platform független
40
megvalósítását teszi lehetővé. A futtató környezet (AS ABAP) feladata, hogy ABAP
nyelvű programot értelmezze, lefordítsa az adott platformon értelmezhető byte-kódra
és végrehajtsa az adott alkalmazás szerveren. Értelemszerűen az SAP alkalmazás
szerver (az SAP kernel) már a konkrét operációs rendszer platformra került
megvalósításra és az adott adatbázis-kezelő felé tartalmazza a platform-specifikus
adatbázis interfészt is, mindez azonban az alkalmazói programok előtt rejtve marad.
Az alkalmazói programok által használt struktúrákhoz való hozzáférés is platform
független módon történik, mivel a konkrét adatbázis struktúrákat „eltakarja” az
alkalmazói rétegben definiált ABAP Data Dictionary. Így bármelyik szállító
adatbázisában is legyenek az adatok, azokat az alkalmazói programok (ABAP és
JAVA is) az ABAP Data Dictionary-n keresztül használják. Természetesen lehetőség
van a fizikai adatbázis struktúrához való közvetlen hozzáférésre is, azonban ezt csak
egyes speciális esetekben használja maga az SAP is és általában nem javasolt ilyen
módon „megkerülni” a Web AS adatbázis interfészét.
III. Adatbázis réteg

A 3 rétegű architektúra legalsó szintjén az adatbázis és az adatbázis kezelő szoftver
van. A SAP rendszerek adatbázisa a következő típusú adatokat tartalmazza:
• Az adott SAP rendszerben futó alkalmazások minden törzs és tranzakciós
adatát.
• A rendszer funkcionális és nem funkcionális működéséhez szükséges
beállításokat (customizing).
• Az alkalmazói (pl. pénzügy) és az alapmodul (ún. SAP Bázis vagy BC modul)
működéshez szükséges programok, függvények, képernyők stb. ABAP (és
JAVA) forráskódja, struktúrák, táblák, nézetek definíciója. Ezeket
összességében SAP Repository-nak nevezzük, amin belül megkülönböztetjük
az ún. SAP Data Dictionary-t, mely az adattípusokat és adatstruktúrák leírását
tartalmazza.
Az alkalmazások adatai és a rendszer működéséhez szükséges beállítások illetve
repository objektumok egységesen egy közös adatbázisban történő tárolása lehetővé
teszi, hogy teljes rendszerről konzisztens másolatot készítsünk - pl. a teszt
rendszerre – csupán az adatbázis – offline vagy online - másolásával.

41
Az adatbázis réteg egy másik jellemezője az ott tárolt alkalmazói (törzs és mozgási
adatok) felosztása ún. mandantokra. A mandant a SAP adatbázis egy olyan része,
melyben teljeskörűen leképezhető egy vagy több intézmény (gazdálkodási egység)
működése. Egy rendszerben több mandant is lehet, melyek egyedi felhasználó
törzzsel és jogosultság rendszerrel rendelkeznek, illetve az egyes mandantokban
leképezett intézmények egymástól teljesen függetlenül működésre képesek.
Az adatbázis szintjén a mandant, az alkalmazói táblákban mindig az első kulcsmező,
ezeket hívjuk mandant-függő tábláknak, a bennük lévő adatokat mandant-függő
adatoknak vagy mandant-függő beállításnak. A törzs és mozgási adatok, a
felhasználó törzs, a szerepek és a jogosultsági beállítások mindig mandant függőek
és a beállítások döntő többség is. A customizing egy kisebb része mandant független
objektum, mint ahogy a repository objektumok is azok.
A SAP adatbázisban egy rendszer adatai egy-egy schema user nevében érhetők el
az alkalmazási réteg ABAP és JAVA motorjai számára. Ha tehát egy rendszeren
belül mindkét futató környezet működik, akkor a mindkét schema user megtalálható
az adatbázisban. Az adatbázis felhasználó neve az ABAP motor számára a
SAP<SID>, míg a JAVA instancia esetében a SAP<SID>DB, ahol a <SID> a SAP
rendszer 3 betűs azonosítója (SAP System ID). Sőt egyetlen adatbázisban több
rendszer adatai is lehetnek. Ezt az ún. Multiple Component One Database – MCOD
– architektúrának nevezzük. A rendszer indulásakor az alkalmazás szerver
processzei ezen az instancia DB felhasználó nevében kapcsolódnak az
adatbázishoz.
3.2 WebAS jellemzők

Az alábbiakban néhány technikai jellemzőt emelünk ki.
Robosztus és skálázható architektúra
Instanciának a közös osztott memóriaterületet használó és együttműködő különböző
SAP processzek együttesét nevezzük, mely a legkisebb egyszerre leállítható vagy
indítható egység az SAP rendszeren belül.
Egy SAP rendszer általában egy vagy több alkalmazás szerver instanciából és egy
adatbázisból áll.

42
Az SAP instanciát az ún. instancia névvel azonosítjuk, amely 3 részből tevődik

össze: a rendszer 3 betűs azonosítójából (SID) , az instancia 2 számjegyű egyedi
azonosítójából (instancia szám) és a hoszt névből, amelyikre az instancia telepítve
lett (ami lehet fizikai, alias vagy virtuális hoszt név),
A gyakorlatilag tetszőleges számú alkalmazás szerver instanciák között mindig van
egy kitüntetett ún. központi instancia (central instance), mely a teljes SAP rendszerre
vonatkozó egyedi szolgáltatásokat nyújtó processzeket tartalmazza. Ezek a
szolgáltatások az ún. message server és az enqueue server. A message server az
alkalmazás szerver instanciák közötti kommunikációban és a terhelés elosztás
vezérlésben van szerepe, míg az enqueue server egy SAP rendszeren belül az
alkalmazás szintű központi zárolásért felelős.
Ha message és az enqueue szolgáltatás egy alkalmazás szerver részeként futnak,
akkor azt központi vagy centrális (CI) instanciának nevezzük, míg ha ezek önálló
instanciaként futnak, akkor azt SAP Central Service-es (SCS) instanciának nevezzük
vagy ABAP Central Service Instanciának (ASCS), attól függően, hogy melyik futtató
környezet része. Mivel ezen komponensekből csak egy van illetve egy lehet egy SAP
rendszeren belül, ezért ezeket – az adatbázis kezelővel együtt - operációs rendszer
szinten kell védeni, pl. az adott platformon elérhető fürtözési (cluster) technológiával,
melyre számos megoldás létezik, amivel a SAP is együtt tud működni különböző
platformokon. Ilyen pl. a HP Service Guard for Cluster Solution megoldás a HP-UX-
on, Sun Cluster Solaris-on, vagy a Microsoft Windows környezetben a Microsoft
Cluster.
Fontos megjegyezni, hogy az SAP Adaptive Design elméletet alapján több node-os
„multi-node-cluster” is kialakítható, vagyis az instanciák több node között is
vándorolhatnak. Ez esetben nem érdekes, hogy a host-ok fizikai vagy virtuális
kiépítésben jelennek meg.

43
Ábra 3-3 C11 SAP rendszer instancia felépítése (példa)
Egy SAP rendszernek egy vagy több alkalmazás szervere lehet, a rendszer által
megvalósított funkciótól függően ezek vagy csak ABAP vagy csak JAVA alapú
instanciák lehetnek, illetve kialakítható olyan rendszer is, amely mindkét típusú
futtató motorral rendelkezik.
Az alkalmazásszerverek többszörözése természetesen egyúttal szolgálja a teljes
rendszertől elvárt rendelkezésre állás biztosítását is – lévén az egy rendszerhez
kapcsolódó alkalmazás szerverek egyenran-gúak, a rendszer összes funkcióját
nyújtják a felhasználók felé.
A produktív rendszer szemszögéből gyakorlatilag nincs korlát a kapcsolódó
alkalmazás szerverek számára vonatkozóan. A rendelkezésre álló fizikai erőforrások
határáig az egyes rendszerekhez a csúcs-terhelés jellegű igények rugalmas
kiszolgálására dinamikusan, az éles üzem közben is rendelhetünk alkalmazás
szerver instanciát, instanciákat. A menetközben bekapcsolt új alkalmazás
szervereket a rendszer automa¬ti-kusan használatba veszi, a felhasználók azt
gyakorlatilag azonnal elérhetik.
Az adatbázis kezelő szintjén is lehetőség van hasonló módon robosztus és
skálázható architektúrát kialakítani, olyan technológiák használatával, mint az pl.
Oracle Real Application Cluster, melyet az Oracle 10-es verziójú adatbázis kezelővel
az SAP rendszerek által is támogatott számos operációs rendszer platformon
(Solaris, HP-UX, AIX, Linux, Windows Server, AS/400, OS/390).

44
Az alkalmazási réteg skálázhatósága, bővíthetősége, azaz az architektúrának az a

képessége, hogy a rendelkezésre álló hardver-kapacitást optimálisan kihasználja
illetve az, hogy minél kevesebb ún. Single-Point-of-Faile (SPOF) komponens legyen
a rendszerben az egyes instanciákon belül, az általuk nyújtott szolgáltatások terén is
megnyilvánul.
A Web AS ABAP szolgáltatásai
Az ABAP alkalmazás szerver – Web AS ABAP, vagy más néven dialóg - instanciák
az alábbi szolgáltatá-sokat nyújtják:
• Internet Communication Manager (ICM): alapvetően a Web alapú vagy
SMTP típusú kapcsolatokért felelős processz. Mind a http, mind a https típusú
kapcsolatokat támogatja, akár mint Web szerver, akár mint Web kliens-ként
működik az adott relációban a Web AS. Egy alkalmazás instancián belül
egyetlen – többszálú működést megvalósító – ICM szolgáltatás áll
rendelkezésre, de egy rendszeren belül – alkalmazás szerverenként – több is
van. A Web alapú klienseket használó felhasználók technikai értelemben a
ICM processz által meghatározott http vagy https portokhoz kapcsolódnak,
melyek konkrét értéke konfigurációból állítható. Amennyiben az instancia
architektúrája ABAP+JAVA, az ICM processz egy úttal szétosztja a Web AS-
hez érkező Web-es kéréseket, aszerint, hogy az ABAP vagy a JAVA motor
számára releváns. Ezt a döntést a meghívott szolgáltatás URL-je alapján
hozza meg az ICM.
• Az ABAP dispatcher processz végzi a SAPGui kliens felől érkező
felhasználói kérések továbbítását az egyes ABAP munka-processzek felé.
Amennyiben minden munka-processz foglalt, a kérés a dispatcher várakozási
sorába kerül, ahol addig várakozik, amíg fel nem szabadul egy munka-
processz.
• A munka-processz (work-processz) hajtja végre az ABAP programokat. Az
alkalmazás szerveren belül számos work-processz működik, melyek
különböző típussal rendelkeznek, az elvégzendő feladatra-típusra
vonatkozóan. Megkülönböztetünk:
o dialog – online tranzakciós lépések feldolgozását végző munka
processzek.
o batch – kötegelt azaz háttért jellegű feldolgozás végző processzek
45
o update, update2 – alkalmazási rétegben definiált konzisztens

adatbázis módosítást végrehajtó eljárások, ún. update taszkok
végrehajtására.
o Spool – nyomtatási feladatok végrehajtása, beleértve a formázást, a
megfelelő code-page-re való konvertálást és a – pl. lokális vagy
hálózati - nyomatatóra való továbbítást.
E munka processzek mindegyikéből lehet több is egy dialóg vagy
centrális instancián belül, azonban összességében a Web AS ABAP
instanciákként számuk összesen nem haladja meg a 40-45-öt. Mivel
minden instanciát – annak minden munka-processzét - csak egyetlen
dispatcher processz szolgál ki, így további munka-processzek
megjelenése már a diszpécseren okozna szűk keresztmet¬szetet.
Amennyiben az adott hoszt erőforrásai ezt lehetővé teszik, inkább
tovább alkalmazás szerverek kialakítása javasolt.
• A SAP gateway processz segítségével tudnak a SAP instanciák egymással
és azt támogató kapcsolódó rendszerekkel kommunikálni az ún. RFC
(Remote Function Call) interfészén keresztül. Instanciáként egy gateway
processz van, de bizonyos esetekben az is előfordult, hogy az instancia nem
is tartalmaz más processzt. Ilyenkor ún. Gateway Instanciáról beszélünk.
• A message server processz – mink korábban már említettük – egyedi
processz egy teljes SAP rendszeren belül. Fő feladata a instanciák közötti
kommunikáció és koordináció biztosítása illetve az instanciák közötti
teherelosztás megvalósítása (felhasználói dialog, batch és update feladatok
teherelosztásra lehetséges)
• Az enqueue server processzből is csak egy aktív lehet egy SAP rendszeren
belül. Ennek feladata a SAP alkalmazás szintű logikai objektumzárolások
kezelése. Egy fail-over szituáció a zárolási információ védelmét szolgálja egy
enqueue replication server kialakítása, ahova az aktuális SAP szintű logikai
zárolásokról fájlszintű mentés készül, amely alapján pl. egy cluster switch-over
után az enqueue szerver információ veszteség nélkül újraindulhat.
Egyfajta magas rendelkezésre állású konfigurációban a message és az enqueue
szerver processze képezhet egy önálló instanciát: az ABAP Central Service

46
Instanciát (ASCS), míg egyéb esetben egy alkalmazás szerver részei, amit ilyenkor
centrális instanciának (CI) nevezünk, szemben az egyszerű dialóg instanciákkal.
Amennyiben egy SAP rendszeren belül több alkalmazás szerver van, közöttük
bejelentkezés idejű terhelés-elosztás működik – az ún. logon load balancing. Ennek
központi eleme a message server, mely eldönti, hogy a SAPGui felül érkező
bejelentkezési igényt az instanciák pillanatnyi terhelésétől függően, melyik
alkalmazás szerverre továbbítsa. A kliensnek már ezt a instancia küldi a logon
képernyőt.
Az egyes alkalmazás szervereket ún. logon csoportokba szervezhetjük. A
felhasználó a rendelkezésre álló logon csoportok közül választhatnak, a
bejelentkezés során, illetve meghatározhatjuk, hogy a felhasználók egy csoportja
mely logon csoportra jelentkezhet be. A logon csoportokhoz rendelt instanciákat
üzem közben is módosíthatjuk, így rugalmasan tudjuk alakítani, hogy a felhasználók
egy adott csoportjához mennyi erőforrást akarunk vagy tudunk allokálni.
A bejelentkezés idejű teherelosztás természetesen csak úgy tud hatékonyan
működni, ha a felhasználók időről időre újra bejelentkeznek. Ezt úgy tudjuk elérni,
hogy az inaktív felhasználókat, paraméterben meghatározható időintervallum után
(pl. 1 óra) automatikusan kijelentkezteti a rendszer.
Az instancián belüli teherelosztást – vagyis az egyes munka-processzek között – a
dispatcher processz végzi.
Az instanciák között teherelosztás nem csak az online (dialog) felhasználók esetén
működik, hanem a batch, az update és az RFC típusú műveletek esetén. Azaz a
rendszer lehetőséget ad, hogy az egyes instanciákat background-, update- vagy
RFC group-okba szervezzük és egy-egy kérést csak az adott csoporthoz rendelt
instanciákon hajthassunk végre. Így a különböző típusú terheléseket SAP
rendszeren belül is elhatárolhatjuk az erőforrások egy az instanciák által
meghatározott csoportjára.
Alapértelmezetten a rendszer természetesen az összes rendelkezésre álló
alkalmazás szerverre megpróbálja szétteríteni ezeket terheléseket és az esetek nagy
részében ez a stratégia kielégítő teher¬eloszlást eredményez.
A Web AS JAVA
A Web AS JAVA alkalmazás szerver struktúráját az alábbi ábrán mutatjuk be.

47
Ábra 3-4 SAP Java engine struktúra (service.sap.com)
Az SAP definíciója szerint az ún. „JAVA cluster” egy vagy több JAVA instanciából és
a – már említett - Central Services instanciából áll.
A JAVA instancia az az egység a JAVA cluster-en belül, amely egy önálló, független
egységet alkot a rendszer indítása, leállítása, monitorozása szempontjából. Az egy
instanciát alkotó JAVA cluster elemek, mindig egy hoszton futnak, illetve egy fizikai
hoszton több JAVA instancia is futhat, melyeket az ún. instancia szám
megkülönböztet meg és választ el egymástól. Hasonlóan az ABAP instanciához , a
JAVA instanciát is a rendszer neve (SID), az instancia száma és azt futtató hoszt
neve határoz meg egyértelműen.
Ábra 3-5 SAP Java instancia (help.sap.com)
A JAVA instancia az alábbiakból áll:

• Pontosan egy Java Dispatcher processzből: a Java dispatcher fogadja a
kliens-től érkező felhasználói kéréseket és továbbítja a legalacsonyabb
terheléssel bíró szerver processzek felé. Amennyiben a kérést küldő kliens
már aktív session-nel rendelkezik a diszpécseren, a kérést a korábban a user-
48
session-höz rendelt server processz fogja megkapni. A szerver processzek

között tehát a dispatcher egyrészt terhelés elosztást, más részt session
management-et végez. Szintén a dispatcher felelős az adott JAVA instancia
kommunikációs szolgáltatásainak üzemeltetésért, (pl. http, https, JCo)
• JAVA Server processz: A szerver processzeken futatnak a Web AS JAVA-ra
telepített a J2EE kompatibilis SAP alkalmazások. A processzeken több-szálú
(multi-threaded) végrehajtás történik, így – szemben az ABAP munka
processzekkel – egy időben több párhuzamos kérést szolgálnak ki, több
felhasználó session-jét kezelik. Egy JAVA instanciába mindig van legalább
egy szerver processz, de általában nem több mint 8-10. Ha rendelkezésre álló
erőforrások lehetővé teszik az adott fizikai hoszton, az instancián belül további
JAVA szerver processzek helyett, új JAVA instanciákat javasolt kialakítani,
melyek szintén rendelkeznek saját dispatcher processzel.
• Central Service instancia (SCS): egy speciális példánya a JAVA
instanciáknak, hasonlóan az ASCS instanciához, kommunikációs és
szinkronizációs feladatokat lát el az JAVA cluster-en belül. Egy Java cluster-
en belül (vagy a SAP rendszeren belül) egyetlen SCS instancia létezhet. Az
SCS instancia elemei:
o A Message Server processz: nyilvántartja a JAVA cluster struktúráját,
(diszpécserek és server processzek eloszlása) biztosítja a
kommunikációt a cluster elemei között és a JAVA instanciák között
kliens oldali terhelésmegosztást is megvalósít a http/https protokoll
felett.
o Az Enqueu Server processz kezeli a logikai adatbázis zárolási
kérelmeket, melyeket a JAVA szerver processzeken futó
alkalmazásoktól erednek.
A JAVA cluster részeként még egy instancia típus megjelenik, az ún. Software
Deployment Manager (SDM). Ez általában Web AS JAVA adatbázis szerverén fut.
Az SDM, amely egy kliens-szerver architektúrával rendelkező komponens
segítségével telepíthetünk új alkalmazásokat, vagyok azok újabb verzióit, patch-eit a
Web AS JAVA rendszerekre. Az alkalmazások vagy patch-ek kiszállítása a SAP
(vagy a JAVA fejlesztők) által összeállított JAVA szoftver archívumok formájában

49
történik, melyeket Software Deployment Archive-nak (SDA) vagy Software

Component Archive-nak (SCA) nevezünk.
A JAVA alkalmazások telepítése az SDM segítségével a Web AS JAVA
adatbázisába és kis részben a fájl-rendszerbe történik, mivel – hasonlóan az ABAP-
hoz – itt is az adatbázisban van nyilvántartva a rendszer repository-ja. Az egyes
instanciák a telepítés/patch-elés utáni első induláskor a verzió-management
segítségével észlelik a telepített új szoftver verziókat, és azokat átmásolják a saját
fájlrendszerük munka-területére. Az ABAP-pal ellentétben a JAVA Runtime
Environment ugyanis csak a fájlrendszerről tudja futtatni a JAVA alkalmazások
bytecode formában tárolt programjait. (Az ABAP alkalmazások futatható, ún. „ABAP
Load” formátumát, közvetlenül az adatbázisból tölti be az ABAP motor a saját
program pufferébe.)
A JAVA archívumok és szoftver komponensek központi tárolása az SAP
adatbázisban biztosítja, hogy a teljes JAVA cluster-en belül, konzisztensek a
telepített JAVA alkalmazások verziói.
Terhelés megosztás a Web alapú kliensek esetén

A JAVA alapú alkalmazások elérése a felhasználók által kizárólag http/https
protokollon keresztül lehetséges.
A felhasználó számára transzparens, szerver oldali terhelés megosztást egy önálló
komponens, a SAP Web Dispatcher szolgáltatja. A Web Dispatcher mind a Web AS
ABAP-on, mind a Web AS JAV A-n futó web alapú alkalmazások esetén használható
terhelés megosztásra, sőt a bejövő kérés URL-je alapján képes eldönteni, hogy az
egy ABAP vagy egy JAVA alkalmazás szerver számára releváns-e.
A SAP Web Dispatcher a Web kliens között és a web-es alkalmazás futtató SAP
rendszer között helyezkedik el. A bejövő http vagy https kéréseket továbbítja az
alkalmazás szerverek felé, függően azok pillanatnyi kapacitásától és
konfigurációjától. Az ABAP esetében pl. a konfigurált work-processz számtól, az AS
JAVA esetén a szerver processzek számától.
Az adott pillanatban megfelelő alkalmazás szerver kiválasztásához információt a
message szerver processztől kapja a Web Dispatcher is.
A Web Dispatcher természetesen állapotfüggő (session statefull) módon viselkedik a
session orientált alkalmazások terhelés elosztása esetén, azaz egy élő http/https
50
session-höz tartozó felhasználói kérést az azt kiszolgáló Web AS instanciához

továbbítja.
A SAP Web Dispatcher egy tipikus alkalmazási lehetőséget mutatja a lenti ábra,
amikor is a védendő Web alkalmazás szerverek egy tűzfal zóna mögött, egy belső
szerver hálózaton helyezkednek el, viszont a felhasználóknak elegendő elérniük a
DMZ zónába elhelyezett SAP Web Dispatcher szervert. A külső hálózat (pl. Internet)
és a DMZ zóna közötti tűzfalon csak a Web Dispatcher portját kell engedélyezni, míg
a belső hálózat felé csak magát a Web Dispatcher gépet kell beengedni.
Ábra 3-6 SAP web-es terheléselosztás (help.sap.com)
3.3 Az SAP bővítési lehetőségei hardver szempontból

Az SAP architektúra adottságaiból következően az alkalmazási logikát futtató ún.
alkalmazási instanciák számossága szabadon bővíthető. Általában egy központi
adatbázishoz számos alkalmazási instancia csatlakozhat ezzel ellátva a
(horizontális) skálázhatóság, valamint a terheléselosztás funkcióit is. (Terminológia
szempontjából azt a szervert, amin alkalmazási instancia fut, alkalmazás szervernek
szokás nevezni.) A terheléselosztás, ill. a szolgáltatások folyamatos biztosítására az
SAP a következő eszközöket, lehetőségeket kínálja:
• Dialógusszolgáltatás: Bejelentkezési csoportokat (Logon Group) kell
kialakítani, melyekhez legalább két alkalmazásszerver van definiálva. Ezzel
elérhető, hogy a felhasználó az egyik szerver kiesése esetén újra
bejelentkezhessen.

51
• Update szolgáltatás: Minden alkalmazásszervert úgy kell konfigurálni, hogy

legalább egy update processz fusson rajta.
• Batch szolgáltatás: A terheléselosztás lehetővé teszi, hogy egy job bármely
rendelkezésre álló background szolgáltatást nyújtó szerveren elindulhasson.
Legalább két alkalmazásszervert úgy kell konfigurálni, hogy „A” típusú jobokat
futtathasson. Lehetőleg kerülni kell a jobok szerverhez rendelését, mert
esetleg nem tud a job az ütemezett időben elindulni.
• Spool szolgáltatás: (Csak hálózati nyomtatás esetén érdekes.) Minden olyan
nyomtatót definiálni kell az összes alkalmazásszerveren, az
operációsrendszer szintjén mely nem hálózati, ill. Frontend nyomtató, hanem
az SAP alkalmazásszerver operációs-rendszere biztosítja a nyomtatási
queue-t. Logikai spool szervereket kell kialakítani alternatív lehetőségekkel. A
nyomtatókat az SAP rendszerben a hierarchiában legmagasabban álló logikai
spool szerverhez kell rendelni, ezzel elérhető, hogy az alternatív spool
szerverek között terhelésmegosztás jöjjön létre, valamint hogy az egyik spool
szerver kiesése esetén manuális beavatkozás nélkül átvegye egy másik a
feladatot.
A fent említett szolgáltatások az instanciákban különálló operációs-rendszer szintű
processzekként jelennek meg. A végfelhasználó felé történő kommunikációra egy
kiemelt, az ún. dispatcher processz szolgál. Ez fogadja a kérelmeket, majd osztja
szét a kérelem függvényében a megfelelő várakozó processzeknek az adott
instancián. A terhelés elosztáshoz ez még nem lenne elég, ezért egy központi,
rendszer (nem instancia) szintű processz, az ún. message szerver gondoskodik az
instanciák közötti üzenetküldésekről, valamint a teljesítmény információk gyűjtéséről.
Bejelentkezési csoportokat használva a message szerver mutatja meg, hogy melyik
szerveren van olyan szolgáltatás, amit használni akar a kérelem, ill. melyik az az
instancia, amelyik legkevésbé terhelt.
A hardver bővítésekor, vagyis amikor új alkalmazási instancia kerül installálásra,
annak elindítása után a rendszergazda felveszi a kívánt bejelentkezési csoportokba.
Ezzel az új bejelentkezők már az új szervert is látják, ill. arra is kerülhetnek a
terheléselosztás jegyében, valamint a háttér, spool és update szolgáltatások
automatikusan használatra kerülnek.

52
A skálázhatóság nem csak az alkalmazási rétegben lehet elvárás, hanem a

prezentációs és adatbázis rétegekben is. A prezentációs réteg esetén akkor
beszélhetünk horizontális skálázásról, ha prezentáció összeállítása nem a
végfelhasználónál fut, hanem egy újabb köztes rétegen. Az SAP esetében két ilyen
lehetőség van, az egyik, amikor Web alkalmazásokat futtatunk (akár SAPGUI for
HTML, akár BSP alkalmazás vagy WebDynpro), a másik, amikor terminál szerveres
megoldáson fut a prezentációs logika. Az első esetben az SAP rendelkezik az
alkalmazás szerver szintbe integrált technológiával, vagyis az alkalmazás szerverek
skálázása magával hozza a prezentáció skálázását is. A második esetben a terminál
szerver megoldás skálázása adja a megoldást.
Az alkalmazási rétegben mindenképpen lehetőség van a horizontális
skálázhatóságra (lásd előzőek), sőt javasolt is. Amennyiben az alkalmazás réteg
nem egy nagy vertikálisan skálázható környezetben kap helyet, hanem több kisebb
párhuzamos (vagyis horizontálisan skálázott) környezet biztosítja a hozzáférést,
megnő a biztonság. Ez azért érthető, mert egy kisebb szerver kiesése nem okoz
látványos performancia romlást az egy nagyhoz képest. Bővítés során pedig
költséghatékonyabb olcsó, kisebb kapacitású egységekkel növelni a környezetet.
Az adatbázis rétegben nem az SAP adja a horizontális skálázhatóságot, hanem az
adatbázis-kezelő motor. Erre manapság már több gyártó is ad megoldást.

53
SAP technológiai architektúra Fejlesztés az SAP környezetben
4 Fejlesztés az SAP környezetben

Ez a fejezet összefoglalja az SAP NetWeaver alalpú rendszerek felépítését főleg
ABAP stack használata esetén. (A Java stack is említésre kerül, azonban az üzleti
szempontból, így fejlesztési szempontból sem olyan jelentős, mint az üzleti
megoldások alap fejlesztési platformja, az ABAP stack.)
Részletezzük az ABAP adatstruktúrát, több rendszeres környezet használatát,
mandantok (client) kezelését, valamint a korraktúra és transzport rendszer alap
felépítését, használatát fejlesztői és architektúrális szemszögből.
4.1 SAP Adatstruktúra (ABAP)

Az SAP-rendszer mandantokon alapuló rendszer. A mandantok miatt lehetséges az,
hogy egy SAP-rendszerben több, üzemgazdaságilag egymástól független vállalatot
együtt lehet kezelni. Minden felhasználói session-nél csak a bejelentkezéskor
kiválasztott mandant adataihoz lehet hozzáférni. A több mandantos környezet a mai
világban újra megjelenik, mint multi-tenant megoldás.
A mandant az SAP rendszer olyan egysége, ami technikailag, szervezetileg és
kereskedelmi szempontból önálló. Táblakulcs tartományon alapuló saját felhasználói
törzsadattal, alkalmazási adattal és customizing lehetőséggel rendelkezik. Az alábbi
ábra zöld résszel jelöli a mandantokat. Mint látható, egy rendszerben több mandant
is lehet egyidejüleg és ezek egy 3 számjegyű azonosítóval vannak ellátva.
Az SAP rendszer különféle adattípusainak megfelelően különféle típusú módosítási
és személyes beállítási lehetőségeket kínál. Mivel az ERP rendszer standard
szoftver, bevezetésekor adaptálni kell a konkrét vállalathoz. Ezt az adaptációs
folyamatot nevezzük customizingnak, mely tartalmazza a képen ábrázolt mandant
függő és mandant független customizing-adatokat. Bizonyos esetekben - noha
lényegesen csekélyebb terjedelemben - az ERP rendszer upgrade-je esetén is végre
kell hajtani beállításokat, utómunkálatokat.
A customizing fejlesztése és tesztelése nem ugyanabban a mandantban történik,
mint a produktív üzem. Emiatt az ERP minden implementálásakor több mandantra
van szükség (ahogy később olvasható). A customizing végrehajtása és tesztelése
egy mandantban történik.

54
Ábra 4-1 ABAP Stack adatstruktúrája
Ezen adatokat mandantfüggő adatoknak nevezzük. Egymástól függenek és

összetartoznak.
Amint látható a felhasználói törzs, ami nem csak a felhasználói azonosítókat,
neveket, stb. tartalmazza, de a jogosultság definíciókat, ún. jogosultsági profilokat és
szerepeket is. így egy felhasználói azonosító ugyanabban a rendszerben ha jelen
van több mandantban, akár teljesen különböző jogokkal is rendelkezhet.
A customizing az alapja az SAP rendszereknek. Beállítások nélkül egy installált
SAP rendszer nem használható, mert semmilyen folyamat nem tud működni. A
customizing maga egy mandant beállításait jelenti, lényegében számos
táblatartalom, érték meghatározása, melyek vezérlik a képernyőn megjelenő
mezőket, értéklistákat, a folyamatok lefutását, stb. Elképzelni úgy lehet, mint egy
összetett hangtechnikusi púlt tele potméterekkel, állítási lehetőségekkel.
A mandantok beállítására szolgáló mandantfüggő customizing mellett egy, a teljes
rendszer egészére vonatkozó beállítási halmaz is idetartozik, az ún.
mandantfüggelten customizing köre. Ide tartozik pl. a hivatalos országhoz rendelt
ünnepnap naptár, nyomtatók definíciója, stb. E kettő beállításhalmaz magába öleli az
alkalmazási adatokat, amik a törzsadatokból és mozgási, vagy tranzakciós adatokból
állnak.

55
Amint az ábra is mutatja a fejlesztési objektumok halmaza,vagy más néven

repository objektumok szintén rendszerfüggőek, vagyis minden mandantban azonos
képet mutatnak. Fejlesztési objektumokat két alap csoportba osztjuk: az adatok
tárolására szolgáló alap elemek, táblák, adatelemek, domének, amik az adatszótár
(ABAP Dictionary vagy Data Dictionary) részei, valamint az ezekre épülő ABAP
programok, képernyők, objektum-orientált osztályok, funkciós elemek és számos
más objektum. Mindennek alapja az adatszótár, hiszen ez hordozza a rendszer
tábláinak leírását. Futásidőben is ez a központi elem, hiszen a korábban tárgyalt
SAP work-processek is ezt a komponenst szólítják meg. Ezt jelképezi az alábbi ábra,
ahol a repository objektumokat hasonló színnel jelöltük, viszont a work-process főbb
részeit vöröses színek jelzik.
Ábra 4-2 ABAP Stack - Work-process és adatszótár kapcsolat
Amint látható az ABAP és Dynpro értelmezők is folyamatosan az adatszótárhoz

fordulnak információért, ABAP program esetén pl. tábla felépítése adat
beolvasáshoz, dynpro esetén a képernyőn megjelenő beviteli mező típusa, hossza,

56
címkéje, stb. az adatszótárból származik. Ennek megfelelően az adatszótár egy

jelentős része pufferelt az alkalmazási instanciákon.
Az Ábra 4-1 ABAP Stack adatstruktúrája jelzi számunkra, hogy nem csak a
csomagokba (package) rendezett modul specifikus fejlesztési objektumok, hanem a
technológia, ún. bázis csomag részei is ide tartoznak. Nagyon fontos ez az
információ, mert azt is jelzi, hogy lényegében a futtatható állományon kívül az SAP
rendszerek mindent az adatbázisukban tartanak. A csomagok szemantikusan
összekapcsolódó fejlesztési objektumok gyűjteménye. Hierarchia képezhető belőlük
és magas szinten SAP komponensekbe gyűjtik őket. Az alábbi ábrák szemléltetik a
csomagok definícióját, kapcsolatát, hierarchiáját.
Ábra 4-3 Egy csomag alap adatai ©SAP

57
Az fenti ábra a kiválasztott (AR) csomag alapadatait tartalmazzák. Sok adat

olvasható ki innen. Egyrészt látható, hogy kihez tartozik, vagyis egyértelműen
standard, SAP által kiszállított csomagról beszélünk. Leolvasható, hogy mely
alkalmazási komponens része a csomag, valamint még az is, hogy melyik
szoftverkomponenshez tartozik. Hierarchiát tekintve szofverkomponenseket szállít ki
az SAP, melyekben alkalmazási komponensek találhatók.
Fejlesztési szempontból érdemes megemlíteni a „transport layer”, vagyis transzport
réteg mezőt, ugyanis ez mutatja meg, hogy egy adott csomagba tartozó objektum
módosítása után milyen útvonalon lehet a szoftvermódosítást tovább vinni más
rendszerekre. (Erről még később olvashatunk.)

58
Ábra 4-4 Egy csomag hierarchia besorolása ©SAP
Ahogy a fenti ábra mutatja, az AR csomag része az APPL magasabb szintű

csomagnak, azonban ebben a csomagban még a kép alján kiemelt alacsonyabb
hierarchia szintek is megjelennek.

59
Ábra 4-5 Csomag függőség-használat ©SAP
Az újabb SAP verziókban a csomagok között összefüggések definiálhatók (az

ügyfeles fejlesztéseknél ezt ritkán használják még ki), melynek lényege, hogy így
csomagok függetleníthetők egymástól, ha nem használhatók egymás elemei. Azt a
célt szolgálja ez a megoldás, hogy bizonyos csomagok, illetve magasabb szinten
komponensek külön kezelhetők azonos rendszerben, akár külön verzionálás is
lehetséges, mivel nem függenek egymástól. Programozástechnikailag ez azt is
jelenti, hogy adott funkciók akát redundánsan is jelen lehetnek a rendszerben, hogy a
függetlenség fenntartható legyen. Bár feleslegesnek tűnik a redundancia, viszont
verzió és licenszelési elhatárolásokat tesz lehetővé.

60
Ábra 4-6 Installált komponenslista ©SAP
A fenti ábrán kiemelésre került a csomagot hordozó standard SAP komponens. Itt
látható, hogy valóban saját verziója van, illetve az is, hogy a rendszerben levő (az
ábrán látható) komponensek között eltérő verziók illetve ún. SP (Support Package)
szinteket használnak.
A fenti ábra az SAP patch manager tranzakciójából, a SPAM-ból származik. A saját,
ügyfeles fejlesztéseket itt nem találjuk meg, mivel nem SAP standard kiszállításhoz
tartoznak.
4.2 Bővíthetőség, fejlesztési lehetőségek

Az SAP rendszereket a bevezetés során az ügyfél igényeinek megfelelően kell
módosítani. A módosítás nem csak fejlesztést és tényleges program módosítást
jelent, hanem számos szintje van a rendszer testreszabásának. Az alábbi ábra
összefoglalja képletesen, hogy az egyes szintek hogyan is ölelik egymásba magát a
standard alap kódot.

61
Ábra 4-7 Szofver hozzáférési szintek bővítéseknél
Az ábrán szereplő módosítási szinteket az alábbi részekre bonthatjuk:

• Customizing: Üzleti folyamatok és funkciók beállítását jelenti az IMG szerint.
(Az IMG, vagyis az ún. Implementation Guide, központi customizing vezérlő
környezet, amiben lehetőségünk van projektek definiálására, beállítások
dokumentálására, stb.) Ezeket a módosítások az SAP már előre látta, így
bevezetési eljárásokat (pl. tábla adatok módosítása) fejlesztett ki hozzájuk.
• Testre szabás (Personalization): Bizonyos mezők általános megjelenési
jellemzőinek a beállítása (pl. default értékek beállítása, vagy egy mező teljes
eltüntetése), valamint felhasználó specifikus menü készítése tartozik ide.
• Módosítás (modification): Az SAP Repository objektumainak az ügyfél által
történő változtatását jelenti. Ha az SAP kiszállít egy javítást a sztenderd
objektumra, az ügyfél rendszerében egyeztetést kell végrehajtani (SPAU,
SPDD). A Modification Assistant segítséget nyújt ebben a műveletben.
• Bővítés (Enhancement): Olyan ügyfeles Repository objektumok készítését
teszi lehetővé, amik az SAP Repositoryban meglevő objektumokra
hivatkoznak. Nem sztenderdmódosítások, viszont a sztenderdműködést
befolyásolják.
• Fejlesztés (development): Ügyfelek számára fenntartott névtartományban
készülő Repository objektumok.

62
Ábra 4-8 Bővítési szintek SAP környezetben
Ezek a tevékenységek a konfigurációhoz tartoznak, azonban nem csak

paraméterezés, hanem bizonyos esetekben fejlesztés is szükséges. Ezek
legalapvetőbb példányai a bevezetés során felmerülő riportok, ill. űrlapok testre
szabása. Nem új fejlesztések ezek a legtöbb esetben, mert az SAP nagyon sok előre
gyártott riportot, ill. űrlapot szállít ki, amik kiindulásként szolgálnak. Amint látható fent,
háromfajta fejlesztés különböztethető meg: módosítás, bővítés és fejlesztés.
Mindhárom típushoz az ABAP Workbench környezetet használhatjuk, azonban a
fejlesztések eredetiségében rejlenek. Az SAP rendelkezésre bocsátja az összes
ABAP forráskódot, vagyis a rendszerben megvizsgálható az összes modul üzleti
folyamata. Ezen felül az ABAP Workbech eszközökkel nem csak megjeleníthető,
hanem akár módosíthatók is a kódok. Azonban a kiszállított, sztenderd kódok
módosítását óvatosan kell végezni, mert az SAP rendszeresen szállít ki javítási
útmutatókat, ill. csomagokat. A javító csomagokkal kiszállításra kerülő fejlesztési
objektum új verziója felülírhatja a saját módosításokat. Ezeket a rendszer
természetesen verziókezeléssel rendben tartja (lásd később). Amikor egy ügyfeles
folyamat miatt a sztenderd objektumot módosítani kell, mind a három lehetőség
rendelkezésünkre áll. Azaz lemásolhatjuk az eredeti objektumot, és mint sajátunk
tovább fejleszthetjük. (Ez nem mindig praktikus, mert a javító csomagok kiszállítják
az új verziót és annak átvezetése a saját kódra nehézkes.) Módosíthatjuk a
sztenderd objektumot is, ahogy feljebb említésre került. Azonban az SAP felkínál

63
számos belépési pontot, ahova a saját fejlesztéseinket, bővítéseinket helyezhetjük el

úgy, hogy nem minősül sztenderdmódosításnak, vagyis javítócsomaggal érkező új
verzió nem érinti a saját fejlesztést.
Az SAP igyakszik az alábbi folyamatot, kezelési szintet követni fejlesztéseinek
konfigurálhatóságában.
Ábra 4-9 Módosítási és hozzáférési szintek összefüggései
Az ábra egyszerre több információt hordoz. Látható rajta a korábban említett

fejlesztési, bővítési szintek kezelése, valamint a futásidőben történő további
módosítási, beállítási lehetőségek használata. A kép tetején levő balra haladó nyilak
és a módosítási fajtákat mutató dobozok mérete jelzi, hogy minél technikaibb szintre
megyünk, annál több dolog állítható be. A beállítást végzők köre persze éppen
csökken, hiszen személyre szabott felületet mindenki magának végezheti el,
ugyanakkor fejlesztést, csak a „kiválasztottak” végezhetnek.

64
Az alsó, jobbra irányuló csökkenés jelzi, hogy a beállítás milyen körre hat. A
fejlesztés módosítása minden megoldásra, ahol használják, a customizing
lényegében mandanton belül, a testreszabás pedig az adott felhasználó számára.
Vagyis bár a beavatkozók köre nő jobbra haladva, a módosíthatóság mennyisége,
kihatása csökken. A végén már szinte csak kinézeti különbségek érhetők el.
Érdemes megjegyezni, hogy a végfelhasználói felület ténylegesen alakítható minden
végfelhasználó számára (pl. Screen Personas, GuiXT, stb.). Ez azonban a
támogathatóságot jócskán ronthatja, hiszen a támogató a standard felületet látja és
nem tudja mi minden módosítást végzett a végfelhasználó a felületen.
A bővítési koncepció szerint az SAP programok az ügyfél által készített, módosított
Repository objektumokat hívnak meg. A következő területeken van lehetőség
bővítésekre, vagy user exitek-re:
• ABAP programokban (funkciós modul exit)
• GUI interfészben (menü exit)
• egy dynprón, egy újabb alképernyő (subscreen) behelyezésével (screen exit)
• egy dynprón, egy specifikus képernyő mező feldolgozására szolgáló ügyfeles
kód (field exit)
• ABAP Dictionary táblákban és struktúrákban (table enhancement)
A bevezetések során legtöbbször a programokban elhelyezett funkciós modul exit-
eket, más néven customer exit-eket használják. Ezek olyan funkciós építőkockák,
amik egy, az ügyfeles névtartományba eső include programot tartalmaznak. Ez a
program kezdetben üres. A user-exit használatakor kitöltésre kerül és a sztenderd
kód a függvény meghívásával az ügyfél kódját hajtja végre.
A user-exitek közé kellene sorolni a Business Add-In (BadI) megoldást is. Az SAP a
4.6x és későbbi bázis release alapú rendszerekben vezette be ezt az objektum
orientált megoldást az ügyfeles bővítésekre. A BAdI esetében lehetőség van
szűrésre, ill. többszörös implementálásra is, vagyis egy belépési ponthoz több saját
kód is rendelhető, melyek mindegyike, ill. szűrés esetén adottak futnak le. Így
belépési ponttól függően akár szűrni lehet vállalatkódra, stb.
A mai SAP rendszerek esetén tovább bővült a fejleszési objektumok bővítésének
tára, ugyanis ún. Enhancement Point-ok illetve Enhancement Session-ök jelentek
meg. Ezeknek nincs megfelelő magyar változatuk, bár nyers fordítás adható rájuk.
Ugyanakkor fontos, hogy technikailag ezek explicit módosítási pontokat illetve
65
kódrészeket adnak meg. Ez azt jelenti, hogy adott ponton (hasonlóan a user-exit-
hez) beléphetünk a standard kódba és ott a saját kódrészletünket futtathatjuk. A
session esetében van egy standard kódrészlet, ami lényegében cserélhető sajátra.
Az új Enhancement környezet (Enhancement Framework) lehetővé teszi implicit
bővítések alkalmazását is, pl. minden program, eljárás elejére és végére saját kód
illeszthető. Ezeket a környezet külön programokba helyezi és külön is kezeli, de ha
aktívak, akkor meg is hívja futtatáskor. Fontos kiemelni, hogy az Enhancement
Framework lehetővé teszi bővítések (amik tartalmazhatnak különböző bővítési
megvalósításokat) ki és bekapcsolását, vagyis eldönthető, hogy használják-e.
Mivel az objektum-orientált kódolás és megvalósítás kezdi a rendszert teljesen
lefedni, így az ehhez kapcsolódó elemek esetén is szerepet játszik a bővítés. Ennek
köszönhetően egy osztály pl. bővíthető saját attribútumokkal, metódusokkal, de
lehetőség van minden meglévő metódus elé illetve mögé kódrészletet készíteni, ami
lefut a metódus meghívása előtt illetve után. Hasonlóan lehetőség van teljes
kódcserére meglévő metódus esetén.
4.3 Fejlesztési eszközök

Az SAP NetWaver (az SAP Integrációs és Alkalmazási platformja) számos
programozási modellt és eszközt kínál az SAP sztenderd alkalmazások
kiterjesztésére és bővítésére, vagy akár teljesen új ügyfeles alkalmazások
létrehozására. Támogatja a teljes fejlesztési életciklus Java és ABAP programozási
körny-ezetekben egyaránt. Az SAP NetWeaver Composition Environment speciális
támogatást nyújt composit alkalmazások készítésére és terítésére a környezetben.
4.3.1 Az ABAP fejlesztési eszközök legfontosabb jellemzői

Az SAP az ABAP (Advanced Business Application Programming) programozási
nyelvet az alkalmazások fejlesztéshez szükséges optimális munkakörülmények
biztosítása érdekében fejlesztette ki. Kezdetben, mint egy feldolgozó riport készítő
processzor szerepelt, később teljesen az üzleti levárásokat támogató környezet és
technológia épült köréje.
Az ABAP támogatja a strukturált programozást, valamint kontrollstruktúrákat és
modularizálási koncepciókat is tartalmaz. Prototyping-gal támogatott

66
programfejlesztést tesz lehetővé. A fejlesztőnek először a program és a felhasználói

felület előzetes verzióját kell elkészítenie, majd ezt ki kell egészítenie a hiányzó
funkcionalitásokkal. Emellett más fejlesztési technikákat is támogat, pl. az előre
navigálássál a hivatkozott, de még nem létező objektumok hozhatók létre.
Az ABAP értelmező (interpreteres) nyelv, vagyis nem készít külön futatható
állományokat a programokhoz. Ugyanakkor mivel minden kód a memóriában
futtatható csak, ezért a gyorsaság kedvéért egy köztes, ún. load (vagy generált)
formátumot készít és ezt is eltárolja a rendszer. A programok indításakor levizsgálja,
hogy létezik-e már load formátum és megfelelő-e az időbélyege. Ha még nincs, vagy
a forráskód újabb, akkor újra fordítja a programot és betárolja azt is a rendszerbe.
Ezután betölti a program pufferbe, mert onnan futtatja a rendszer.
• A fejlesztés során létre lehet hozni ún. verziókat, melyekre vissza tud térni a
programozó, sőt össze is tudja a verziókat hasonlítani. A fejlesztési
objektumok továbbításánál automatikusan generálódnak verziók. További
főbb jellemzők sorolhatók fel:
• Többnyelvűség (szövegelemek, mint pl. lista fejlécek, beviteli mező szövegei,
stb. külön kerülnek tárolásra). A szövegelemek módosíthatók, más nyelvre
lefordíthatók és karbantarthatók anélkül, hogy a programkódot módosítani
kellene.
• Hatékony hozzáférés az adatstruktúrákhoz (táblák, adatelemek, domének,
stb.) az aktív ABAP Dictionary-ben (memória puffer) tárolt meta-adatok
segítségével
• Az ABAP támogatja az üzemgazdasági adattípusokat és műveleteket is. A
számítási műveletek speciális dátum- és időmezőkkel hajthatók végre. A
rendszer az összes szükséges típuskonvertálást elvégzi.
• Egyszerű, hatékony felhasználói felület (Dynpró) készítést biztosít (Screen
Painter és Menu Painter segítségével)
• Csoportmunka lehetősége
• Objektum dokumentálási lehetőség Repository objektum, adatelem és
transzport szintjén
• Verziókezelés, mely minden ABAP Workbench objektumra kiterjed a
következőket nyújtja: a fejlesztő folyamatosan követheti a munkáját (mi,
hogyan változott), visszatölthet egy előző változatot, a rendszergazda
67
monitorozhatja a munkát (mely objektumok hogyan változtak egy adott

időintervallumban), auditoroknak lehetőséget biztosít a változások
történetének megtekintésére, lehetővé teszi az ügyfeleknek, hogy rendszer
verzióváltása után egyeztessék a régi, módosított és újonnan érkezett
adatokat.
Platform független, az OPEN-SQL és adatbázis interfész (DBIF) segítségével
lehetőséget nyújt az adatbázistáblák elérésére, módosítása - mindenkori adatbázis-
rendszertől függetlenül.
• Eseményorientált
• Objektumorientált programozást tesz lehetővé (ABAP Objects).
A platform függetlenségről az SAP kernel gondoskodik oly módon, hogy az
alkalmazási logikát leíró ABAP nyelvi kódok interpreter jelleggel történő futtatását
valósítja meg úgy, hogy az alatta levő adatbázis natív nyelvére fordítja le az ABAP
Open-SQL hívásokat. Ezek optimalizáltan történnek a rendszerben és figyel az alatta
levő adatbázis-kezelő sajátosságaira, optimalizálójának kihasználására. Az
adatbázisban tárolt táblák közötti összefüggéseket nem az adatbázis, hanem az SAP
szintjén, az adatszótárban (ABAP Dictionary) képzi le, így az alkalmazások
egyszerűen és legtöbb esetben kódolás nélkül alkalmazni tudják a kapcsolatokból
eredő megszorításokat (pl. idegen kulcs). Ezt a funkciót végzi el az adatbázis
interfész. Mindemellett az ABAP szintjén definiálható (különböző típusú) pufferelés
táblákon, ami tovább növeli a teljesítményt.
Az ABAP/4 fejlesztési környezete a speciális fejlesztéseket többek között a
következő kényelmes és teljesítmény orientált eszközökkel támogatja:
• Adatszótár (ABAP Dictionary): a rendszerben tárolt adatok integrált kezelője.
Segítségével központilag karbantarthatók az alap objektumok, vagyis a táblák,
nézetek, struktúrák, valamint a mezők definíciói és az összetettebb
kapcsolódó objektumok, mint például segítségek, zárolási objektumok, típus
csoportok.
• Képernyőtervező (Screen Painter): a dialógus ablakok, tranzakciós képernyők,
(Dynprók, Dinamikus Programok) tervezésére, és tesztelésére. Ablakok,
gördítő sávok, szelekciós listák kényelmes felhasználása a tervezés során. Itt
definiálható a képernyők lefutási logikája is, ami a dynpro megjelenése előtti
és a bevitel utáni tevékenységeket fogja egybe.
68
• Menütervező (Menü Painter): a menük tervezésére. Az SAP képernyőin levő

sztenderd és a felhasználó által adatbázis módosító modulok kódolására,
valamint külső vagy egy másik SAP rendszerből történő meghívásra. Ez
utóbbi az úgynevezett RFC (Remote Function Call) megoldás, ami az RPC
SAP megfelelője.
• Class Builder: Az objektum orientált programozás alapegységének, az
osztálynak globális karbantartó felülete. Segítségével definiálhatók osztályok,
interfészek, azoknak attribútumai, metódusai, eseményei valamint öröklődés
is. Az itt definiált globális osztályok minden program számára elérhetőek.
Mindamellett lehetőség van lokális, csak egy adott programban funkcionáló
objektumok, osztályok definiálására is. (Ez utóbbi csak ABAP kódokban
szerepel.)
• ABAP-Query eszköz: azon felhasználóknak nyújt támogatást, akik nem
rendelkeznek programozási ismeretekkel, és egyedi beszámolókra van
szükségük. A felhasználó interaktív módon állíthatja össze az igényelt listát,
amely alapján a rendszer automatikusan ABAP programkódot generál.
• Adatmodellező (Data Modeler): ABAP nyelven fejlesztett eszköz, ami az SAP
SERM (Structured Entity Relationship Model) definícióinak megfelelő modellt
képes előállítani. Mindazonáltal lehetőséget biztosít a modellezett adatok
ABAP Dictionary objektumokra történő leképezésére.
• Object Navigator: Az ABAP Workbench központi eszköze, ahol az integrált
fejlesztő-környezetbeni fejlesztések kezelhetők fejlesztési objektumtípusok,
felhasználók, fejlesztési osztályok, stb. szerint. Bármelyik felsorolt objektum
szerkesztésére egér segítségével lehet navigálni, ill. újabb objektumok
létrehozása, szerkesztése is lehetséges. A fenti pontokban felsorol eszközök
ill. azok által kezelt objektumokon kívül a Web-es fejlesztéseket támogatandó
ún. Web Application Builder is helyet kap. Ez szolgál az ITS (Internet
Transaction Server) által támogatott IAC-k, valamint a BSP-k (Business
Server Pages, lásd „B4” melléklet) fejlesztésére. Az Object Navigátorban
található az előbb leírt Repository Browser mellett a Mime Repository (mime
objektumok kezelésére), a Tag Library (az SAP rendszerben használható tag-
ek könyvtárai), valamint a Transport Organizer. A Tag Library lehetőséget
biztosít a Tag-ek opcióinak megjelenítésére, dokumentációkra, valamint
69
programokba történő beemelésére. Itt találhatók a HTML különböző verziói

mellett WML, XHTML, és XSLT tag-ek, valamint a BSP programozás
könnyítésére szolgáló BSP tag-ek.
• Business Object Repository (BOR): SAP objektumorientált technológiát
alkalmaz az SAP folyamatok és adatok kezelésére az SAP Business
Objektumok használatával. Külső alkalmazások hozzáférhetnek az SAP
Business Objektumokhoz sztenderd, platformfüggetlen interfészeken –
Business Application Programming Interface (BAPI) – keresztül. Az SAP
Business Objektumok és az azokhoz tartozó BAPI-k egy nyílt,
objektumorientált felületet biztosítanak az SAP rendszer üzleti folyamatainak
és adatainak eléréséhez. Minden SAP Business Objektum típus, SAP
interfész típus és ezek metódusai a Business Object Repository-ban (BOR)
kerülnek definiálásra. Az SAP Business Objektumokat a külső kapcsolatok
mellett főként az SAP Business Workflow használja.
• XSLT editor: A Workbench-be integrált eszköz, mely lehetővé teszi
alkalmazásszerveren végrehajtható XSL transzformációk definiálását. XML
dokumentumok így más XML vagy HTML dokumentumokba, ill. ABAP adat
struktúrákba alakíthatók át, ill. vissza. XSLT programokat, mint repository
objektumokat használ a rendszer a transzformációs szabályok definiálására. A
WebService-k alkalmazásánál igen fontos eszközként használható.
• Nagy külső adatmennyiségek automatikus feldolgozása (Batch Input és Direct
Input technika).
• Idegen rendszerek elérésére szabványos kommunikációs csatlakozási
felületeken keresztül (CPI-C, EDI, ALE).
• OLE 2.0 kapcsolat. Az SAP lehetőséget biztosít arra, hogy az SAP OLE
szerverként és kliensként is funkcionálhasson. Ebben az SAPGUI program a
partnere.
• Egyszerű adatbázis analizáló, karbantartó és adatmodellező funkciók.
• Interaktív hibakereső (debugger). Az eszköz fel van ruházva töréspont
kezelési, mező, belsőtábla illetve komplex struktúra tartalom kijelzési, valamint
watchpoint lehetőségekkel.
• Teljesítménymérő eszközök: futásidő elemzés és Performance trace. A
futásidőelemzés forráskódok futásidejéről és teljesítményéről ad részletes
70
áttekintést egyetlen utasítástól egészen a tranzakciók szintjéig. A

Performance Trace funkció számos nyomkövető eszközt foglal magába,
melyekkel monitorozható és elemezhető a rendszer adatbázis hozzáférése,
zárolások valamint távoli hívásokat (RFC) végző riportok és tranzakciók.
Lehetővé teszi az adatok tárolását és elemzését különböző összegzéseken,
szűréseken keresztül.
• Számítógép által támogatott ellenőrző és mérőeszközök (CATT), ill. új verziója
az e-CATT (Extended CATT).
• Transport Organizer: Bármilyen méretű, központi vagy osztott környezetben
futó szoftver fejlesztési projektek szervezéséhez biztosít támogatást. A
projekthez tartozó ABAP workbench és customizing beállítások, módosítások
a CTS (Change and Transport System) segítségével transzportálhatók a
rendszerkörnyezetben résztvevő SAP rendszerek között. (Az SAP szoftver
logisztikája mind ABAP, mind Java környezetben központi szerepet tölt be a
fejlesztésekkel kapcsolatban.)
Alábbiakban nagyvonalakban bemutatjuk a fejlesztési irányokat, lehetőségeket és
fontosabb eszközöket.
4.3.1.1 Standard fejlesztési lehetőségek

Az SAP rendszer fejlesztési eszközei között három nagyobb elemet érdemes
kiemelni:
• Adatszótár
• ABAP editor
• Dynpro kezelés
Mindkét elem számos függő objektum kezelésekor előkerül. Az adatszótár hordozza
a tábla és egyéb adatstruktra definíciókat.

71
Ábra 4-10 ABAP két szintű domain koncepció
Az ABAP Editor szolgáltatja a fejlesztői felületet az ABAP riportokhoz, funkciós

elemekhez, eljárásokhoz, objektum-orientált metódusokhoz, WebDynpro elemekhez,
stb.
Ábra 4-11 ABAP Editor használati példák (SAP HU)

72
Az SAP tranzakciói képernyőkön keresztül haladva juttatja el a felhasználót a végső

döntésre, hogy menti-e a bevitt adatokat. Ezalatt a képernyők mögött számos
ellenőrzés vizsgálat lezajlik, hogy a bevitt adatok értelmesek, konzisztensek
legyenek. Az SAP ezen képernyőkre saját eseményorientált megoldást fejlesztett ki,
amint dinamikus programnak, vagy röviden Dynpro-nak (esetleg screen) nevez.
A dynpro-k saját programozási nyelvvel rendelkeznek, melyet a work processzek
részeként futó dynpro processzor értelmez és hajt végre. Az itt leírtak igazából
hivatkozások, hogy mikor melyik mező értékével foglalkozik és annak kezelésére
melyik ABAP modult (itt programozási modulról van szó) hívja meg. Összetett
elemek, mint pl. alképernyő, vagy egy táblázat kezelése esetén speciális utasítások
is bekerülnek, amik kifejezetten csak ezekre szolgálnak. A dynpro alapvetően négy
nagyobb részből áll: attribútumok, képernyő elemek, layout, és lefutási logika. Ezek
közül a layout és képernyő elemek együtt dolgoznak, hiszen a layout-ra képernyő
elemek kerülnek. Az itt definiált képernyő mezők adatainak feldolgozása történik
ABAP modulokban. Ezen modulokat egy ún. modul pool program tartalmazza. Egy
ilyen program nem futtatható, csak kód hordozó, és hozzá vannak kapcsolva az
egyes képernyők. Ennek lényege az, hogy a képernyők így a modulpool globális
adataival tudnak dolgozni, vagyis adatokat tudnak cserélni. Belépési pontot ezen
programokra az ún. tranzakciók szolgáltatnak, mivel ezek egy modul pool,
képernyőszám (dynpro azonosító) párost tartalmaznak. (Így egyértelmű, hogy egy
modulpool-hoz számos dynpro és tranzakció is tartozhat.
A Dynpro-k utolsó nagyobb eleme a lefutási logika. Ez tartalmazza esemény
vezérelten a mezőnkénti, illetve esemény szerinti feladatok meghívási sorrendjét.
Alapvetően két nagy dynpro esetményt kezel (további kettő már magasabb szintű
ABAP programozási tudást igényel), a PBO (Process Before Output) és PAI
(Process After Input) eseményeket. Amint a nevek is mutatják, az egyik még a
képernyő végfelhasználónál történő megjelenítése előtt zajlik le, a másik pedig
miután a végfelhasználó valamilyen funkciós billentyű kombinációt nyomott le. A
PBO eseményben beállítási (customizing), jogosultsági adatokat olvasnak és
inicializálnak bizonyos objektumokat, adatokat. A PAI a vezérlés feldolgozását végzi.
Ebben az eseményben dönthetünk arról, hogy különböző képernyő elem használata
esetén milyen kódrészlet, modul fusson le.

73
A többi fejlesztési objektum ezen eszközök kombinált használata különböző

aspektusból.
4.3.1.2 Web fejlesztési lehetőségek

Mivel a rendszer alapját egy WebAS (lásd később) képzi, lehetőséget biztosít
hatékonyabb fejlesztésekre, mely lehetővé teszi a Web alkalmazások
implementálását is. A környezet a stabil SAP alkalmazásszerver technológiára,
valamint Internet alapú infrastruktúrára épül. A standard bázis verzió funkcionalitások
mellett tartalmazza a HTTP, HTTPS, SMTP, WebDav, HTML, XML, SOAP és szerver
oldali scriptelési Internet szabványokat is.
A Web alkalmazások fejlesztésének könnyebbé tételének érdekében a WebAS egy
page alapú programozási modellt alkalmaz, szerver oldali scripteléssel, a Java
Server Pages (JSP) analógiájára. Az eredmény egy erőteljes, azonban könnyen
elsajátítható programozási modell, ami támogatja a Web alkalmazások fejlesztését a
tervezési és megvalósítási fázisokban is. Az SAP WebAS-ben a megjelenítés el van
különítve az üzleti logikától. Ez teszi lehetővé a front-end technológia
implementálását. A WebAS felkínál a HTTP kliens funkcionalitásokat, DCOM és Java
kapcsolódási lehetőségeket a Java konnektor segítségével.
A régebbi verziókban ismert és használt ITS (Internet Transaction Server)
technológia által nyújtott szolgáltatások mellett megjelentek újabb és fejlettebb
Webfejlesztési eszközök is. Az ITS egyik szolgáltatása a korábban említett SAPGUI
for HTML megjelenítés.
4.3.1.2.1ITS alapú fejlesztés

Az SAP a 90-es évek végén érzékelte az Internet felől jövő igény, hogy képes legyen
Web felületek kiajaánlására is. Az első ilyen funkcionalitás már a 3.1h rendszerben
megjelent. A lényege az volt, hogy a standard SAP és frontend közti kommunikációt
használva az adatokat elkapja és konvertálja HTML alapú felületekké. A megoldás
lelke az Internet Transaction Server (ITS) volt. Technikai felépítését a következő
sematikus ábra mutatja meg.

74
Ábra 4-12 ITS architektúra (help.sap.com)
Az ábra feltünteti a protokolokat is, amin kommunikál az SAP szerver felé, valamint a
kliens felé. Az egyes komponensek közé biztonsági okokból tűzfal is helyezhető. A
Web felületekhez tartozó mime objektumokat a Web server kezeli, és a HTML
template-k is itt kapnak helyet.
Fejlesztési szempontból három megoldás lehetséges Internet Transaction Server

használatával
Ábra 4-13 ITS programozási modell ©SAP
Ahogy látható a SAPGUI for HTML is ide tartozik, ugyanis hasonlóan a többihez
használja a HTML-Business csomagot, valamint a lefutási logika ugyanúgy az SAP

75
zajlik és ott hordozza a rendszer az adott alkalmazás státuszát is, mint az Easy Web
Transaytion (EWT) esetén.
Az Easy Web Transaction lényege, hogy meglevő Dynpro alapú SAP tranzakciók
felületeit át lehet kódolni HTML template-ekre és azokat teljesen át lehet alakítani
tetszés szerinti web oldalakká. Az ITS kezel témákat (theme), valamint nyelvfüggő
megjelenítsét tesz lehetővé. Az SAP ABAP Workbench a 4.6-os verzió óta lehetővé
teszi, hogy a rendszeren belülről az Object Navigator segítségével készítsük el
bármelyik tranzakció felületeihez (dynpro-ihoz) a template-ket. A template-k
módosításával lehetővé válik pl. hogy egy két vállalatos cég esetén ne egy
vállalatkód kérő mező jelenjék meg, hanem két nyomógombként működő kép a két
vállalat logo-jával, stb. Az alábbi SAP screenshot egy példa EWT definíciót mutat a
QISR1 standard tranzakcióra.
Ábra 4-14 ITS példa EWT (transaction QISR1) ©SAP
Az alábbiakban látható egy részlet ugyanezen Internet szolgáltatás HTML template-

jének kódrészlete.

76
Ábra 4-15 ITS példa EWT kódrészlet a HTML template-ből ©SAP
Ha megvizsgálnánk a SAPLQISR3 modulpool 0110-es dynpro-ját, észrevennénk a

hasonlóságot a mezőnevek és egyebek között, ahogy az alább screenshot is
mutatja.

77
Ábra 4-16 Standard Dynpro példa ugyanarra a tranzakcióra ©SAP
Az EWT insdításakor a végfelhasználó lényegében egy standard tranzakciót indít a

háttérben, csak a megjelenítő felület jön az ITS, illetve Web server felöl, azonban a
program az SAP szerver memóriájában van ugyanúgy, mint a standard tranzakció
esetén. Fontos, hogy a Web felületen kiváltott akció (pl. nyomógomb lenyomása),
mint HTML akció a Web szerverre érkezik, ahol a megfelelő CGI, vagyis a W-Gate
meghívódik. Ez feldolgozza az akciót és szükség esetén, mint GUI akció továbbítja
az A-gate-nek, aki tovább adja megfelelő adatokkal és protokollal az SAP
szervernek. Lényegében ezzel be is érkezett a végfelhasználói kérelem a dispatcher-
hez.
A FlowLogic ezzel szemben nem a szerveren tartja az alkalmazás státuszát, hanem
az ITS szerveren (A-gate). Ennek oka, hogy a szervert tényleg csak, mint szolgálttó
használja méghozzá, mint RFC-szerver. Az SAP rendszerben felkínált RFC
funkciókat hívja meg amennyiben a folyamat leírásában ez a feladata. A folyamat
leírását egy ún. flow fájlt tartalmazza, ami az Internet Transaction Server-en kap
helyet. Az alábbi ábra mutatja a feldolgozás lényegét.

78
Ábra 4-17 ITS FlowLogic sematikus ábra (help.sap.com)
A flow fájl vezérli, hogy a Modul Provider Interfész milyen funkciót hívjon meg.
Lényegében egy korai egyszerű BPM (Business Process Management) rendszer,
ami szolgáltatásokat (modulokat) hív fel a logikának megfelelően akár különböző
helyekről. SAP esetén RFC funkciós elemeket, illetve ún. BAPI (Business API)
modulokat hívhat meg. Adatokat ad át, majd az eredmények szerint dönt, hogy a flow
fájl értelmében mi legyen a következő lépés. Eközben természetesen a
végfelhasználó számára Web felületeket jelenít meg HTML template-k alapján. Alább
egy példa flow fájl olvasható (forrás: help.sap.com).
<flow>
<state name="present" >
<module name="employee_get" type= "RFC" stateful="0" >
<exception next_template=“add_record“
name="no_records_found">
</exception>
</module>
</state>
<event name = "search" next_state = "present">
</event>
</flow>

79
Amint a kódból olvasható az employee_get BAPI modult hívja meg RFC technikával,
illetve ha hiba lép fel, akkor megvan adva, hogy mely HTML template-tel folytassa a
munkát.
Az ITS megoldás a 6.20-as bázis verzió óta az SAP ABAP Web AS része, ún.
Integrated ITS-ként üzemel, nem kell hozzá külön környezet, külön hardver.
4.3.1.2.2Web fejlesztés BSP környezetben

Az SAP fejlesztői környezete (SE80, Repository Browser) ki lett egészítve a Web
Application Builder funkcióval BSP (Business Server Pages) fejlesztésekre. HTML
oldalak vagy BSP alkalmazások készíthetők szerver oldali scripteléssel ABAP vagy
JavaScript alkalmazásával.
Egy BSP alkalmazás BSP oldalakból és strukturált logikából áll, ami megvalósítja az
üzleti feladatot. A BSP megoldás közvetlen eléréssel rendelkezik az SAP
komponensek teljes funkcionalitására, mint pl. BAPI hívások, ill. adatbázis
hozzáférés. A modernebb BSP környezetekben ún. BSP-kiterjesztések is
alkalmazhatók (ill. készíthetők), melyek magukba foglalják a design mellett a kívánt
speciális funkciókat, így a fejlesztési idő rövidebbé válik az újra felhasználható
komponensek használatával. Ilyen kiterjesztések pl. a HTMLB ill. XHTMLB üzleti
könyvtárak is. A kiterjesztések mellett Model-View-Controller tervezési template is
használható az alkalmazások fejlesztésére.
Számos Web alapú alkalmazási komponens, mint pl. a SAP Learning Solution
(LSO), CRM, stb. nagy része BSP alapon működik. Az SAP a saját szoftvereivel áttér
a WebDynpro for ABAP felületekre (lásd alább), illetve párhuzamosan támogatja a
legújabb HTML5 alapú SAPUI5 illetve SAP Fiori technikákat is új alkalmazásfelületek
kialakításával. Ugyanakkor a BSP továbbra is megmarad a legszabadabb ABAP
alapú Web fejlesztési környezetnek.
4.3.1.2.3Web fejlesztés WebDynpro for ABAP környezetben

A WebDynpro az SAP standard UI (User Interface) technológiája web alkalmazások
fejlesztésére. A technológia kidolgozására a Java környezetben került sor, majd az
újabb ABAP verzióba (7.00-tól) is implementálásra került, melynek neve WebDynpro

80
for ABAP vagy WD4A lett. A WD4A egy futtató környezetből és egy grafikus fejlesztői
környezetből áll, ami a többi ABAP eszköz mellett az ABAP Workbench (SE80)
integráns része.
A WebDynpro a következő előnyüket kínálja az alkalmazásfejlesztőknek:
• A deklaratív (MVC, model-view-controller) és grafikus eszközök szignifikánsan
csökkentik az implementációs ráfordításokat
• A webDynpro struktúrált tervezési folyamatot tesz lehetővé
• A felület és az üzleti adatok teljesen elválaszthatók egymástól
• Komponenseket használva megnő a kezelhetőség és az
újrafelhasználhatóság
• A felület és a navigációk könnyedén változtathatók a WebDynpro eszközökkel
• Támogatja a „stateful” alkalmazásokat
• Automatikus adattranszport érhető el az adatkapcsolások használatával
• Automatikus beviteli vizsgálat
• Automatikus WebDynpro műveletek lehetségesek a billentyűzeten keresztül
• A felhasználói felület támogatja a korlátozott képességüek munkavégzését
• Teljesen integrált a megbízható ABAP fejlesztői környezettel
4.3.1.2.4SAP Business Workflow

A fejezetben is már több helyen felmerült, hogy az SAP rendelkezik Workflow, vagyis
automatizált folyamatirányítással.
SAP az egyik alapítója és ma is aktív tagja az olyan nyílt szervezeteknek, mint a
Workflow Management Coalition (WFMC), vagy Business Process Management
Initiative (BMPI), ezzel nem csak a standardokat támogatva, de azok megvalósítását
ill. a rendszerek közötti működését is szem elé tűzi ki. Ezek a célok vezették az SAP-
t és a Business Process Technology kezdeményezésből kinőtt a SAP Business
Workflow és annak legújabb eleme, a WebAS részét képző WebFlow. A Webflow az
alább tárgyalt lényegi workflow funkcionalitásokat kibővítette a SOAP, XML
üzenetküldés, Web szerviz kezelés és új felhasználói interfész támogatásával.
Az SAP Business Workflow fontos eszköz az üzleti folyamatok felépítésében,
optimalizálásában, továbbá a BPR gyakorlati megvalósításában. A workflow olyan
folyamatok automatizálásával foglalkozik, ahol dokumentumok, információk és
81
feladatok cserélődnek ki a résztvevők között, egy közös cél elérése érdekében. Fő

érdemei közé sorolható az információ és folyamat-áramlás automatizálása és a
szervezeti struktúra rugalmas modellezése. A Business Workflow egyesíti a
folyamatautomatizálást a szervezetigazgatással, a szervezeti struktúrát alapként
használva fel a Workflow-feladatok eljuttatásához és feldolgozásához. Képes a
folyamatokat automatizálni a szervezeti struktúrán és az alkalmazási környezet
határain kívül is. További lényeges jellemző még az is, hogy a feladatok, illetve a
Workflow egyéb funkcionalitásai nem csupán személyekhez, hanem munkakörhöz,
pozícióhoz vagy akár egész szervezeti egységhez is kapcsolhatók.
A feladatát minden – a folyamatban érintett – felhasználó a saját Workflow inbox-
ában találja, ahonnan egy kattintással indíthatja el az adott munkalépést. A
munkalépésekhez határidő figyelés állítható be, azaz meghatározható, hogy egy
bizonyos feladatot mennyi időn belül kell elvégezni, és megadható az is, hogy
ellenkező esetben mi történjen (pl.: levélküldés egy meghatározott személynek,
avagy az el nem végzett feladat továbbküldése valakinek).
Az SAP Business Workflow környezetében a lefutott és éppen futó folyamatokról a
rendszer naplókat készít, ami megfelelő jogosultsággal megtekinthető. Ezek a
naplófájlok tartalmazzák az egyes Workflow lépések (work item-ek) adatait, vagyis
hogy ki volt lehetséges feldolgozó, ki dolgozta fel, az adott lépésen milyen műveletek
zajlottak, stb. Mindezen adatokhoz időbélyeg információk kapcsolhatók, melyekkel
követhető az automatizált folyamat sebessége és a munkatársak feldolgozási
teljesítménye. Vagyis a lefutott illetve éppen futó Workflow-król napra, hétre,
hónapra, illetve akár több évre visszamenőleg elemzéseket készíthetünk. Ezen
elemzésekből megállapítható a futások gyakorisága, a munkalépések
feldolgozásának időtartama, az esetleges hibák, valamint a határidő túllépések.
A Business Workflow a bázisrendszer része. Az üzleti folyamatok (Workflow), melyek
a SAP Business Workflow-val modellezhetők, lehetnek alkalmazásokat átfogó, vagy
egy alkalmazáshoz hozzárendeltek. Ezért speciális beszámoló készítés szükséges
az ügyfél specifikus üzleti folyamatokhoz, amiket az SAP nem minden bevezetési
területhez ajánl fel. A LIS (Logistic Information System) kapcsolaton keresztül
rendelkezésre áll egy széleskörű támogatás az analízisnél.
A Workflow Információs Rendszerrel (WIS) a Workflow futásidő környezete által
adatbázistáblákban eltárolt alap beszámoló adatokat dolgozza fel. A modern
82
adattárház koncepció háromszintes modellt használ az adatok kényelmes

analizálásához (alkalmazás, adattáblák, folyamatelemzés). A WIS lehetőséget
biztosít az elemzések grafikus és Excel tábla formájában történő megjelenítésére is.
Számos standardelemzés mellet ügyfél által definiált elemzésekkel is bővíthető az
információs rendszer. Mindezek mellett független a futásidő környezettől.
A Workflow funkcionalitás kiterjesztése az intranet/Internetre biztosítja, hogy
rendelkezésünkre álljon egy, napi 24 órában üzemelő, bárhonnan a világból elérhető
Workflow rendszer.
4.3.1.2.4.1 SAP Business Workflow főbb jellemzői
• Integrálódás az ERP üzleti alkalmazásokkal

• Fejlesztői környezet, mely tartalmaz egy grafikus folyamatmodellezőt
• Integrálódás a ERP szervezeti struktúra kezelési rendszerével
• Előre definiált folyamatmodellek melyeket felhasználhatunk saját
folyamatainkban
• Workflow „varázslók”, melyekkel gyorsan megoldáshoz juthatunk
• Szöveges és grafikus folyamatnapló, mellyel végigkövethetjük folyamatainkat
• Workflow információs rendszer (WIS) mely folyamataink felülvizsgálatában és
optimalizálásában segít
• Objektum-orientált megközelítés mely az ERP BOR (Business Object
Repository) komponensén alapszik
• Univerzális levelesláda a munkalépéseknek, e-mail, fax, telefonos
üzeneteknek
• Az univerzális levelesláda elérhető a SAPGUI-ból, a Java SAPGUI-ból, MS
Outlook-ból, Lotus Notes-ból vagy Web felületekről.
4.3.1.2.4.2 Workflow Fejlesztési környezet

A SAP Business Workflow a workflow definíciót használja az üzleti folyamat technikai
szempontból történő definiálására. A workflow definíció szabályozza az aktív
vezérlést és adatfolyamot a folyamat lépései között. Minden ilyen lépéshez
automatikusan rendelkezésre állnak a feldolgozáshoz szükséges adatok és

83
dokumentációk. Amikor egy lépést feldolgoznak, egy esemény keletkezik, ami

további feldolgozási lépéseket vált ki. Ugyanekkor eredmények is keletkezhetnek,
amiket más workflow-kban lehet használni. Ilyen eseményekre példa lehet egy
vevőtől jött üzenet, kapcsolt rendszerek jelzései, állapotváltozások, vagy túllépett
határidők. A szóban forgó lépések vagy automatikusan feldolgozásra kerülnek, vagy
a felelős levelesládájába (inbox) kerül. A rendszer monitorozza a lépések pontos
befejeződését.
A Workflow definíciók verziói bármikor teljes körben változtathatók a grafikus
editorban. Lépéseket lehet beszúrni, áthelyezni vagy törölni az alkalmazásba történő
beavatkozás nélkül. A verziók lehetővé teszik, hogy a futó üzleti folyamatok sérülése
nélkül lehessen változtatásokat végrehajtani. Automatizált folyamatok
felülvizsgálatakor, verziók segítségével határozható meg, hogy milyen szabályokat
és folyamatlogikát használtak, amikor a folyamatban a döntés megtörtént. Ez egy
kritikus tényező automatizált folyamatoknál auditálás esetén.
A Workflow Management és a lépésekben használt alkalmazási funkcionalitások
közti interfész objektumorientált elveken alapul. Az SAP Business Objektumok
alkalmazási funkcionalitásokat és adatokat ágyaznak be, úgymint számlák,
beszerzési megrendelés vagy akár egy PC-s dokumentum. Például a megjelenítési
és feldolgozási folyamat, az objektum állapot információi és más előre definiált
ellenőrző tevékenységek összeköthetőek a megfelelő objektum adataival. Az adatok
és funkcionalitások ilyen mérvű koncentrációja egyszerűsíti a kommunikációt az
objektumok között és segíti azok flexibilis egyeztetését és bármikori változtatását. Az
SAP Business Objektumai központilag vannak karbantartva a Business Object
Repository-ban.

84
Ábra 4-18 SAP Business Workflow - Fejlesztői eszköz ©SAP
Előre definiált workflow modulok használatával felgyorsítható a bevezetési folyamat.

Workflow-k definiálásához az SAP gondoskodik egy mintákat tartalmazó könyvtárról,
ahol működő alkalmazási folyamatok találhatók. Ezek alkalmazhatók, mint Workflow
feladat, vagy akár egy ügyfél specifikus folyamatok kiindulópontjaként is. A grafikus
Workflow szerkesztő lehetőséget biztosít Workflow definíciók egyszerű létrehozására
és módosítására programozás nélkül. Nem szükséges az alkalmazást módosítani,
sem a működő üzleti folyamatot megszakítani.
A Workflow minták egyedi lépései kiszállított standard feladatokra hivatkoznak,
melyek az üzleti funkcionalitásokat hordozzák magukban. Ezek könnyedén
kombinálhatók cég specifikus Workflo w definíciókkal. Az SAP gondoskodik Business
Objektumokról a Business Object Repository-ban, melyek szabadon használhatóak
saját Workflow feladat definiálásához. Az ABAP Workbench professzionális fejlesztő
környezetként áll rendelkezésre az ügyfél specifikus Business Objektumok és
metódusok implementálásához.
Amint a fejezetben leírtakból olvasható volt, az SAP biztosítja mind a három kérdésre
a megfelelést, hiszen:
85
• az SAP saját fejlesztő környezetében (ABAP Workbench) készítette a saját

kódjait, amik megtekinthető forráskóddal rendelkeznek, valamint akár
módosíthatók, bővíthetők is,
• Paraméterezhető, customizálható és a standard kódok eszerint élnek,
• Bárki, bármikor továbbfejlesztheti, ha megvan a megfelelő szakismerete, nem
szükséges a szoftver szállítóját vagy a bevezető vállalkozót hívni.
4.3.2 Tesztelési, optimalizálási standard mechanizmusok

A rendszerben jogi és technikai korlát nélkül lehetőség van a fejlesztésre,
továbbfejlesztésre, módosításra és bővítésre. Az ügyfél szabja meg, hogy kivel
akarja megcsináltatni a fejlesztéseket, beállításokat, nem kötött, hogy ki végzi ezeket
el, csak a szaktudás igénye mellett javasolt dönteni. Mint feljebb említésre került,
amennyiben egy projektben résztvevő munkatársk az oktatásokon és a tevékeny
projekt részvétellel elsajátítják a fejlesztési tudást, a modul szakértelmet, a
paraméterezési lehetőségeket, eszközöket, hatásmechanizmusokat, akkor akár
külső tanácsadás nélkül önmaguk is üzemeltethetik a rendszert.
Project vezeté
vezetés - Workflow-
Workflow-model - Documentá
Documentáció
ció - Prototí
Prototípus
Repository
Browser
ABAP Teljesítmény
Dictionary
Debugger vizsgáló
Screen Painter eszközök
SAP Modellezés Teszt
Menu Painter Workbench
megoldá
megoldás menedzsment
Organizer
Function- (eCATT)
builder Verziókezelés
Class Builder
ABAP Editor
…
Elemzé
Elemzés /
tervezé Implementá
Implementáció
ció Tesz
Teszt Adminisztrá
Adminisztráció
ció
tervezés
Amint a fenti ábra (fejlesztési folyamat az SAP-ban) mutatja és feljebb is olvasható

volt, a fejlesztési környezet tartalmazza a kialakítandó SAP megoldás teljes
életciklusához szükséges eszközöket a tervezéstő, a megvalósításon és tesztelési
eszközökön keresztül a teljesítmény ellenőrzésig lényegében mindent. Fentebb nem
került részletezésre a CATT/eCATT ([extended] Computer Aided Test Tool)
megoldás, ami a tesztelést támogatja oly módon, hogy rögzíteni lehet egy folyamatot,
majd a folyamatból Excel táblát készít az eszköz. A táblázat ezután feltölthető a
különböző tesztesetekkel. A végrehajtás előtt beállítható, hogy a tesztelés pozitív

86
vagy negatív kimenetet kíván meg, vagyis az a jó, ha sikerül, vagy az, ha éppen
nem. Eszerint ki is értékeli a tesztelési eredményeket. További lehetőség található a
SAP Solution Manager rendszerben is a tesztesetek feltöltésére és későbbi hívására,
menedzselésére. A kidolgozott tesztesetek később is használhatók, pl. ha egy
javítócsomag betöltésre kerül és egy adott funkciót tesztelni kívánunk.
A teljesítményteszteléseket a Workload analízis eszközökkel, a futásidő elemzéssel,
valamint az SQL-trace eszközzel lehet végezni alapvetően. Az ABAP futásidő
elemzési eszköz (SE30) lehetővé teszi bármely ABAP program, mint pl. riportok,
eljárások, funkciós modulok, vagy osztályok teljesítményértékelését. Elmenti az
eredményeket a adat fájlokban, melyek közül ki lehet választani, hogy melyiket
szeretnénk kiértékelni. Az elemzések során felderíthetőek a futásidő intenzív
utasítások, kódrészletek beleértve a tábla hozzáféréseket is. Hierarchikusan
megjeleníti a programhívásokat, melyekben láthatók a ráfordítási idők nettó ill. bruttó
értékben, valamint százalékosan is látható, hogy az egész kódból, vagy egy
eljáráson belül mennyit tettek ki az adott utasítások, hívások. Az elemzés során
felderíthetőek többek között a túlzott, vagy szükségtelen modularizáció használatok,
a CPU intenzív program elemek, felhasználó-specifikus funkciók, amik
helyettesíthetők ABAP utasításokkal, nem effektív vagy redundáns adatbázishívások.
Az SQL trace lehetővé teszi az adatbázis hozzáférések feljegyzését, zárolási
tevékenységek követését, távoli függvény (RFC), riport, vagy tranzakcióhívások
elemzését, adatbázis pufferek használatának vizsgálatát. A feljegyzéseket egy
nyomkövetési fájlba helyezi el a rendszer, ahonnan az elemzővel különböző
szűrések, aggregálások segítségével kimutathatók akár a drága SQL hívások is.
4.4 Szoftverlogisztika
A szoftverlogisztika feladata a szoftver változásainak (konfiguráció, fejlesztés,
módosítás, stb.) csomagokba gyűjtése és fogadó rendszerek felé továbbítása, illetve
azokba történő implementálása. A szoftverlogisztika ugyanakkor a projekteken a
fejlesztők, konfiguráló munkatársak és a technikai csoport közti formális
kommunikációs folyamatok definiálása a módosítások és fejlesztések
transzportálására vonatkozóan.

87
A szoftverlogisztika eszköze az ABAP alapú SAP rendszerekben (ún. ABAP stack) a

Change and Transport System (CTS). A Korrektúra és Transzportrendszer
segítségével a fejlesztési projektek Workbench és Customizing módosításai
rendszerezhetővé, kezelhetővé és követhetővé válnak.
A bevezetésnek megfelelő részletes technikai infrastuktúra kialakításához szükséges
az SAP konfiguráció, tesztelési és változáskezelési koncepciók és eljárások
megismerése. Ezeket az ismereteket feltételezzük.
4.4.1 Általános jellemzők

Az egész ABAP Workbench környezetet áthatja a szoftverlogisztika kifinomult
szelleme. A szoftverlogisztika összefoglaló neve azon eszközöknek, metodológiának
és mechanizmusnak, melynek segítségével a szoftvermódosításokat
(paraméterezés, fejlesztés, bővítés, standardmódosítás) egybe lehet gyűjteni,
fejlesztő, beállító csoporthoz lehet rendelni, valamint a módosítási verziókat kezelve
át lehet vinni másik rendszerbe. Így a módosítások egységesen kezelve kerülnek át
a fejlesztői környezetből a minőségbiztosításon át az éles üzembe.
Alapvetően elkülönítjük a beállításokat, paraméterezéseket (ugyanis ezek tábla
tartalmakat jelentenek) a fejlesztési objektumoktól. Az elsőket ún. customizing
kérelem kezeli, az utóbbiakat pedig az ún. workbench kérelem. Ezek az ún.
módosítási kérelmek az alapjai a csoportmunkának, a verzionálásnak, valamint az
objektumok átvitelének (transzportálásnak) is. A csoportmunka úgy valósul meg,
hogy a módosításért felelős felhasználó létrehozza a módosítási kérelmet, mely alatt
kiosztja a feladatokat az egyes fejlesztőknek beállítóknak. Ezután az egyes fejlesztő,
beállító a kérelmen belül a saját feladatába (task) gyűjti (automatikusan) a
módosításait. Fejlesztési objektumok esetében egy logikai zárolás is kerül az
objektumokra, miszerint más módosítási kérelem nem nyúlhat hozzá, amíg a
hozzárendelt fogja.
A fejlesztési objektumok esetén minden objektumnak van egy eredetisége, vagyis,
hogy melyik rendszerben keletkezett, hol tudják közvetlenül korrigálni az esetleges
hibáikat. Ez a standard SAP részét képező kiszállított objektumok esetében egy fiktív
SAP nevű rendszer. A saját fejlesztett objektumaink eredetisége a fejlesztői rendszer
(pl. DEV). Amikor saját objektumot hozunk létre, vagy javítunk (korrigálunk), akkor

88
ún. fejlesztési/korrektúra típusú feladathoz (task) rendeli a rendszer a fent nevezett

módosítási kérelmen belül. Ha nem a mi rendszerünkben eredeti, vagyis SAP-s vagy
egy másik cég által fejlesztett és hozzánk importált objektumot módosítunk, akkor ún.
reparatúra típusú feladatba helyezi el a módosított objektum referenciát a rendszer.
Így mindig követhető, hogy egy módosítás során milyen objektumok és hogyan
módosultak, valamint az is, hogy ki módosította. Amikor a módosítás unit tesztje
lezajlott és a fejlesztők, beállítók lezárják a feladataikat, a módosítási kérelem
tulajdonosa, felelőse (pl. projektvezető) is engedélyezi a módosítási kérelmet. Ez
több lépést foglal magában. Egyrészt a kérelemben hivatkozott objektumok logikai
zárolását feloldja, az objektumokról verziót generál, amit megőriz, valamint az
objektumok aktuális állapotát kiexportálja egy fájlrendszerbeli könyvtárba, mint
transzportot. Ez az a transzport, ami már adatbázis és operációs-rendszer független
formában tartalmazza a fejlesztéseket, beállításokat és vihető bármely rendszerbe.
Vagyis a transzportok azok a hordozó egységek, amikkel az SAP is, valamint
bármely más fejlesztő csapat objektumokat, beállítások vihet ügyfeleknek,
partnereknek. (Maguk a javító csomagok, sőt a verzióváltás során kiszállított
objektumok is így kerülnek a rendszerekbe.) A rendszerben keletkező transzportokat
nem kell operációs rendszer szintjén adminisztrátoroknak kezelni, ugyanis a TMS
(Transport Management System) környezet definiálja az ún. transzport útvonalat,
hogy milyen sorrendben áll fel az SAP rendszerek környezete (fejlesztő,
minőségbiztosító ill. produktív), valamint eszközöket biztosít a transzportok
betöltésére, naplók vizsgálatára, stb. A transzportok betöltése a minőségbiztosító
rendszer kezelhető automatikusan, vagy manuális, azonban a produktív rendszerbe
történő betöltés előtt mindenképpen javasolt az ún. QA-Workflow definiálása. Ez a
workflow lehetőséget biztosít arra, hogy egy a minőségbiztosító rendszer betöltött
transzportról állást foglaljon egy megfelelő illetékes, hogy mehet-e a produktív
rendszerbe. Amíg nem hagyják jóvá, nem lehet importálni.

89
Ábra 4-19 Fejlesztési objektum (itt program) verziói ©SAP
Nem esett szó még a verziókezelésről részletesen. Amint említettük a módosítási

kérelmek engedélyezése során automatikus verziógenerálás jön létre. Lehetőség
van arra is, hogy a rendszer import során generáljon verziót, ezzel a célrendszerben
is megmarad a verzió adatbázis. Fontos megjegyezni, hogy javító csomag (support
package), vagy upgrade esetén is figyel a rendszer arra, hogy vannak-e módosított
standard objektumok, amiket az SAP a javítás során kiszállít és azokról készít külön
verzió adatbázist. Amint az alábbi két ábra mutatja, pl. egy kód verziói
megtekinthetők, ill. összehasonlíthatók, valamint visszahívható egy korábbi verzió is.
Az összehasonlítás nem csak a rendszerben történhet meg, hanem rendszerek
között is, ezzel lehetővé téve az esetleges hibák felderítését.

90
Ábra 4-20 SAP ABAP verziókezelés (összehasonlítás) ©SAP
A felső ábra mutatja, hogy ki, mikor módosított, ugyanakkor az is látható, hogy
milyen fajta verzióról beszélünk. Az üresek az exportálás (módosítási kérelem
engedélyezés) során keletkezett verziók, az ’I’ betűvel jelzettek másik rendszerből
importált verziók. Az ’S’ ill. ’U’ betű pedig olyan köztes verziót jelent, amit a fejlesztő
magának generálhat fejlesztés közben, amikor szeretne megőrizni egy köztes
állapotot. A szélesebb ábra a fent szereplő aktív és a 00007-es verzió
összehasonlítását mutatja. Mint látható akár párhuzamos megjelenítéssel is
megvizsgálhatóak a különbségek, valamint lehetőség van mindig a következő
különbségre ugrani, stb. Ha egy régebbi verziót visszahívunk, a rendszer generál egy
új módosítási kérelmet, amiben elhelyezi, hogy most már ez lesz az új verzió.
4.4.2 Mandantok
Az SAP mandantok elválasztó szerepet töltenek be egy SAP környezetben.
Alapvetően fontos, hogy meghatározzuk egyes mandantjaink szerepét és helyét. A
mandantok üzletileg, szervezetileg, jogosultságilag önálló egységet képeznek,
azonban figyelembe kell vennünk azt a tényt, hogy az egy rendszerben létrehozott
mandant-ok ugyanazt a repository-t (vagyis fejleszési objektum készletet) használják.
Az alábbiakban a mandantok használatáról, kezeléséről, szerepéről lesz szó.

91
4.4.2.1 Definíció és mandantkiosztás

A szoftverlogisztika különböző, esetleg más rendszerben elhelyezkedő mandantok
között dolgozik. Feladata az SAP szoftver változásainak összegyűjtése és
mozgatása rendszerek, mandantok között. A rendszerkörnyezet definiálja a
konszolidációs utat, mely a szoftverváltozások mozgatásának útvonalát jelöli ki.
Az SAP-rendszer mandantokon alapuló rendszer. Egy mandant önálló egységet
képez gazdasági, szervezeti és technikai szempontból is, a saját felhasználói
törzsadataival együtt. A különböző mandantokhoz tartozó adatokat szeparáltan
kezeli a rendszer az SAP kernel szintjén.
Az alábbi táblázat a legfontosabb mandantokat és azok rendszerkörnyezetben
betöltött szerepét sorolja fel.
Mandant Szerep
CUST Customizing és fejlesztő mandant.
Minden mandantfüggő és mandantfüggetlen customizing
ebben a mandantban történik. Az összes repository
módosítás (riportok, tranzakciók, táblák, stb. karbantartása) is
itt zajlik. Beállításokon kívüli alkalmazási (mozgási és törzs)
adatok nincsenek a mandantban.
QAST Minőségbiztosító tesz mandant (Quality Assurance and Test
client).
Az új beállítások és fejlesztési objektumok ebben a
környezetben lesznek tesztelve eredeti, tömeges adatokkal. A
változáskezelők (Change Manager) koordinálják a tesztelési
folyamatokat, az előre kialakított tesztesetek szerint. Ők
fogadják vagy utasítják el az új beállítások vagy fejlesztési
objektumok produktív környezetben történő használatát.
PROD Produktív mandant
Táblázat 4-1 Alap mandant típusok
A konfigurációs és repository változásokat a konszolidációs útnak megfelelően kell

mozgatni. A változásokat ún. változási kérelmekben (Change Request) tárolja a
rendszer. Egy transzport a változási kérelem által felsorolt referenciák szerinti
adatoknak az engedélyezés pillanatában meglevő értékét tartalmazza. A keletkezett
92
transzportokat a megfelelő mandantba, rendszerbe kell importálni. Az azonos, vagy

akár különböző rendszerekben levő mandantok közötti konfigurációk és/vagy
fejlesztések mozgatásának eszköze a CTS (Correction and Transport System).
A táblázatban szereplő mandantok részletes leírása és használata:
• Fejlesztői, konfigurációs mandant (CUST):
Az SAP bevezetési projektek lényeges része az ügyféligényeknek megfelelő
rendszerkörnyezet kialakítása. A bevezetés során a kiszállított SAP R/3-as
környezetet kell az ügyfél előre definiált követelményeihez illeszteni. Ez azt
jelenti, hogy az SAP R/3 nagyfokú paraméterezési lehetőségét kihasználva a
rendszert az igényeknek megfelelően átállítják be. Emellett természetesen
lehet találkozni olyan megoldandó feladatokkal is, amiket nem lehet
paraméterezéssel megoldani. Az ilyen feladatokat fejlesztéssel kell kiváltani. A
fejlesztéseket és a paraméterezéseket mindig a fejlesztői mandantban kell
elvégezni, majd a módosításokat szabványos SAP R/3-as eszközökkel
áttranszportálni a további (teszt, produktív…) környezetekbe.
• Minőségbiztosítási Teszt mandant (QAST):
Feladata, hogy a fejlesztői, beállítói transzportok ill. a tartalmuk tesztelhető
legyen ténylegesen produktív környezetben úgy, hogy ez a produktív üzemet
ne veszélyeztesse. Ezért a produktív mandant időszakos másolatával
készülhet el. A minőségbiztosító mandantban tárolt adatokat rendszeresen
frissíteni kell, hogy a tesztek végén nehogy hamis következtetéseket vonjanak
le.
• Produktív mandant (PROD):
Az ügyfél ebbe a mandantba viszi fel kézzel, vagy tölti be kötegelve a napi
munkája során keletkező adatokat. Ez a mandant a legjobban védett és a
legerősebb hardverkörnyezetet igényli, mivel a legtöbb felhasználót szolgálja
ki. Az ügyfél érdekében a produktív rendszer működőképességét minden
változás ellenére meg kell őrizni.
A három szükséges mandant elhelyezése történhet azonos és különböző

adatbázisokba is. Mindazonáltal a különböző adatbázisok is kerülhetnek azonos,
vagy különálló hardverre. Ennek megfelelően a következő lehetőségek állnak
rendelkezésre, amint az alábbi leírás és ábra is mutatja.
93
Ábra 4-21 Standard mandantokra példa
Háromgépes rendszerkörnyezet (3-tier system landscape):

A fejlesztői (CUST), minőségbiztosító (QAST) és produktív (PROD) mandantok egy-
egy különálló R/3 rendszerben kapnak helyet.
Nem csak háromrendszeres környezet ismert, hanem több és kevesebb rendszerből
is állhat. (Az alábbiakban szereplő szövegben gép, illetve rendszer tekinthető
azonosnak, azonban a rendszer a mérvadó. Virtuális környezetben nemhogy egy
rendszer, de egy rendszernek egy szolgáltatása is akár külön gépre, virtuális gépre
kerülhet.)

94
Ábra 4-22 Transzportálási lépések - 3 rendszeres környezet (help.sap.com)
Kétgépes rendszerkörnyezet (2-tier system landscape):

A fejlesztői és teszt ill. produktív rendszerből álló rendszerkörnyezet, ahol a
fejlesztési és tesztfunkciókat egy SAP R/3 rendszer látja el, és a produktív rendszer
funkcióját önálló SAP R/3-as rendszerként látja el.
Kétgépes rendszerkörnyezetben a produktív rendszer működőképességének
megőrzésére megfelelőek az esélyek. A tesztelési és fejlesztési munkákat és azok
ütemezését azonban igen részletesen egyeztetni kell.
Egygépes rendszerkörnyezet (single system landscape):
Elméletileg az a lehetőség is elképzelhető, hogy az ügyfélnél csak egyetlen SAP
ERP installáció van. Minden funkciót (fejlesztés, teszt, produktív üzem) egy SAP
ERP rendszer lát el. Ezt a megvalósítást az SAP AG nem támogatja, mivel a
fejlesztés során létrejövő félkész, vagy kiteszteletlen rendszermódosítások (pl.
programok, táblastruktúrák, stb.) azonnali hatással megjelennek a produktív
környezetben is, hiszen a fejlesztési (workbench) objektumok mandantfüggetlenek,
így ugyanaz érhető el minden mandantban az adott rendszeren belül. Ez
semmiképpen nem megengedhető. Ezért az egygépes konfigurációt kerülni kell.
Az SAP HR környezet kialakításakor a három rendszeres környezet kerül

kialakításra. Mind a három környezetben helyet kap az SAP R/3 Enterprise-ra épülő
HR rendszer, e-learning megoldás (LSO), e-Recruitment környezet, az ezekhez

95
kapcsolódó Enterprise Portal, valamint a dokumentumkezeléshez szükséges IXOS

megoldás. Amint az előző fejezetekben is leírásra került kilenc adatbázis környezetet
különböztetünk meg. Ezek közül a transzportrendszer szempontjából az R/3
Enterprise HR rendszer, valamint a e-Recruitment rendszer hármas környezete
érdekes. A következő táblázat egy lehetséges SAP ERP alapú HR (emberi erőforrás)
rendszerkörnyezet rendszereit és mandantjait tartalmazza.
HR Fejlesztő HR Teszt HR Produktív

HRF HRT HRP
SAPR 000 SAPR 000 SAPR 000
SAP Referencia SAP Referencia SAP Referencia
CUST 010 QAST 100 PROD 200
Customizing/Devel. Minőségbizt. teszt Éles
UNIT 020 CONV 120
Unit teszt Migráció
SAND 060 TRNG 160
Homokozó Oktató
Ábra 4-23 Egy lehetséges mandant kiépítés 3-rendszeres (HR) környezetben
A standard mandantok rendszerekbe történő elhelyezése nem csak három

rendszerben történhet, hanem akár további környezetekbe is. Ilyen lehet a több
régióban való jelenlét kezelése, vagy egyáltalán több fejlesztési réteg alkalmazása.

96
Ábra 4-24 Több régiós környezet transzport útvonalai (help.sap.com)
A fenti ábra nem tárgyal több fajta mandant típust, azonban mint látható a transzport
útvonal összetett, ugyanis több fejlesztési réteget is használunk, sőt, több fejlesztői
rendszert. Ennek oka, hogy a fejlesztői rendszerben általáos objektumok
keletkeznek, amik mindhárom régióra megfelelőek, a specifikus objektumok már a
„lokális”, vagyis régió függő környezetben kerülnek kialakításra.
A Ábra 4-23 Egy lehetséges mandant kiépítés 3-rendszeres (HR) környezetben
ábrán szerepel néhány, eddig nem említett mandant típus. Ezek a mandantok
kényelmesebbé teszik egy bevezetési projekt munkáját és csökkentik a mandantok
terhelését.
Mandant Szerepe
SAPR A 000-ás mandantot nem szabad módosítani, semmiféle
konfiguráció nem végezhető. Az SAP, mint referenciát
használja ezt a mandantot, pl. űrlapok és eredeti nyelvi
objektumokat tárol itt.
UNIT Unit teszt mandant. Az új beállításokat átmásolják ebbe a
mandantba, és mint egy önálló egység tesztelik, mielőtt
engedélyeznék, hogy a QAST mandantba menjen. A
fejlesztett riportok, tranzakciók szintén itt tesztelendők. A
törzsadat feltöltő programokat is itt kell kipróbálni. Eredeti
ügyfeles adatokat kell feltölteni és használni ebben a
mandantban.

97
SAND Homokozó mandant. Ez a mandant tartalmazza a legfrissebb

konfigurációs és ügyfeles adatokat. Mindenki kipróbálhat
bármilyen mandantfüggő beállítást, vagy fejlesztett
objektumot. A mandantot érdemes rendszeresen frissíteni.
(Ebben a mandantban lehet kipróbálni a beállítást, mielőtt a
CUST mandantban véglegessé válna.)
CONV Konverziós teszt mandant. Az integrációs (minőségbiztosító)
mandant mellett ajánlott egy külön mandant, a kiváltandó
rendszerekből adatokat feltöltő programok tesztjére. Ez a
mandant gyakran sérülhet. Az adatait törölni archiválással
vagy mandant másolással lehet.
TRNG Végfelhasználó oktatási mandant. Ez a mandant a QAST
mandant másolata, mely a legfrissebb, tesztelt beállításokat
és repository objektumokat is tartalmazza. A kulcs
felhasználók oktatják a végfelhasználókat a beállított és/vagy
kialakított eszközök használatára.
PPRD Előzetes produktív mandant (Pre Production). Az R/3
konfiguráció produktív rendszerbeli végső tesztelésére. Ezt a
mandantot lehet használni a nagy mennyiségű adatfeltöltések
tesztelésére is. A valós produktív életet lehet szimulálni a
produktív környezetnek megfelelő módon. Külön rendszerben
történő használatakor nincs szükség a produktív környezet
reorganizálására indulás előtt. Kalkulálni lehet a tényleges
adatbázisméretet és kialakítást a produktív rendszerhez.
MAST Minta mandant (Master). A mandant feladata, hogy a
beállításokat ügyfeles adatokkal együtt érintetlenül tárolja.
Ezzel a mandanttal könnyebb a SEND, UNIT és QAST
mandantok frissítése, helyreállítása.
Használatakor a fejlesztő és minőségbiztosító rendszerben is
ajánlott egy-egy példány.
Táblázat 4-2 Egyéb mandantok és szerepeik
A fent leírt mandantok használata nem feltétlen egyértelmű, projektektől függően

máshogy lehet alkalmazni őket.
98
Ábra 4-25 Több SAP komponens, több környezet, több mandant
Az ábra egy valós projekt „pillanatképet” fest, ugyanis a projekt haladtával a

kapcsolatok a rendszerek/mandantok között változik, valamint bizonyos környezetek
(szűrke csíkok) keletkeznek és megszűnnek. Az ábrán sárga az ABAP, kék pedig a
Java rendszereket jelöli. (A többi csak információként kapcsolódó rendszereket
mutat.) Az elnevezések (SAP hárombetűs SID) eslő két betűje jelöli a különböző
SAP komponenseket (ERP, SRM, BW, NetWeaver Portal). Mint látható, itt számos
mandant megjelenik, főleg az ERP környezetben. Külön szerepet kapnak a TRG+,
valamint CMAS mandantok, hiszen ezek csak beállítás hordozására és megtartására
szolgálnak, mint master (vagy minta).
4.4.2.2 Mandant kialakítása és azok attribútomai

A mandant attribútumok vezérlik a customizing és fejlesztési funkcionalitásokat az
SAP rendszerekben. Ezek a jellemzők nem bírálják felül a rendszer szintű
módosíthatósági beállításokat (System Change Options SE06), hanem inkább finom
hangolásra szolgálnak a mandantok SAP rendszerkörnyezetben betöltött szerepét
tekintve.
Minden mandant esetében néven és kategórián kívül a mandantban végezhető
műveletek is szabályozhatóak. A mandantban történő mandantfüggő beállításokat le
lehet tiltani, vagy engedélyezni, sőt a módosítások kérelembe történő automatikus
99
rögzítésére is van lehetőség. A mandantfüggetlen objektumok, vagyis a repository és

mandantfüggetlen customizing objektumok módosítása külön-külön engedélyezhető
vagy tiltható. Ezeken felül további megszorítások szabhatók a mandant
transzportokkal történő felülírhatóságára.
A következő táblázat a rendszerkörnyezetben alkalmazott mandantok attribútumait
tartalmazza.
SID Mndt Kategória Mandt.más. Mandantfüggő Mandantfüggetlen beállítás

védelem beállítás
HRF CUST Customizi 1 felülírás Módosítások Repos. és
ng nem automatikus ügyfélfüggetlen cust.
lehets. rögzítése módosítása lehetséges
SAND Training/ 0 korl. Módosítás Repos. és
Educatio nélkül automatikus ügyfélfüggetlen cust.
n rögzítés nélkül obj. nem
módosúlhatnak
UNIT Test 0 korl. Módosítás nem Repos. és
nélkül megengedett ügyfélfüggetlen cust.
obj. nem
módosúlhatnak
HRT QAST Test 0 korl. Módosítás nem Repos. és
obj. nem
módosúlhatnak
CONV Test 0 korl. Módosítás nem Repos. és
obj. nem
módosúlhatnak
TRNG Training/ 0 korl. Módosítás nem Repos. és
Educatio nélkül megengedett ügyfélfüggetlen cust.
n obj. nem
módosúlhatnak
HRP PROD Productiv 1 felülírás Módosítás nem Repos. és

100
SID Mndt Kategória Mandt.más. Mandantfüggő Mandantfüggetlen beállítás

védelem beállítás
e nem megengedett ügyfélfüggetlen cust.

lehets. obj. nem
módosúlhatnak
Táblázat 4-3 Mandant attribútumok (példa)
4.4.2.3 Létrehozási/engedélyezési felelősségek

Az SAP korrektúra és transzport rendszere garantálja a csapatmunka, verziókezelés
és módosítászárolási mechanizmus eszközeit és koncepcióit. Amikor egy módosítási
kérelem létrejön, a létrehozó lesz a felelős a kérelemhez rendelt módosításokért.
Ugyanakkor meg kell adnia egy felhasználó listát, akik a kérelemhez tartozó
fejlesztési csapatot alkotják. Mindenegyes csapattag kap egy ún. feladatot, amiben
tárolhatja a kérelemhez tartozó módosításait. Amikor egy csapattag elkészül,
engedélyezi a feladatát, amivel a feladatához rendelt referenciák a módosítási
kérelembe másolódnak. Midőn minden csapattag elkészül, és az összes feladat
engedélyezve van, a módosítási kérelem is engedélyezhető, amennyiben a csapat
vezetője (a kérelem létrehozója) elfogadta a módosításokat. A kérelem
engedélyezési fázisában a referenciáknak megfelelő adatok fájlokba exportálódnak.
Ezek a fájlok kerülnek később importra a konszolidációs útvonalon lévő további
rendszerekbe.
A projekt során kérelmek létrehozását a technikai csapat bázis csoportja, valamint az
integrációs csapat vezetője hozhat létre, engedélyezhet. Az üzemeltetés során
kialakításra kerülő transzport folyamat a részletes tervben kerül kifejtésre, de a
központosított, megfelelően naplózható kezelést követi az is.
A felelősségi szinteket a jogosultsági rendszerben kerülnek kialakításra. A
transzportok továbbítási mechanizmusa az SAP által rendelkezésre bocsátott
Transport Management System segítségével az STMS tranzakción keresztül
történik. A produktív rendszerbe csak a minőségbiztosításon jóváhagyott
transzportok kerülhetnek be. Ehhez a minőségbiztosító rendszer integrációs (QAST)
mandantjában beállításra kerül a QA eljárás, ami a jóváhagyásfüggő transzportálást
vezérli. A jóváhagyók a projekt során a csoportvezetők, az üzemeltetés során pedig

101
a kulcsfelhasználók lesznek. A transzportálást a technikai üzemeltetés, vagyis a

bázisos szakemberek végzik.
4.4.2.4 Változásmanagement
A változáskezelési rendszer (formálisan a korrektúra és transzportrendszer) opciókat
kínál az adatátvitelre rendszerek között ill. egy rendszeren belül. A eszköz
használható például tuningolt és tesztelt konfigurációs beállítások transzportjára
rendszerek és mandantok között. A változáskezelési rendszer customizing-gal
fennálló integrációja folytán gondoskodik arról, hogy csak egyedi táblabejegyzések
kerüljenek transzportra, így a teszt adatok akaratlan átvitele nem fordul elő. A
fejlesztő mandantban végzett fejlesztések és a konfigurációs beállítások
automatikusan feljegyzésre kerülnek módosítási kérelmekbe. Ezek a kérelmek
később a minőségbiztosító, majd a produktív mandantba kerülnek. Amint a
módosítási-kérelem engedélyezésre kerül a forrás rendszerben, egy transzport
kérelem keletkezik. Ez a transzport kerül átvitelre.
A továbbiakban az adatok átvitelének speciális eseteit tárgyalja a dokumentum.
4.4.2.5 Mandant másolás

Az SAP rendszer lehetőséget biztosít új mandantok előállítására, már létezők
másolásával. A következő eszközök állnak rendelkezésre a mandantmásolásnál:
• Mandantmásolás egy SAP rendszeren belül
• Mandantmásolás összekötött SAP rendszerek között
• Mandant transzport (export/import)
A mandant transzport esetén az exportáló eszköz a forrás rendszer
operációsrendszer szintjén fut és készíti a fájlokat. Az importálás a célrendszer
operációsrendszerén fut a forrásfájlok felhasználásával, majd az utómunkálatokat az
SAP rendszerben végzi.
Két összekötött SAP rendszer közötti mandant másolás esetén, RFC kapcsolaton
keresztül történik a másolás.
A mandantmásolás során az összes customizing és vezérlő tábla átvitelre kerül a
létező, forrás mandantból a célmandantba. Ha további paraméterek is aktívak,
alkalmazási (törzs és mozgási) adatok, valamint felhasználó törzsrekordok is

102
másolásra kerülnek. Másolás előtt a célmandantban a mandantfüggő táblák tartalma

inicializálódik. A másolásra ki nem jelölt táblák tartalma törlődik.
Mandant másolás kérelem alapján
A fejlesztői/konfigurációs mandantban történt customizing változásokat unit tesztelés
céljából néha szükséges ugyanazon SAP rendszeren belül egy másik mandantba is
átmásolni. Csak azok a táblamódosítások kerülnek transzportálásra, amik egy
módosítási kérelembe automatikusan feljegyzésre kerültek. Ez a lehetőség teret nyit
egy beállított alkalmazási terület egyedi tesztelésére az általános beállító mandanttól
elszigetelten.
Módosítási kérelmek transzportja
A kérelem szerinti mandant másolás alkalmazható a konfigurációs beállítások
terjesztésére a fejlesztői rendszerben többi mandantjába. Ahogy korábban is
szerepelt, a mandantfüggetlen módosításokat (pl. ABAP objektumok) nem
szükséges átmásolni, hiszen ezek a rendszer összes mandantjában elérhetők.
Mindazonáltal a rendszerkörnyezet bármely más rendszerébe történik a beállítások
vagy fejlesztések átvitele, szükséges mind a mandantfüggő, mind a
mandantfüggetlen módosításokat transzportálni. Az ilyenfajta szoftverterjesztésre az
R/3 transzport mechanizmusa használható. A mandantfüggő módosítások más
rendszerbe történő átvitelekor ugyanazokat a módosítási kérelmeket használják,
melyeket a fejlesztő rendszer mandantjai közti másolásnál alkalmaztak. A
mandantfüggetlen módosítások a megfelelő workbench módosítási kérelmek
segítségével transzportálhatók a további rendszerekbe. A következő négy lépés írja
le a beállítási és fejlesztési módosítások transzportálását különböző rendszerek
mandantjai között:
• A customizing és/vagy fejlesztési feladatok (task) engedélyezése. (Ezek a
feladatok tartalmazzák a módosítási kérelemhez rendelt teamtagok
módosításait.)
• A customizing és/vagy fejlesztési kérelmek engedélyezése és exportja.
• Módosítások (transzportok) importálása a célrendszerbe.
• Transzportnaplók ellenőrzése.
Nem szabad elfelejteni, hogy a mandantfüggetlen módosítások azonos rendszerben
történő kérelem szerinti mandantmásolásai mindig a kérelemben felsorolt referenciák
szerinti adatok aktuális értékét viszik át. A rendszerek közötti átvitelkor pedig a
103
kérelem engedélyezésének pillanatában meglevő pillanatkép kerül másolásra a

célmandantokba. Ezért fontos a transzportok engedélyezési ideje szerinti
importsorrend betartása.
4.4.2.6 Mandantok kialakítása

Az előző fejezetekben leírt mandantműveletek segítségével a projekt és később az
üzemeltetés számára fontos mandantok az alábbi táblázat szerint kerülnek
kialakításra és frissítésre.
SID Cél Művelet Művelet oka Gyakoriság

Mndt
HRF CUST Rendszermásolás Bevezetési Induláskor
FVM-ről inicializálás egyszer
SAND Mandantmásolás Bevezetési Induláskor
CUST-ról inicializálás egyszer
UNIT Mandantmásolás Bevezetési Induláskor
CUST-ról inicializálás egyszer
SAND Mandantmásolás Frissítés Ad-hoc
UNIT-ról
HRF UNIT Kérelem szerinti Beállítási Ad-hoc
másolás CUST-ból módosítások
HRF Kérelem exportja Elkészült a módosítás Egységteszt után
CUST-ból
HRT QAST Rendszermásolás Bevezetési Induláskor
HRF-ről inicializálás
CONV Mandantmásolás Bevezetési Induláskor
CUST-ról inicializálás
TRNG Mandantmásolás Bevezetési Induláskor
CUST-ról inicializálás
HRT TRNG Kérelem szerinti Beállítási Minőségbiztosítási
másolás QAST-ből módosítások elfogadás után
HRT QAST Kérelem importja Minőségbiztosítási Ad-hoc (CONV is)

104
teszt imp
CONV Kérelem importja Minőségbiztosítási Ad-hoc (QAST is)
teszt imp
HRP PROD Kérelem importja Produktív üzemhez Indulás előtt
kell
PPRD Kérelem importja Előzetes prod. teszt Minőségbiztosítási
elfogadás után
A táblázatban szereplő PPRD (PreProduction) mandant léte még nem eldöntött a

részletes terv végén a tesztelések összaállításánál döl el a szükségessége.
4.4.3 ABAP transzportrendszer

Az SAP a fejlesztéseket és beállításokat ún. módosítási kérelmekbe (Change
Request) gyűjti. Minden fejlesztő, illetver customizing-ot végző tanácsadó ilyen
kérelembe helyezi a módosításait, azonban nem közvetlenül, hanem a számára
fenntartott task-on (feladaton) keresztül. Amink kész a beállítással lezárja a task-ot.
Ekkor a task-ban felsorolt adat ill. fejleszési objektum referenciák átvándorolnak a
kérelem szintjére. Miután minden beállító / fejlesztő befejezte a munkát, maga a
kérelem is lezárható. Ekkor egy pillanatkép készül a referált objektumokról és a
fájlrendszerben keletkezik egy transzport. Ez a platform független állomány, ami
tartalmaz minden információt, vihető át a többi rendszerbe a Transport Management
System (TSM) eszközön keresztül. A taks és kérelem kezelések jogosultsággal
megfelelően elválaszthatók egymástól, hogy ne legyen kavarodás sem projektek
alatt, sem éles üzemben.

105
Ábra 4-26 ABAP kérelem, task kezelés
A fenti ábra mutatja ezt a folyamatot. Fontos megjegyezni, hogy a fejlesztések és

customizing között különbséget kell tenni, ugyanis ez utóbbiak mandantfüggő
adatokkal dolgoznak, a repository objektumok módosításai viszont mandanfüggetlen
feladatok. Ennek megfelelően kétféle módosítási kérelem létezik:
• Customizing request (mandantfüggő adatok számára)
• Workbench request (fejlesztési objektumok és mandantfüggetlen customizing
adatok számára)
Ezen felül a fejlesztési objektumoknál még belép a második lépés is, vagyis a
fejlesztési objektumot (ha új) egy package-hez kell rendelni. Ennek lényege a
fejlesztési objektumok csoportosítása és a transzportútvonal meghatározása. Ez
utóbbi abból adódik, hogy a fejlesztéseket tartalmazó package-t egy fejlesztési
réteghez (transport layer) kell rendelni, ami a transzportútvonalak szerint
meghatározott útvonalat definiál.

106
Ábra 4-27 STMS - Transzport útvonal (scn.sap.com)
A fenti ábra speciális esetet mutat, de számunkra az látszik, hogy egy két rendszeres
landscape alakul ki benne (NW3->NWD), amiben két transzport layer játszik
szerepet: ZNW3 és SAP. Ez utóbbi az SAP standard objektumok módosításainál
játszik szerepet, hogy a módosítások (ún. reparatúrák) is átvihetők legyenek a követő
rendszerekbe. Az alábbi ábra egy „értelmesebb” standard 3-rendszeres környezetet
mutat.
Ábra 4-28 STMS 3-rendszeres landscape (sap.knowledgehills.com)
Itt már látható, hogy a transport layer csak a fejlesztő és teszt rendszer közötti utat
határozza meg, pontosabban, hogy egy adott fejlesztési objektum melyik irányba
menjen (attól függően, hogy melyik package-hez rendelték, ha a package-k más
layer-hez tartoznak). Az ezutáni rendszerek már mint kiszállítási rendszerek
szerepelnek és megadható, hogy számukra mi legyen a forrás. Így lényegében
bármilyen komplikált környezet kialakítható.

107
4.4.4 SAP Java alkalmazások szoftverlogisztikája

Az SAP környezetben az SAP PI (Process Integration, vagy az újabb változat esetén
PO ::= Process Orchestration) és Portal is Java komponensek, ahol bizonyos szinten
eltérő fejlesztési lehetőségek, technikák állnak rendelkezésre. Az SAP J2EE engine,
mint fejlesztői platform is használható. Alapvetően eltér az SAP-s ABAP fejlesztési
szisztémától a Java fejlesztés, minimálisan a technológia és fejlesztői eszközök
tekintetében.
Környezeti elem ABAP Java
Editor Integrált környezetben, ABAP Eclipse alapú külső fejlesztői
Workbench részeként: környezet:
Object Navigator (SE80) SAP NetWeaver Developer Studio
Fordtó / Értelmező Kernel (work-process, ABAP Component Build Service (CBS)
processor or ABAP interpreter)
Runtime környezet Kernel (work-process, ABAP Kernel (Java server process
processor or ABAP interpreter) szálaiban)
Forráskód kezelés A fejlesztői rendszerben kelekezik a Design Time Repository (DTR)
és verzionálás verzió (importáláskor a cél
rendszerben is létrejön verzió, hogy a
felülírttal összehasonlítható illetve
kicserélhető legyen)
Transzport CTS (Korrektúra és Transzport Change Management Service (CMS)
mechanizmus Rendszer), illetve Transport
Management System (STMS
tranzakció)
Mint látható az SAP kialakított egy külön fejlesztői eszközt, hogy kezelni tudja a Java
fejlesztéseket. A Design Time Repository (DTR) szolgáltatás központi forráskód
adminisztrációt végez, így a verziók kezelését is ellátja, ugyanakkor saját
mechanizmus áll rendelkezésre a Change Management Service (CMS) formájában,
ami a rendszerek közti szoftverlogisztikát látja el.
Maga a SAP NetVeawer Developer Studio számos eszköz mellett a következő

fontosabbakat szolgáltatja:
• Web Service Tools: a web-es interfészek fejlesztésére

108
• J2EE Tools: standard J2EE alakalmazások, mint pl. Enterprise Java Beans
(EJB) fejlesztésére szolgál
• Java Dictionary Tools: platform független adat típus és adatbázis objektum
definíciók központi tárolására szolgál
• Persistence Tools: a hosszabb időre felhasználandó adatok tárolására,
mentésére szolgáló eszközkészlet
Természetesen nem csak Enterprise Java Beans használattal lehet Servlet-eket,
JSP (Java Server Pages) alkalmazásokat készíteni, hanem az SAP WebDynpro
technikája is használható. Ez a megoldás előbb létezett Java környezetre, mint
ABAP környezetre, azonban ma már mindkét alkalmazási platform teljes egészében
biztosítja a szolgáltatásait.
A fejlesztési folyamat ABAP és Java környezetben eltér, azonban a következő ábra

szemlélteti, hogy lehet párhuzamot vonni köztük.
Ábra 4-29 Java és ABAP fejleszési lépések/elemek összevetése
Ahogy olvasható volt, a Java fejlesztés lényegében egyedi fejlesztést igényel saját
környezettel. A környezetben számos komponens közreműködik, hogy a fejlesztést
109
megfelelően verzionálja, transzportálja további rendszerekbe. Ez azt igényelné, hogy

minden fejlesztőnek teljes saját környezete legyen, amit az alábbi sematikus ábra
szemléltet.
Ábra 4-30 J2EE lokális fejlesztés (saját környezet)
A fent nevezett komponensek elhelyezkedése és kapcsolata olvasható ki az alábbi

ábráról.

110
Lokális installáció Központi infrastruktúra Futásidő

(fejlesztői PC) (SAP NetWeaver) Rendszer
SAP NW Dev. Studio
CBS
Futásidő
CMS
Deploy Web AS
Java
DTR
Rendszer
Komponens (RTS)
Modell
Név szolgáltatás
Lokális
Lokális fájl
Web AS System Landscape
rendszer Directory (SLD)
Java
n SAP NW Developer Studio n DTR (Design Time Repository)

uSAP komponensmodell teljes u Fejlesztések forrás fájlait kezeli
támogatása n CBS (Component Build Service)
uIntegrált UI NWDI feladatokhoz
u Fejlesztések archívumait (pl. .jar) kezeli
Ábra 4-31 Java fejlesztői környezett központi és osztott fejlesztés esetén
Ha több fejlesztő dolgozik egyszerre, akkor azok akár párhuzamosan is

fejleszthetnek, így a betöltött objektumok verziói keveredhetnek, ami kényelmetlenné
teszi a fejlesztést, ugyanakkor inkonzisztenciához vezethet. Az alábbi ábrán
felhasználtuk a fent mutatott egyszerűsített lokális fejlesztői gépen futó környezet
képét, hogy megmutatható legyen a párhuzamos fejlesztésekkel nem csak független
objektumokat lehet a rendszerbe tölteni, hanem akár azonosakat is, ami problémát
okozhat. Az ábrán a WebAS két arculattal, ún. dual stack (ABAP és Java együtt)
szerepel egyszerűsítési okokból, azonban az SAP már nem támogatja ilyen
környezetek installálását (kivéve az így kiszállított Solution Manager, ill. Process
Integration megoldásokat). Ebben az esetben is a Java alkalmazás az ABAP
alkalmazással (ha adatok kell kinyernie, vagy oda betárolnia) a Jco-n (Java
Connector-on) keresztül kommunikál RFC hívásokkal.

111
Ábra 4-32 Párhuzamos Java fejlesztés
Az ABAP környezetben nincs olyan probléma, mint a Java esetében, hogy több
komponensnek kell kiszolgálnia a fejlesztőt, lokális Java installáció szükséges,
valamint verzió keveredés lehetséges, ugyanis a rendszerbe integrált központi
fejlsztői környezet, az ABAP Workbench áll rendelkezésre.
Ahhoz, hogy ezt a problémát a Java környezetben elkerüljék, az SAP kialakította az
SAP NetWeaver Development Infrastructure (NWDI) komponensét. A célja, hogy az
ABAP környezetben bevált megoldást a Java környezetbe is behozza. Az SAP az
ismert Java standardokra (J2EE, WebDAV, DeltaV, stb.) alapozva alakította ki a
fejlesztési objektumok kezelését és verzionálását. Maga a SAP NeWeaver
Developer Sturio rendelkezik közvetlen hozzáféréssel az SAP NetWeaver
Development Insfrastructure komponens felé, ugyanis az NWDI egy PC oldali
fejlesztői és egy szerver oldali szolgáltatásokat tartalmazó komponensből áll össze,
ami így a fejlesztői csapatnak központi, konzisztens fejlesztést tesz lehetővé,
ugyanakkor a készülő termékek teljes fejlesztési életciklusát támogatja. Az alábbi
áttekintő ábra mutatja, hogy egy teljes rendszerkörnyezet transzport útvonala Java
oldalon is megoldható a SAP NetWeaver Development Infrastructure használatával.

112
Ábra 4-33 Java transzportálás NWDI segítségével (help.sap.com)
Az ábra lényege, hogy az NWDI hogyan használja a CMS-t (Change Management

System), vagyis a Java oldali transzport rendszert. Az általános ABAP fejlesztő –
teszt – produktív rendszerkörnyezetével szemben az NWDI négy környezetet
(fejlesztési fázist) tart számon a Java fejlesztésekhez:
• Fejlesztő(DEV) – A fejleszéseket elemi egységenként (Activity) lehet
központilag tesztelni
• Konszolidációs(CONS) – Az elemi egységeket teljes szoftverkomponens
archívummá (SCA) állítja össze
• Teszt(TEST) – Az SCA tesztelése zajlik itt
• Produktív(PROD)
Nem minden fejlesztési fázishoz tartozik kötelezően tényleges futtatókörnyezet. Az
üzemeltetés szempontjából az SLD és a CMS alrendszer a releváns (lásd alább).
A Java komponensek logisztikáját a NetWeaver Development Infrastucture (NWDI)
alkalmazás biztosítja több fejlesztő esetén, amely az egyik fejlesztő rendszeren
helyezkedik el. Az NWDI öt fő komponensből áll:
1. System Landscape Directory(SLD) – a fejlesztendő és az az által
előfeltételként megkövetelt szoftverkomponensek definícióját tartalmazza. A
SLD felelős továbbá a Java fejlesztési objektumok ütközésmentes
névkiosztásáért is.
2. Design Time Repository (DTR)– a fejlesztendő szoftverkomponens
forrásobjektumait tartalmazza (Java kódok, konfigurációs file-ok, WebDynpro
definíciók, stb)

113
3. Component Build Service (CBS) – a fejlesztendő komponens bináris file-jait

építi fel, illetve tartalmazza a fejlesztett objektum által megövetelt egyéb
komponensek binárisait
4. Change Management System (CMS) – A fejlesztett objektumokat menedzseli
az egyes fejlesztési fázisokon keresztül.
5. Fejlesztői munkaállomás – a fejlesztő munkaállomására egy NetWeaver
Developer Studio (NWDS) kerül. Az NWDS a CMS információi alapján
lokálisan letölti a fejlesztéshez szükséges forrásobjektumokat (a DTR-ből),
illetve binárisokat (a CBS-ből). Az elkészült új fejlesztések visszakerülnek a
DTR-be, majd a kész szoftver komponenst a CBS építi meg telepíthető
archívummá (.SCA file).
A fejlesztendő szoftverkomponensek egy adott verzióját egy ú.n. track-ben tartjuk
nyilván. A DTR-ben, és a CBS-ben a track-hez tartozó objektumok elkülönült
környezetet kapnak.
4.4.5 Központi szoftverlogisztika

Az SAP Solution Manager lehetővé teszi a két szoftverlogisztika egyesítését és
kényelmesebb kezelését. Az SAP igyekezett a SAP Web AS Java (J2EE)
környezetben az ABAP technológiánál kialakított és bevált technikát alkalmazni a
fejlesztések kezelésére.
Ehhez be kell kapcsolni a CTS+ szolgáltatást (persze ez jelentős technikai
konfigurációval jár, de megéri). A megoldás kiterjeszti a CTS megoldás ABAP
környezetben adott szolgáltatásait nem ABAP objektumokra is, így többek között
Java komponensek számára is.

114
Ábra 4-34 CTS+ használata ABAP és Java esetén (help.sap.com)
A fenti ábra integrálja az ABAP CTS és Java CMS+NWDI funkciókat. Így lehetővé
válnak a következők:
• alkalmazások (pl. WebDynpro for Java és Portal iView) automatikus
szinkronizációja lehetséges, vagyis egy transzport eszköz használatával lehet
ugyanazon alkalmazás különböző részeit transzportálni.
• központi ellenőrzés az összes transzport fölött, amik a produktív rendszerekbe
mennek
• Nyomon követhetők a transzportok, lazán alakítható transzport útvonalak, és
üzemezett betöltések, deploy-ok
A CTS NWDI-jal történő integrálása az SAP NetWeaver Developer Infrastructure
összeállító fázisában történik technikailag, ahogy a Software Component Archive
(SCA) állományok létrejönnek és csatolhatókká válnak a Transport Management
System transzport kérelmeihez. Ezután már a többi lépés a TMS segítségével zajlik.
Így könnyedén kezelhetővé válnk az összetett landscape-k is.
Tovább is fokozható az integráció és felügyelet a Solution Manager speciális ún.

Change Request Management (ChaRM) funkcionalitásával. Ez azonban nem része a
jegyzetnek.

115
4.5 Patchelés, verzió követés

Az SAP környezetben az operációs rendszer, az adatbázis-kezelő és az SAP
rendszer is tartalmazhat hibákat, melyeket javítani lehet, ugyanakkor a szoftverek
gyártói újításokat is szállítanak készítenek. Ezen javításokat, újításokat patch-ekkel
tölthetjük a rendszerekre. Természetesen nagyobb verzióváltásra is okot adhat egy
újabb fejlesztés, ami nincs meg a jelenlegi verzióban.
Az SAP szoftver két nagy részből, az SAP kernel és az ABAP/Java program szintből
áll, melyek mindegyike külön patch-elhető. A kernel az SAP bináris, lefelé
kompatíbilis szoftverkomponense. Az SAP rendszerekben minden program,
tranzakció, stb az ABAP programozási nyelven íródott. Ezek a programok szintén
javíthatók az ún. Support Packegekkel.
4.5.1 Support Packagek

Az Online Correction Support (OCS) szolgáltatás keretében az SAP ABAP szintű
javításokat tartalmazó csomagokat bocsát rendelkezésre. Ezek a csomagok ún.
Support Package formájában jelennek meg. Különböző Support Package fajtákkal
lehet találkozni, melyek használat a a kiválasztott mySAP Business Suite terméktől,
és annak verziójától függ.
Minden SAP alapú rendszer (ERP, BI, CRM, Portal, stb.) egy ún. SAP bázis
rendszeren nyugszik (Web AS). Előfordul, hogy ebben a részben is ABAP hibák
vannak. Ezek javításár a szolgálnak a bázis (SAP_BASIS), az Application Interface
(SAP_ABA), az Alkalmazási Platform (SAP_AP), valamint a 7.00-s verziótól ugyanitt
helyet kapó Business Warehouse (SAP_BW) csomagok. Jelen pillanatban az ERP
termék bázis rendszerének verziója (7.0) különbözik az alkalmazási verziótól (6.00).
A SAP ERP megoldással az SAP útjára bocsátotta azt a víziót, melyben egy
szervezeten belül az üzleti hatékonyság növelhető az új generációs ERP megoldás
felé, automatizálva az üzleti folyamatok egymáshoz illesztését és kiterjesztését az
Intézmény határain túlra, a teljes üzleti ökoszisztémáig, ami magába foglalja az
ügyfeleket, partnereket és szállítókat is.

116
Ábra 4-35 SAP ERP magas szintű szoftver felépítése (help.sap.com)
A képen látható felosztás inkább license politikai szempontból mutatja be az ERP

lehetőségeit, azonban az alábbi már utal a technológiára is.
A bázis rendszerre (WebAS) épül az ABAP nyelven megírt alkalmazás (az ábrán
„SAP ECC”), amibe a beállítás szerinti adatok kerülnek, valamint ez hordozza az
üzleti logikát is. Az SAP ERP 6.0-ás verzió teljes egészében a megelőző verziók
alkalmazásainak (Application Core) funkcióira épülnek. A stabilitás és a teljesítmény
tovább javult, továbbá nőtt a user exitek, BAdI-k és a BAPI-k száma is. Az SAP
folyamatosan frissíti, szükség esetén javítja, ill. bővíti a core alkalmazásokat.
Speciális, új funkcionalitásokkal azonban nem bővíti a core rendszert.
A Core ERP funkcionalitás tekinthető az alap HR (SAP_HR), valamint a pénzügy és
logisztika (SAP_APPL) alap funkcióinak gyűjteményeként. Az olyan speciális
bővítéseket, melyek nem iparági megoldások, azonban nem feltétlenül mindenki
akarja használni őket, ún. Extension Set-ekbe foglalta az SAP. Ilyenek pl. a EA-PS
(Public Services, közigazgatási modulok), EA-GLTRAD (Global Trade)
funkcionalitások. Ezek az Extension Set-ek EA előtaggal kezdődnek, hiszen ezek
Extension Add-on-ként élnek a rendszerben. A switch Framework segítségével ezek
külön kapcsolhatók be ill. a patch-elésük is külön zajlik. Természetesen külön terület
még az iparági megoldások (pl. jelen esetben IS-U) halmaza. Az új ERP verzió már
tartalmazza ezek nagy részét és nem kell külön add-on jelleggel installálni őket.
Használatukhoz be kell kapcsolni a megfelelő funkcionális területet a switch
framework-ben, valamint el kell végezni a patch-elést.
Ezeken kívül plug-in-ek (pl. BW, CRM ill. Solution Manager kapcsolathoz), valamint
lokalizációs add-on-ek szerepelnek egy rendszerben. A következő ábra a
dokumentum írásakor meglevő patch szinteket mutatja, amit a SPAM tranzakcióban
tekinthetünk meg.

117
Ábra 4-36 SAP komponens lista – SPAM ©SAP
Az ábrán látható pl. egy speciális, alapvetően nem kiszállított komponens az MRSS
(Multi Resource Scheduling System). Ez a megoldás külön package-ként szerepel a
rendszerben, így különálló patch-elés szükséges a modul számára.
Amennyiben Enhancement Package (EHP) is bekerül egy rendszerbe, akkor
megváltoznak a verziószámok bizonyok komponensek esetében. Pl. ha ERP EHP3
kerülne betöltésre, akkor a legtöbb 600-ás verziójú elem (pl. SAP_APPL, IS-U) 603-
as verzióra kerülne át. Hasonlóan ha a NW EHP1 kerülne betöltésre, akkor a WebAS
részét képző SAP_BASIS, SAP_ABA, SAP_AP, ill. SAP_BW kerülne a 700-ás
verzióról 701-re. Ezután természetesen az új verzióhoz (mint 4.6B ill. 4.6C) tartozó
SP-ket kell letölteni.
A SAP Service Marketplacen (http://service.sap.com) ellenőrizhetjük, hogy az adott
komponenshez milyen javítócsomagok készültek az utolsó ellenőrzés óta. Ha a SAP
Solution Manager rendszerből szeretnék elvégezni a javítócsomagok keresését,
akkor az is megoldható, azonban külön konfigurációra van szüksége ebben az
esetben. A konfiguráció eredményeképpen a Solution Manager mindig friss
információval rendelkezik a kapcsolódó komponens rendszerek állapotáról, valamint
ezeket elküldi az SAP-nak, hogy a support könnyebben valósulhasson meg. A friss
adatok támogatásával le tudja vizsgálni, hogy készültek-e újabb SP-k az installált
SAP komponensekhez és azokat felkínálhatja letöltésre.

118
Alapvetően nem szükséges a Solution Manager-en keresztül keresni, ezt meg lehet
tenni a Service Marketplace felületén is (http://service.sap.com/patches, vagy
http://support.sap.com/patches).
Ábra 4-37 SAP Service Marketplace (suport.sap.com)
Ugyanakkor arra figyelni kell, hogy a Support Package-ket nem lehet közvetlenül
letölteni, hanem azokat be kell helyezni a „Download basket”-be. 2007. április 2. óta
ezen felül még a Solution Managerben is el kell végezni az engedélyezési folyamatot
(approve) és csak azután lehet letölteni a Download Manager-rel, a Solution
Manager-rel vagy akár az objektum mentése popup menüponttal.
Ábra 4-38 SAP Download Basket (support.sap.com)

119
A Solution Manager-ben történő engedélyező folyamatot egy másik fejezet

tartalmazza.
A letöltés után a 000-ás mandantban megfelelő jogosultságokkal (nem SAP*
felhasználóval) lehet végrehajtani a SPAM tranzakcióban a patch-ek betöltését.
Fontos megjegyezni, hogy a SPAM tranzakció is gyakran javításra, bővítésre szorul,
így a legfrissebb ún. SPAM Update le- és betöltése mindig előzze meg a többi SP
betöltését.
Ábra 4-39 SPAM update (support.sap.com)
A fenti ábra a SPAM update elérhetőségét mutatja a Service Marketplace-en. A

SPAM update betöltése is a SPAM tranzakcióban zajlik, azonban erre külön
menüpont van delegálva.
Ábra 4-40 SPAM update betöltése ©SAP
Amennyiben egy OSS javításr a van szükség, de a Support Package, ami tartalmazz
a még nem játszható be a fent leírt okok miatt, kézzel vagy az SAP által
rendelkezésre bocsátott Note asszisztenssel kell feltölteni.

120
4.5.2 Kernel patch-ek

Amint a dokumentumban már korábban szerepelt, a legújabb kernel patch-et kell
alkalmazni az SAP rendszerkörnyezet összes instanciájánál. A kernel az SAP
alkalmazásszerver végrehajtható, operációsrendszer függő fájljait és adatbázisfüggő
transzport ill. mentési programokat (pl. tp, R3trans, brbackup) programokat tartalmaz.
A megfelelő kernel patch is a SAP service Marketplace oldaláról
(http://service.sap.com/patches) tölthető le.
A frissítés következőképp zajlik:
• Le kell állítani az SAP rendszert (minden instanciát). Ez Windows
környezetben a Management Console felületről történik. Nem szabad
elfelejteni az SAP service-ket is leállítani.
• Biztonsági mentést kell készíteni az aktuális kernel fájljairól, vagyis a
<d:>\usr\sap\<SID>\sys\exe\run\nuc könyvtár tartalmát egy ideiglenes
könyvtárba kell másolni. Ezzel a mentés gondoskodik arról, hogy a kernel nem
megfelelő működése esetén a régi kernel visszaállítható legyen. (Az ERP
esetén szerepel a fenti könyvtár, ugyanis az non-unicode installáció, viszont a
többi rendszer már unicode rendszer, így azoknál a használatos könyvtár a
<d:>\usr\sap\<SID>\sys\exe\run\uc.)
• Az új kernelt telepíteni kell a CAR vagy SAR fájlokból. Ehhez a célkönyvtárban
állv a a CAR –xvf <forrásfájl>.CAR (vagy SAPCAR –xvf <forrásfájl>.SAR)
paranccsal ki kell tömöríteni a futtatható fájlokat.
• A központi instanci a elindítás a és ellenőrzése (rendszer napló és fejlesztői
trace fájlok vizsgálata) után a többi instanci a is indítható.
Az újabb verzióknál a frissített kernelt elegendő a központi instanciár a telepíteni.
Ugyanis az alkalmazás szerverek START profil beállítás a szerint, indításkor képes
letölteni a központi instanciáról a frissebb kernelt.
A lefelé kompatíbilis kernel azt jelenti, hogy pl. egy 4.6B bázis release-en futó
rendszer (pl. 4.6B-s R/3) futtatható 4.6B, 4.6C és 4.6D kernellel is (bár a példa 4.6-
os, de ez él az újabb verzióknál is). A magasabb verziójú kernelhez a legfrissebb
patch alkalmazás a előtt, a magasabb verziónak megfelelő teljes kernelt installálni
kell. Csak ezután tölthető rá a patch. Vagyis a patch az installált kernellel azonos
verziószámú kell, hogy legyen. Az SAP kernel szintjét az SM51-es tranzakció release
info gombjával érhetjük el (vagy a Rendszer->Státusz -> További kernel infó
gombbal). Az operációsrendszer szintjéről a ’disp+work –V’ parancs kiadásával. A
frissített SAP kernel szintén a service marketplacen, a http://service.sap.com/patches
címen érhető el. A frissített fájlok letöltése során érdemes a fájlnév_verziószám

121
konvenciót használni, így gyorsan összehasonlíthatóak a már meglévő fájlok az

újakkal.
A rendszerkörnyezetben a fejlesztő, minőségbiztosító, majd produktív rendszereket
sorban, tesztelve szabad csak patch-elni.
4.5.3 Adatbázis- és operációsrendszer patch-ek

Az SAP futtatásához megfelelő Windows2003 szintre van szükség. Az
operációsrendszer gyártója hasonlóan az SAP-hoz rendszeresen kibocsát javító
csomagokat. A hardver szállítójánál kell érdeklődni, hogy egy adott javítás az SAP
rendszer stabilitását nem befolyásolja-e.
Az adatbázis-kezelő gyártója is (jelen esetben ugyanaz) mindig újabb verziókat dob
piacra. Az SAP ezeket teszteli, és megfelelő patch szint esetén engedélyezi az adott
SAP kernel verzióhoz. Egy SAP kernel alatt akár több adatbázis-kezelő verzió is
megfelelő lehet. Ezzel biztosítja az SAP azonos SAP komponens verzió
használatakor az adatbázis verzióváltást. Ajánlott a legfrissebb adatbázis verzió
használat a az aktuális patchset installálásával. Ezekről az SAP mindig ad
információkat az útmutatókban (notes).
4.5.4 Verzióváltás
A verzióváltás (upgrade) és javítócsomag betöltésnél a rendszer mielőtt behozná a
módosításokat, azokat az objektumokat, amiket módosított (reparált) az ügyfél,
valamint az SAP is kiszállítja új verzióval elmenti az ún. verzió adatbázisba. Egy
másodlagos ún. shadow (árnyék) repository-t készít, ami tartalmazza az összes új
objektumot, ill. ahogy az ábra is mutatja, az ügyfeles, saját fejlesztések érintetlenül
átkerülnek ide, sőt még azok a standardmódosítások is, melyeket nem szállít ki az
SAP új verzióval. Amikor mindent aktivált az upgrade folyamat az új repositoryban,
visszamásolja a jelenlegi helyére.

122
SAP
Repository
Ügyfélmódosítás
Ügyfélmódosítás SAP
SAP módosította
módosította
Verzió Ügyfélmódosítás shadow-ba másolás Ügyfélmódosítás

Ügyfélmódosítás Ügyfélmódosítás
készítés
Ügyfeles shadow-ba másolás Ügyfeles
Verzió
adatbázis Objektumok Objektumok
Ügyfél Repository Új Repository
Ábra 4-41 SAP verzióváltás repository egyeztetés (scn.sap.com)
Ekkor a rendszer már használható az új verzión, ill. javítócsomag betöltésekor az új

kódokkal, azonban a standardmódosítások még kezelésre várnak.
A rendszer ekkor az új, eredeti SAP verziókkal dolgozik, azonban lehetőséget
biztosít a verzió adatbázis segítségével a módosított és az új, eredeti SAP-s
objektumok összehasonlítására, egyeztetésére. Az egyeztetés során döntünk arról,
hogy melyik verziót kívánjuk továbbá használni, esetleg a kettőből egy újat gyúrva.
Természetesen a döntésünk bekerül a módosítási kérelembe, hogy a transzport
útvonal következő rendszereibe már csak importtal kelljen betölteni az egyeztetés
eredményét.
SAP
Repository
SAP
SAP módosította
módosította Módosítások
Egyeztetése
Egyeztetett
Egyeztetett
Módosítás
Módosítás
Ügyfeles
Verzió Objektumok
adatbázis
Ügyfélmódosítás SPDD/SPAU
Ábra 4-42 Upgrade/patch standard módosítások kiigazítása (scn.sap.com)
Az ABAP Workbench így egy kifejlett, minőségi környezetet biztosít SAP standard,
külső, vagy saját fejlesztési elemek létrehozására, módosítására, kezelésére. A
customizing és táblatartalom módosításokkal beállítható rendszer lehetővé teszi,
hogy úgy vezéreljük a programok, alkalmazások üzleti logikáját, hogy a program
kódokhoz ne kelljen nyúlni. Pl. bérelemek táblázata is ide tartozik.

123
SAP technológiai architektúra Jogosultság- és felhasználókezelés, authentikáció
5 Jogosultság- és felhasználókezelés, authentikáció

Az SAP rendszerek saját jogosultsági rendszerrel, felhasználókezeléssel és
authentikációval rendelkeznek. Alábbiakban bemutatjuk a jogosultsági rendszer
felépítését, valamin az ahhoz kapcsolódó biztonsági elemeket, termékeket.
5.1 SAP felhasználó adminisztráció

Az SAP rendszereket a felhasználók csak egyedi azonosítóval használhatják, melyet
a bejelentkezés során kell megadniuk. A rendszeren beül minden jogosultság,
szerep ehhez az SAP azonosítóhoz kötődik. Az egyes SAP rendszerekben a
felhasználók célszerűen egyforma azonosítóval rendelkeznek, de a jogosultságok
csak az adott rendszerben (adott mandantban) érvényesek és egymástól teljesen
függetlenek, azaz egy jogosultság egy adott rendszerben automatikusan nem jár
együtt egy másik rendszerben érvényes jogosultság meglétével vagy megadásával.
A felhasználókat felhasználói csoportokba lehet sorolni. Minden felhasználói
csoporthoz be kell állítani az adott csoportba tartozó felhasználók törzsadatainak és
jogosultságainak karbantartásáért felelős felhasználó adminisztrátort és jogosultság
adminisztrátort.
Biztonsági vagy hatékony rendszerműködési okokból korlátozni lehet a felhasználók
bejelentkezését. Egyes felhasználók például csak munkanapokon, vagy csak minden
hónap 5. és 25. napja között dolgozhatnak.
A SAP felhasználó törzsben 5 típusú felhasználót különböztetünk meg, amint az ábra
is mutatja.

124
Ábra 5-1 SAP felhasználói típusok
Felhasználó típusok az ABAP rendszerekben:

• Dialóg típusú felhasználó: online (SAP kliensen, a Web portokon vagy pl. az
RFC interface-en keresztüli) bejelentkezésre szolgáló felhasználó, egyetlen
(valós) természetes személyhez köthető. A dialog felhasználók esetében a
többszörös bejelentkezés naplózható illetve letiltható.
• Rendszer (System): A SAP rendszeren belüli háttér folyamatok számára vagy
rendszer működésé¬hez szükséges kommunikációs interface-ekhez
használható felhasználó. SAP kliens felüli bejelent¬kezésre nem alkalmas.
• Kommunikációs felhasználó: kifejezetten az SAP RFC interface-en keresztüli
kommunikációra használandó felhasználó, tipikusan más SAP vagy nem SAP
de RFC képes külső rendszerekkel való adatcserére hozunk létre ilyen, az
adott kapcsolathoz nevesített felhasználót.
• Szolgáltatás (service) típus felhasználó: a rendszeren belül bizonyos
rendszerszintű szolgáltatások működéséhez beállított felhasználó: pl. a Web-
es felületen a bejelentkezési képernyő megjelenítése – mint ABAP program –
ilyen típusú user nevében fut, majd a sikeres authentikáció után már az
azonosított felhasználó nevében történik minden.
• Referencia típusú felhasználó: Ezt a fajta felhasználót jogosultságok
gyűjtőjének lehet használni, vagyis másik felhasználónak nem jogosultságok
125
adunk, hanem egy referencia felhasználó jogosultságaira hivatkozunk, vagyis

mondhatni örökli az ott megadott jogokat. Egy referencia felhasználóval nem
lehet bejelentkezni.
A felhasználó adminisztrációja a SAP felhasználói törzsben történik (SAP User
Master), ahol minden lénye-ges adat megtalálható a felhasználóról,
• Cím adatok: név, megszólítás titulus, kommunikációs adatok, telefon,
levelezési és e-mail címek, földrajzi elhelyezkedés (Intézmény cím, épület,
szoba, telefon
• SAP bejelentkezési adatok: felhasználó típusa (dialog, batch,
kommunikációs), felhasználó csoport, felhasználó időbeli érvényessége,
státusz (zárolt, zárolás oka)
• Alapértelmezett értékek: kezdő menü, alapértelmezett nyomtató,
bejelentkezési nyelv, tizedes és dátumformátum.
• Paraméterek: az egyes alkalmazói programok számára beállítható változók és
értékeik, mely egy-egy felhasználó esetében alapértelmezetten kerülnek
beállításra - opcionálisan vagy kötelező érvénnyel - pl. a tranzakciós
képernyők egyes beviteli mezőin vagy szelekciós mezőkben.
• A felhasználó szerepei: a jogosultság rendszerben definiált szerepek időfüggő
hozzárendelése a felhasználóhoz.
• A felhasználó jogosultsági profiljai: a SAP jogosultsági rendszerben definiált
jogosultsági profilok hozzárendelése a felhasználóhoz. Ez hozzárendelés
történhet manuálisan vagy a szerepeken keresztül.
• Beállítások alkalmazások testre-szabásához: a felhasználó által állítható
preferenciák bizonyos alkalmazói funkciók működésével, kinézetével,
tranzakciós képernyő felépítésével kapcsolatban stb.
• A felhasználó SAP licensz szerinti besorolása.
Az alábbi ábrán a felhasználó adminisztráción belül a cím adatok karbantartása
látható.

126
Ábra 5-2 Példa a felhasználó adminisztrációra
A felhasználói törzs karbantartásához a SAP rendszer integráltan tartalmazza a

szükséges eszközöket, melyek az SAP felhasználó adminisztrációs moduljának
részét képezik. Segítségével az alábbi feladatok hajthatók végre:
• Felhasználói törzs adminisztrációja: felhasználó törzs rekord létrehozása,
módosítsa, felhasználó paraméterek, jogosultsági attribútumok karbantartása,
felhasználók zárolása, másolása, érvényességének lejáratása, indokolt
esetben törlése.
• Jogosultsági szerepek létrehozása a jogosultsági profile-ok alapján, szerepek
hozzárendelése felhasználókhoz
• Indirekt szerep hozzárendelés megvalósítása SAP rendszerben definiált
szervezeti struktú-rában elfoglalt pozíció alapján.
• Felhasználó információs rendszer: teljes körű változáskövetés, naplóvezetés
és jelentés készítés a felhasználó adminisztrációs és jogosultsági
rendszerben történ változásokról, módosításokról. Különböző szintű
értesítések (riasztás, figyelmeztetés, információs rekord) generálása

127
biztonsági eseményekről, mint pl. érvénytelen jelszóval történő hibás

bejelentkezési kísérletek
• Felhasználói törzs rekordok tömeges módosítása, karbantartása (pl.
felhasználók zárolása) széleskörű szelekciós lehetőségek alapján (pl.
bizonyos jogosultsággal rendelkező felhasználók leválogatása)
• Inaktív felhasználók automatikus kijelentkeztetése, inaktív azonosítok
automatikus zárolása.
A felhasználó adminisztrációs feladatok – mint minden egyéb tevékenység –
jogosultsághoz kötött funkció az SAP rendszerben. Ezen jogosultságok segítségével
biztosítjuk az SAP rendszerben, hogy ne legyen összevonható egyetlen kézbe a
jogosultság és felhasználó kezelés folyamat: a felhasználó adminisztráció
kapcsolódó jogok egyrészt elválaszthatók a jogosultság adminisztrációtól
(jogosultságok tervezése és definiálása,) illetve a szerep adminisztrációtól (szerepek
létrehozás, jogosultságok szerepekhez történő rendelése) valamin a szerepek
felhasználókhoz történő hozzárendelésétől.
A felhasználó fent említett adati közül egyesek karbantartását – beállítástól függően
– átengedhetünk a magának felhasználóknak, pl. hogy az intézményi telefon számát
ő maga állíthassa be saját magának. A felhasználó számára módosíthatóvá tehető
adatok pl. a „Cím”, „Állandó” adatok, és Paraméterek. Termé-szetesen ez a
lehetőség teljesen el is vehető a felhasználóktól.
Alapértelmezetten minden Web AS ABAP rendszernek (és azon belül pl. minden
SAP mandantnak) önálló, egymástól független felhasználó-törzse van, melyeken a
felhasználó adminisztráció egymástól függetlenül történik. Komplexebb, több
rendszerből álló környezetek esetében azonban célszerű a felhasználó
adminisztrációt központosítani. A rendszert alkotó SAP komponensek esetében az
SAP Központi Felhasználó adminisztráció funkcióját (Central User Administration –
CUA) állítható be, melynek segítségével egy célszerűn kiválasztott rendszerből - az
ún. CUA mandantban - karbantartva a felhasználói törzset, az, az összes bekötött –
ún. CUA kliens - rendszer felhasználó törzsébe átszinkronizálható, SAP standard
(ALE/RFC) interface-en keresztül. Ezzel azt érjük el, hogy technikailag az IDM
(Identity Management) megoldásnak nem kell minden SAP rendszer felé kiépíteni a
kapcsolatot, hanem csak a CUA mandant felé és az továbbítja az adatokat a

128
komponens SAP logikai rendszerek felé. A CUA önállóan is él az SAP IDM

megoldástól függetlenül.
A központi felhasználó adminisztrációba a korábban felsorolt felhasználói
attribútumok mindegyike karban-tartható. Az egyes attribútumokról egyedileg
eldönthető, hogy azokat csak központilag, vagy csak a lokális CUA kliens
mandantba, vagy mindkettőben, meghatározott precedencia mellet tartjuk karban.
Így például dolgozó beléspése esetén központiag karbantarthatjuk alapvető adait
(név, telefon szám, szobaszám stb.) és hozzárendelhetünk szerepet az összes
szükséges SAP rendszerben.
A CUA rendszerben lehetséges központilag végrehajtani a szerep-hozzárendelést
vagy visszavonást minden bekötött CUA kliens rendszerre vonatkozólag. E központi
szerep-hozzárendelés alapján – a szinkronizáció révén - a megfelelő jogosultság
profile és jogosultság már a CUA kliens rendszerben rendelődik hozzá a
felhasz¬nálóhoz és - természetesen - a jogosultság ellenőrzése is itt történik.
Mind a felhasználó érvénysége mind a szerephozzárendellés időfüggő módon
történik, azaz pl. csak a megadott időpontól csak megadott időpontig aktív a
felhasználónév és a hozzárendelet szerepekkel is csak a beállított időkorlátok között
rendelkezik. Ezen időpontos követen a szerep mögött lévő jogosultság
automatikusan visszavonásra kerül az adott rendszerben.
Kilépéskor célszerűen a felhasználót nem töröljük a rendszereből csupán a
felhasználói azonosítóját és szerephozzá rendeléseit járatjuk le, mellyel együt
jogosultságai is vissza-vonásra kerülnek. Ideiglenesen távol lévő felhasználót pedig
központilag, az összes rendszerre vonatkozólag tudunk zárolni, majd kérésére ismét
aktiválni az eredeti hozzáféréssel és jogosultságokkal. A három rendszeres üzemi
környezet esetében – fejlesztő, teszt és éles rendszerek – célszerű a produktív és a
nem produktív rendszereknek két önálló CUA környezetet kialakítani, két független
CUA mandanttal.
A CUA rendszer számára természetesen bármelyik Web AS ABAP alapú rendszer
üzemi vagy éppen egy szeparált mandantja megfelel, de általában a központi
szerepet betöltő SAP Solution Manager rendszer egy külön mandantját szokás
használni. A produktív rendszerek központosított felhasználó adminisztrációját pl. a
produktív Solution Manager rendszerbe, míg a fejlesztő és teszt SAP rendszerek
felhasználó adminisztrációját a közös teszt/fejlesztő Solution Manager rendszerbe
129
valósítjuk meg. A CUA mandant kiválasztása és az CUA architektúrának a

véglegesítése a részletes tervezés során fog megtörténni.
A Web AS JAVA alapú rendszerek is alapértelmezetten önálló felhasználó törzzsel
és felhasználó adminisztrációval (ún. UME - User Management Engine
szolgáltatással) rendelkeznek. Egy Web AS JAVA rendszer esetében a felhasználói
törzset 3 helyen alakíthatjuk ki:
• A Web AS JAVA saját adatbázisában
• Egy Directory Service-ben, LDAP protokollon keresztül összekötve a JAVA
felhasználó adminiszt-rációs szolgáltatásával (az UME-val)
• egy ABAP rendszer felhasználó törzsére kötve RFC/JCo-n keresztül.
Legtöbb esetben, mint pl. a BW-hez kapcsolható Portalok esetében mindig az utóbbit
választjuk és a J2EE UME szolgáltatását rákötjük a CUA rendszerként kijelölt SAP
Solution Manager rendszerre, pontosabban annak egy kifejezetten a J2EE motort
reprezentáló mandantjára (amiben más nem is zajlik). Így a CUA-ba felvett
felhasználók egyúttal Portál felhasználók is lehetnek. A CUA rendszerben, az ABAP
oldalon az SAP portál számára speciális ún. CUA-Portál szerepeket alakíthatunk ki,
melyek – a ABAP-UME összekötés révén - a portáloldalon, mint Portál felhasználó
csoportok (User group-ok) jelennek meg. A Portál oldalán e felhasználó
csoportokhoz rendelhetjük hozzá a Portal vagy JAVA szerepeket (jogosultságokat).
Az SAP rendszeren belüli eszközökkel végrehajtott felhasználói karbantartás mellet
lehetőség van a felhasz-nálói törzs meghatározott attribútumait külső adatforrásból,
pl. egy központi címtárból, szinkronizálni. Ez a szinkronizáció LDAP protokollon
keresztül történhet, címtár és az ABAP rendszer felhasználói törzse között. Az LDAP
szinkronizációhoz az ún. LDAP konnektort a SAP, a megfelelő LDAP kliens library-t
az alkalmazás szervert futtató adott platform operációs rendszer szállítója biztosítja.
A szinkronizáció előfeltétele, hogy az LDAP-on keresztül elért adatbázis
rendelkezzen egy megfelelő struktúra kiegészítéssel, ami a SAP felhasz-nálói törzsre
jellemző adatok tárolását teszi lehetővé. E struktúra kiegészítés definícióját az
elterjedtebb LDAP szerverekhez az SAP a rendszerrel együtt szállítja.
A LDAP szinkronizáció lehet egy irányú – a SAP felé vagy az LDAP rendszer felé –
illetve kétirányú. Azt, hogy az egyes attribútumok az SAP-ban vagy egy címtárban
legyenek elsődlegesen karbantartva, egyen-ként meg lehet határozni az LDAP
szinkronizáció konfigurálása során.
130
Az LDAP szinkronizáció természetesen egy CUA rendszerrel is kiépíthető, így akár

az is lehetséges, hogy egyetlen központi cím tárból tudjuk karbantartani az összes
SAP rendszer felhasználó-törzsét illetve végre-hajtani a felhasználó-szerep
összerendelést is.
5.2 Az SAP jogosultsági rendszere

Az SAP rendszerek egy nagyon szerteágazó és a folyamatokhoz jól illeszthető
felhasználói jogosultsági rendszerrel rendelkeznek, mely jogosultsági rendszer
kapcsolatba hozható a felhasználói menükkel és a függelmi viszonyokat is
figyelembe vevő szervezeti struktúrával. A rendszerben a felhasználók és
jogosultságaik központilag karban tarthatók. Az SAP gyakorlatilag komoly
eszközöket nyújt a kidolgozott, szervezethez illeszkedő jogosultsági elképzelésekhez
és feltételezi ezek meglétét. A későbbiekben jól kézben tartható, központilag
kezelhető felhasználói azonosító és jogosultság rendszer alapját a nagyon pontosan
definiált szerepkörök és a szerepkörökhöz rendelt tevékenységek és jogok
határozzák meg.
5.2.1 Általános tulajdonságok

Az SAP rendszerben a felhasználók tevékenységét MAC (Mandatory Access
Control) elven alapuló jogosultsági rendszer szabályozza.
Ez a jogosultsági rendszer kiterjed a felhasználó által futtatható tranzakciókra, ezen
tranzakciók funkcióira, illetve a tranzakciók által elérhető adatokhoz történő
hozzáférésekre. A tranzakciók és a tranzakciók részét képező funkcióhoz
kapcsolódó jogosultságokkal lehet például szabályozni, hogy a felhasználó jogosult-e
bizonylatok főkönyvi könyvelésére, jogosult-e a mások által könyvelt bizonylatok
megtekintésére, jogosult-e áru kiadására, jogosult-e megrendelés kiadására,
jogosult-e a kiadott megrendelések megtekintésére, stb.
5.2.2 A jogosultsági rendszer elemei

A Web AS ABAP rendszeren belül egy funkcionális objektumhoz való hozzá féréskor
vagy egy funkció végrehajtásakor a felhasználónak rendelkeznie kell a megfelelő
jogosultsággal (authorization).

131
Az egyes funkciókat (programokat, tranzakciókat stb.) ún. jogosultsági objektumok

(authorization object) védik, melyek egy vagy több paraméterrel, ún. jogosultsági
mezővel (authorization filed) rendelkeznek. Míg a jogosultsági objektum magára a
funkcióra vonatkozik, a jogosultsági mezőkkel általában a hozzá férés módját (pl.
olvasás, módosítás, törlés, létrehozás stb.) és a funkció hatáskörét szabályozzuk (pl.
mely szervezetre, költséghelyre, partnerre stb. vonatkozik).
A jogosultságok a jogosultsági objektumokból vannak példányosítva, azáltal, hogy e
jogosultsági mezőknek egyedi értéket, intervallumokat, esetleg maszkot adunk meg
értékül, attól függően, hogy a szóban forgó felhasználó milyen feladatokkal és
felelősséggel bír ezen jogosultsági objektum kapcsán.
A különböző jogosultságokat ún. jogosultsági porfile-okba szervezzük, melyek így
már egy nagyobb funkció csoport egyedi jogosultságait fogja össze. A profile-ok
hierarchikusan egymásba szervezhetők így egyre nagyobb funkcionális terület
fedhetők le vele.
Az elemi profile-ok az szerepkör alapú jogosultság koncepció megvalósítása esetén
jogosultsági szerep-ekhez (role) rendelhetők.
A profile-ok és szerepek egymáshoz viszonyított struktúrája természetesen az adott
szituációban választott jogosultsági koncepció szerint alakulhat.
Az SAP által javasolt gyakorlat szerint a jogosultságok kidolgozása az általános
szerepkörök meg¬ha-tározásával kezdődik, és ezek a SAP jogosultság
rendszerében az ún. minta (v. referencia) szerepek létre-hozásával. A minta
szerepek már tartalmazzák az adott szerepkörhöz rendelhető SAP funkciók
(tranzakciók, menük) listáját és automatikusan behúzzák magukkal a szükséges
jogosultsági objektumokat. Ezen felül természetesen manuálisan is illeszthetünk
jogosultsági objektumokat a szerepbe.
A szerepkörök további lebontása során már az egyes minta szerepekből –
származtatás útján - egyedi szerepeket hozunk létre, melyekben az egyes
jogosultsági objektumok mezőit már konkrét értékekkel tölt-hetjük fel. Az értékek
explicit megadása helyett egyes jogosultsági mezőket ún. referencia megadásával is
feltölthetjük, pl. a szervezeti struktúra alapján. Ilyenkor a jogosultságot megkapó
konkrét felhasználó esetében a jogosultsági mező pl. a „szervezeti pozíció” alapján
meghatározott értékkel kerül feltöltésre és az adott jogosultság „hatásköre” is ez
alapján kerül meghatározásra.
132
Az értékekkel – vagy éppen referenciákkal – feltöltött jogosultságok alapján

generáljuk az egyedi szerepkörhöz 1:1 relációban hozzárendelt jogosultság profilt,
amin belül aztán generálodnak a konkrét jogosultságok is.
A szerepépítés és jogosultág profil generálás ún. SAP profile generátor segítségével
történik, mely ugyanúgy része a SAP jogosultság rendszerének.
A szerepköröket a felhasználókhoz vagy direkt módon a felhasználó adminisztráció
eszközeivel vagy indirekt módon a szervezeti struktúra alapján – pl. szervezethez
vagy pozícióhoz kötötten rendelhetünk hozzá. Ez utóbbi előnye, hogy a
felhasználónak a szervezeti hierarchiában elfoglalt helyének megváltozása esetén az
új pozícióban a rendszer hozzárendeli az ott érvényes szerepköröket, míg a régieket
elveszi.
Ábra 5-3 SAP jogosultságok és HR szervezeti hierarchia elemei
Az SAP több mint ötszáz előre gyártott szerepkört és több ezer előre gyártott profilt
szállít ki. Ezeket le lehet másolni, és fel lehet használni a saját jogosultsági rendszer
kialakításához. A kiszállított szerepek lefedik az összes modul majdnem minden
lehetséges felhasználótípusainak megfelelő szerepköröket.
A korábban ismertetet központi felhasználó adminisztráció működése szerint a
szerepek mindig az egyes CUA kliens rendszerekben kerülnek kialakításra és a
profile-t is ott generáljuk hozzájuk, azonban a CUA rendszeren központilag kerülnek
kiosztásra az egyes felhasználókhoz. A CUA nyilvántartja, hogy adott felhasználónak
melyik rendszerben, melyik szerepkör van hozzárendelve illetve a hozzárendelésnek
időbeli érvényessége is van (-tól,-ig) a központi rendszernek ehhez ismernie kell a

133
CUA kliensekben létező szerepkörök neveit, melyet egy standard program

segítségével – ütemezetten – fel is olvas miden CUA-ba bekötött rendszerből.
A központi összerendelés után a felhasználó-szerepkör reláció átszinkronizálódik a
CUA kliens rend-szerekbe, majd az „szerepkör egyeztetésnek” nevezett automatikus
folyamat révén megtörténik a releváns jogosultág profil ( azon keresztül pedig a
jogosultságok) hozzárendelése a felhasználóhoz.
A jogosultsági rendszer adminisztrációját a felhasználó adminisztrátor és a
jogosultság adminisztrátor végzik. A jogosultság adminisztrátor feladata a
jogosultságok, profilok, aktivitáscsoportok létrehozása, karbantartása.
5.2.3 Jogosultságok az SAP környezetben

Az SAP rendszerben a jogosultságok jogosultsági csoportokba vannak sorolva. Egy-
egy objektum több jogosultsági mezővel is rendelkezhet. Amennyiben ezen
mezőknek értéket adunk egy jogosultságot (megvalósulást) hozunk létre. A
jogosultság nem rendelhető közvetlenül a felhasználóhoz, csak profilon vagy
szerepen keresztül.
Ábra 5-4 Jogosultsági objektumok az SAP-ban
Az alábbi jogosultsági elemek szerepelnek egy SAP rendszerben:

• Jogosultsági mező: a legkisebb egység, amit ellenőriz a rendszer (ACTVT,
BUKRS).

134
• Jogosultsági objektum: 1..10 mező együttese, amit egyszerre ellenőriz a

rendszer (F_LFA1_APP).
• Jogosultsági objektum osztály: a jogosultsági objektumok logikai
csoportosítása (FI).
• Jogosultság: az objektum egy megvalósulása, azaz egy objektum mező
értékkel kitöltve.
• Jogosultsági profil: jogosultságok együttese
• Gyűjtőprofil: profilok együttese
• Szerepek: menüvel és a bennük levő tranzakciókhoz jogokkal felruházott
jogosultsági elem
• Gyűjtőszerepek: szerepek gyűjteménye
Ábra 5-5 Szerep, tevékenységi csoport definiálása (profile generátor) ©SAP
5.2.4 Jogosultságvizsgálat
Az SAP rendszert az használhatja, aki rendelkezik felhasználóval egy adott
mandantban, és sikeresen azonosította magát a beállított authentikációs eljárással
(eljárásokkal). Az egyes felhasználók bejelentkezéskor megkapják (az előre definiált)
135
jogosultságaikat, és az abban megadott módon férhetnek hozzá a rendszer

komponenseihez.
A jogosultsági rendszer komponensei egyrészt a programok kódjában levő
ellenőrzések, másrészt a jogosultságok, amelyeknek a meglétét ellenőrzik a
programok. A jogosultsági rendszerhez tartoznak még egyes customizing
beállítások, paraméterek, táblák, jogosultsági csoportok is.
A jogosultsági koncepció szerint az SAP jogosultsági vizsgálatokat végez, amikor a
felhasználó megkísérel végrehajtani egy programot vagy tranzakciót. A vizsgálat
során az SAP megbizonyosodik arról, hogy a felhasználó rendelkezik a megfelelő
jogosultságokkal a felhasználói törzsrekordjában, mielőtt engedélyezi a feldolgozást.
A következő jogosultsági vizsgálatokra kerülhet sor:
SAP tranzakció indítási jogosultság:
Minden alkalommal, amikor egy felhasználó elindít egy tranzakciót menüből vagy
közvetlenül, a rendszer jogosultság vizsgálatot végez az S_TCODE objektumra.
Tranzakció specifikus jogosultság:
A tranzakció indítási jogosultság mellett az SAP tranzakciók további jogosultsági
vizsgálattal lehet védeni. Egy újabb tranzakció létrehozásakor a SE93-ban
megadható egyedi jogosultsági objektumra történő vizsgálat. Ez a beállítás akkor
érdekes, ha a tranzakció védelmére elegendő egy egyedi jogosultság is.
Amennyiben nem elegendő, további vizsgálatokra van szükség, mint pl. a program
szintű jogosultság vizsgálat.
AUTHORITY-CHECK program szinten:
A program kódokban is lehet jogosultság vizsgálatot elvégezni, erre az AUTHORITY-
CHECK parancs szolgál. Ezzel a vizsgálattal a kód szintjén lehet egyedi
vizsgálatokat elvégezni, és az indirekt kódhívások (CALL TRANSACTION, SUBMIT)
is figyelhetők. Az utasításban meg kell adni a vizsgálandó jogosultsági objektumot és
a kívánt értékeket az objektum összes mezőjére. A felhasználó csak akkor hajthatja
végre az adott programot, modult, ha rendelkezik az AUTHORITY-CHECK
parancsban előírt jogosultságokkal. Az SAP programok ezt a módszert használják a
védelemre és javasolt a saját fejlesztésekben is alkalmazni.
Riport és tábla jogosultsági csoportok:
A program és tranzakció szintű vizsgálatok mellett a riportok és táblák
hozzárendelhetők ún. jogosultsági csoportokhoz. Ezzel elérhető, hogy a felhasználó
136
ugyan rendelkezik a riport futtatásához vagy a tábla hozzáféréshez szükséges

jogosultságokkal, de csak akkor érheti el ezeket, ha a megfelelő jogosultsági
csoporthoz is joga van. Az SAP a riportok esetében nem szállít ki előre definiált riport
jogosultsági csoportokat, ezeket az ügyfélnek kell definiálnia. A táblák esetében az
SAP szállít előre definiált jogosultsági csoportokat, melyekhez a standard táblák
hozzá is vannak rendelve. Ezek a csoportok és hozzárendelések a TDDAT táblában
találhatók és az S_TABU_DIS jogosultsági objektummal lehet vizsgálni a meglétüket.
A fejlesztések során az első vizsgálati lehetőség kivételével mindegyikkel dolgozni
kell. A tranzakció egyedi jogosultságvizsgálattal történő védelme csak akkor
szükséges, ha az a vizsgálat elegendő a teljes tranzakció futtatásához. Amennyiben
a kód szintjén dől el, pl. paraméterek alapján, hogy a felhasználó futtathatja-e a
kódot, akkor már nem érdemes a tranzakció szintű vizsgálat, hanem az
AUTHORITY-CHECK alkalmazása kötelező. Minden programkódot védeni kell a
megfelelő jogosultsági vizsgálatokkal, ha kell, saját jogosultsági objektumok, és
mezők létrehozásával kell bővíteni a vizsgálati lehetőségeket.
Minden új táblát érdemes, esetlegesen új jogosultsági csoporthoz rendelni. A riportok
esetében javasolt az összes (az SAP által kiszállított) riport jogosultsági csoport
hozzárendelését elvégezni, ezzel egyszerűbben lehet kezelni a riportfuttatási
jogosultságokat. (Javasolt az RSCSAUTH riport használata.)
Egyes jogosultság objektumra történő vizsgálat a SAP kernel-be épített módon kerül
végrehajtásra, azaz ABAP programból nem módosíthatók vagy nem hagyhatók el.
Ezek az objektumokra vonatkozó ellenőrzések még a tranzakció, program vagy
tábla-karbantartó elindulása előtt ellenőrzése kerülnek:
• A tranzakció indításra vonatkozó S_TCODE objektum vizsgálata
• Riport indításokat ellenőrző S_PROGRAM objektum vizsgálata
• Az RFC hívás végrehajtása esetén az S_RFC objektum vizsgálata
• Tábla-karbantartás jogosultságra vonatkozó vizsgálat az általános
táblakarbantartó eszközök használata esetén: S_TABU_DIS

137
5.3 Felhasználó azonosítás (authentikáció) és Single Sign-On

Az SAP rendszerekbe történő belépéshez minden felhasználónak érvénye
felhasználói névvel kell rendel-keznie és azonosítania kell magát a SAP
rendszereken, mielőtt bármilyen funkciót elindíthatná, vagy bár-milyen adathoz
hozzáférne. Ez egyaránt igaz akármelyik kliens-megoldást is használja a felhasználó:
SAPGui for Windows, SAPGui for HTML vagy csak egy egyszerű web-es elérést,
akár a Web AS ABAP-ra, akár a Web AS JAVA alapú rendszerre szeretne belépni.
A felhasználók rendszerbe történő belépése és azonosítása kapcsán számos
standard megoldást és integ-rációs lehetőséget kínál az SAP rendszer, melyek
közül nem egy alkalmas a felhasználók erős authentikációjának a megvalósítására.
Jelszó alapú azonosítás: A Web AS alapú rendszereken (ABAP-on és JAVA-n
egyaránt) a legegyszerűbb megoldás a SAP felhasználó törzsben tárolt jelszóval
történő azonosítás. A rendszer, a paraméterek igen széles skáláját bocsátja
rendelkezésünkre a jelszó szabályok testre szabásának, pl. :
• A jelszó minimális (és maximális) hossza
• A jelszó komplexitása: kis- és nagy-betűk, számok és speciális karakterek
minimális darabszámának előírása
• Egy adott jelszó érvényessége és jelszó történet vezetése
• A jelszóként nem megengedett szavakról szótár vezetése (USR040-es SAP
tábla)
• A jelszó egyes részeinek korlátozása
• Az SAP rendszerek jelszóképzési szabályait és bejelentkezési szabályokra
vonatkozó ajánlásait tartalmazza az alábbi lista.
• A jelszavakat legalább 60 naponként módosíttatni kell.
• A jelszavak hossza legalább 6 karakter legyen. (maximális jelszó-hosszúság
40 karakter)
• A jelszó tartalmazzon legalább 2 fajta karaktert az alábbi csoportokból:
számok, kis- és nagy betűk, speciális karakterek.
• A felhasználónév első 3 karaktere nem ismétlődhet meg a jelszóban.
• A jelszó első 3 karaktere nem lehet azonos.
• A jelszó első karaktere nem lehet '?' , vagy '!'.
• A jelszó nem lehet pass vagy sap*.

138
• Az utolsó 5 jelszó nem használható fel újra.

• sikertelen bejelentkezési kísérlet után a bejelentkezési folyamatot a rendszer
elutasítja.
• sikertelen bejelentkezés után a felhasználót a rendszer zárolja.
• Éjfélkor a sikertelen bejelentkezés miatt zárolt felhasználókat a rendszer
automatikusan feloldja.
Single Sign On authentikáció SNC-vel a telepített SAPGui for Windows klienssel, a
Web AS ABAP alapú rendszerekbe történő bejelentkezés során az egykapus
bejelentkezést a SAP által definiált Secure Network Communication (SNC) protokoll
használata mellet tudjuk megvalósítani. Ez az a protokoll, amivel a SAPGui és az
alkalmazás szerver közötti kapcsolat biztonságossá tehetjük. Az SNC használatának
előfeltétele egy a SAP által is bevizsgált biztonsági szoftveren alapuló biztonsági
környezet kialakítása. Ezen harmadik gyártó által szállított biztonsági szoftverrel
szemben elvárás, hogy támogassa az SNC által is használt GSS-APC v2 szabványt.
Egy ilyen szoftver segítségével kialakított biztonsági környezet már önmagában
biztosítja azokat authentikációs eljárásokat, amivel a SAPGui is együttműködni
képes és megvalósítható a SSO, nem csak az egyes SAP rendszerek között, hanem
akár a Wndows domain és a SAP rendszerek között is (pl. egy Kerberosz token-eken
alapuló eljárással)
X.509 alapú azonosítás, PKI intergráció A Web alapú SAP alkalmazások Secure
Socket Layer (SSL) protokoll feletti elérése esetén a kliens tanúsítvány is
használható a felhasználó azonosítására. Az authentikáció magával az SSL protokoll
segítségével történik, így ennek használata kötelező az a X.509 tanúsítvánnyal
történő belépés során. A tanúsítvány adatai alapján (Distinguished Name – DN
mező) és a Web AS ABAP felhasználó törzsébe rögzített ún. external ID alapján a
felhasználót egyértelműen azonosítani tudja rendszer, így külön jelszó megadás
nélkül hozzá férést biztosít a felhasználónak.
Egy SAP Web AS JAVA alapú rendszer esetében (mint amilyen az SAP portál) az
X.509 kliens tanusítvány alapján a SAP user-t többféle módon is azonosíthatja a
rendszer:
• a SAP user-ID és a kliens tanúsítvány manuális vagy automatikus
összerendelése (ún. user-mapping) alapján.

139
• a kliens tanúsítvány meghatározott mezőiből az UME-ban definiált szűrési

szabályok alapján határozza meg a SAP felhasználó azonosítóját.
A ún. user-ID és a tanúsítvány közötti „user-mapping” esetében a kliens tanúsítvány
a Web AS Java rend¬szer saját adatbázisában vagy egy a Web AS Java
rendszerhez kapcsolódó Active Directory Server-ben tárolható. Az első esetben a
Java környezet felhasználó-adminisztrációs szolgáltatásain keresztül (User
Management Engine – UME) tarthatjuk karban a felhasználók adatbázisban tárolt
tanúsítványait, azaz végezhetjük el a felhasználók és kliens tanúsítványok
összerendelését.
A második esetben a Java engine LDAP-on keresztül fér hozzá az ADS-ben tárolt
kliens tanúsítványhoz. A Java és az ADS között ilyenkor on-line LDAP kapcsolat
kerül kialakításra, de az ADS-ben tárolt attribútumokat nem szinkronizáljuk át a Web
AS Java-ba. (csak ún. attribútum mapping-et definiálunk a kliens tanúsítvány adatai
tartalmazó mezőkre)
A kliens tanúsítványok kezelése a SAP rendszertől függetlenül történik, melyhez
természetesen ki kell építeni a megfelelő biztonsági infrastruktúrát (ez az ún. Public
Key Infrastructure - PKI) amin keresztül például a felhasználó biztonságosan
hozzájuthat a kliens tanúsítványához, a rendszer visszavonhatja a lejárt
tanúsítványokat stb.
A kliens tanúsítvány lehet a felhasználó Pc-jén, egy chip-kártyán vagy egy központi
szerveren.
A PKI-n belül az első azonosítás tulajdonképpen már a tanúsítványhoz való
hozzáférés vagy annak használatba vétele során megtörténik, és az egy érvényes
tanúsítvánnyal rendelkező felhasználó további jelszómegadás nélkül használhatja a
PKI-ba bevont SAP rendszerek funkcióit. (természetesen a felhasználó jogosultság
ellenőrzése továbbra is SAP rendszeren belül történik)
SAP Login Ticket alapú azonosítás. Kifejezetten SAP rendszerek között egykapus
bejelentkezés számára kifejlesztett SAP specifikus authentikációs eljárás, mely a
felhasználó böngészőjében MYSAPSSO2 néven tárolt, nem-perzisztens (session)
cookie-n alapszik. A rendszerkörnyezeten belül az egyik SAP rendszer – mint ticket
kiadó – a HTTPS protokollon keresztül, egyéb eljárással sikeresen authentikáló
felhasználó böngésző session-jében elhelyez egy logon ticket-et (session cookie-t).
A cookie tartalmazza a felhasználó nevét és azt kiállító rendszer által van digitálisan
140
aláírva. Ezen cookie-val jelentkezve egy másik – ticket elfogadóként beállított –

rendszernél, az felismeri és azonosítja a kiadó rendszer digitális aláírását és a ticket-
ben tárolt felhasználó név alapján hozzáférést biztosít az elérni kívánt
szolgáltatáshoz. Mind egy Web AS ABAP mind egy Web AS JAVA alapú rendszer
ticket kiadó (ticket issuer) vagy ticket fogadó rendszer, illetve akár egyszerre
mindkettő.
A biztonság fokozása érdekében a kiadott ticket-eket védi a rendszer:
• A ticket-nek van egy érvényessége, amin túl az már nem használható fel. Ezt
az érvényességet a kiállító SAP rendszer állítja be (konfigurálható rendszer-
paraméter alapján).
• A ticket nem tárolódik a felhasználó PC-jén csak annak memóriájában, így a
browser session megszűnése után ahhoz már nem lehet hozzáférni.
• A session cookie-t a browser, csak ticket-et kiállító Web szerver DNS domain-
jével azonos domain- rendszer számára adja ki.
• A SAP rendszerek között logon ticket alapú SSO működésének az alábbi
előfeltételei vannak:
• Az minden érintett SAP rendszerben a felhasználó rendelkezik azonosítóval,
mely minden SAP rendszerben azonos.
• A felhasználó Web böngészője elfogadja a session-cookie-kat.
• A ticket kiadó és a fogadó SAP rendszerek Web szerver szolgáltatásai azonos
DNS domain-be tartoznak.
• Az érintett rendszerek óráinak szinkronizálva kell lenniük.
• A ticket kiállító rendszernek érvényes publikus és privát kulcs-párral és
publikus-kulcs tanúsítvánnyal (public-key certificate) kell rendelkezni, a logon
ticket digitális aláírása végett.
• A ticket elfogadó rendszereknek rendelkezniük kell a ticket kiállító rendszer
publikus-kulcs tanúsítványával, a digitális aláírás ellenőrzése végett.
A Logon Ticket alapú azonosítás ugyan alapvetően SAP rendszerek közötti standard
megoldás, de SAP lehetőséget ad arra, hogy más alkalmazásokat is integráljuk ebbe
az authentikációs eljárásba. Ahhoz, hogy egy nem SAP alkalmazás is ellenőrizni
tudja a session-cookie-ban tárolt logon ticket érvényességet, a SAP az ún.
SAPSSOEXT dynamic library bocsátja a gyártók rendelkezésére, mely C-ben került
megvalósításra, de rendelkezik JNI és .COM interface-ekkel is. Az SAPSSOEXT
141
egyaránt használható Java, C, C#, Visual Basic és .NET programozási nyelvekben

illetve fejlesztési környezetekből.
Továbbá az SAPSSOEXT használatához különböző Web szerverekhez bővítő
modulokat ún. Web Server filtereket is ad az SAP. A filterek segítségével e Web
szervereken futó alkalmazások – már ha maga az alkalmazás támogatja a http fejléc
váltózókon keresztüli azonosítást – is bevonhatók egy SAP Logon Ticket alapú SSO
környezetbe. Támogatott Web szerverek pl. a MS Internet Information Server,
Apache Web Server, Sun JAVA Web Server.
Az MS IIS-hez létezik egy olyan ISAP filter is – az ún. SSO22KerbMap modul – ami a
MS Windows Server 2003-ban elérhető Kerberosz implementáció, ún. „delegation”
eljárását használja ki, azért, hogy SAP Login Ticket -tel authentikált felhasználó
SSO-n keresztül hozzá férhessen különböző MS Web alapú alkalmazásokhoz, mint
pl. az Outlook Web Access.
Kerberosz 5 alapú authentikáció. Egy SAP Web AS Java rendszer esetén, a Web
browser-en keresztüli bejelentkezéshez használhatjuk a az ún. „Simple and
Protected GSS API Negotiation” eljárást vagy röviden az ”SPNego” authentikációt.
Az eljárást a Web AS JAVA ún. SPNego LoginModul-ja valósítja meg. Ez az
logon eljárás használata lehetővé teszi a Web klienseknek és a Web szervereknek a
Kerberosz authentikációs funkciók használatát, amelyek integráns részei a Microsoft
Windows 2000 és magasabb verziójú operációs rendszereknek. A Kerberosz
használható a Windows domain-en belül, ahol a Windows Domain Controller mint
Kerberosz kulcs elosztó központként (Key Distribution Center – KDC) működik.
A Web AS JAVA rendszer, az adott operációs rendszeren futó JDK-ba megvalósított
Kerberosz implemen-tációt használja.
Az kliens-szerver azonosítás főbb lépéseit az alábbi ábrán szemléltetjük:

142
Ábra 5-6 Kliens-szerver azonosítás lépései kerberos esetén
1 A Web kliens „HTTP GET” kérést intéz egy szolgáltatáshoz vagy erőforráshoz
való hozzáférés érdekében a Web AS JAVA-n.
2 Az Web AS JAVA egy 401-es (jogosulatlan hozzáférés) HTTP hibakóddal
válaszol a kliensnek és egyúttal, a HTTP fejlécben a „Negotiate” értékre beállított
„WWW-Authenticate” paraméterrel felkéri azt a SPNego azonosítási eljárás
megindítására.
3 A kliens felismeri, hogy a Web AS JAVA hoszt egy Kerberos Realm tagja és egy
kéréssel fordul a Kerberos kulcs-kiszolgáló központhoz (Key Distribution Center
– KDC), melyben egy Client/Server Session Ticket-et kér a szóban forgó Web
AS Java-hoz.
4 A megkapott Session Ticket-et a kliens SPNego token-ként becsomagolja és a
HTTP authorization header-ben elküldi a Web AS Java-nak.
5 Az SPNegoLoginModule JAVA login modul kiolvassa token-t a HTTP kérés
fejlécéből és továbbítja azt szerver oldali Kerberos implementációnak a JDK-ban.
6 Az azonosítás eredménye vagy sikeres vagy ha hibára fut, illetve a kliensnek egy
újabb kérés küldésre is szükség lehet a KDC felé.
Security Assertion Makup Language (SAML) alapú azonosítás. A Web AS JAVA
képes együttműködni és SSO-t megvalósítani külső authentikációs szolgáltatást
nyújtó rendszerekkel, melyek megvalósítják a SAML protokollt és mint ún. SAML
143
authority-k működnek. A Web AS Java illetve az itt futó alkalmazások ebben

eljárásban, mint ún. „Artiface Receiver” működik, azaz ellenőrzi a külső rendszertől, a
felhasznál adatait alapján lekért ún. „assertion ticket”-et és a benne lévő információ
alapján azonosítani a SAP felhasználót. Ha külső rendszerben használt azonosító
nem egyezik meg a SAP azonosítóval, akkor a Web AS Java login moduljába
tetszőleges felhasználó-mapping eljárás illeszthető, amely pl. a saját adatbázisban
tárolt információ vagy pl. címtár alapján végrehajtja a felhasználó összerendelését.
A fentiekben felsorolt authentikációs eljárások a standard SAP rendszer részét
képezik, megvalósításuk nem igénylik a rendszer módosítását. Egy konkrét
környezetbe (pl. PKI) történő integráció természetesen beállítást, testre-szabást
igényel. Segítségükkel többféle módon is megvalósítható a felhasználók erős
authentikációja, akár egyszerre több alternatív megoldást is megengedve a
felhasználók egy tetszőleges csoportjának.
5.3.1.1 Az SAP NW Portál Single Sing-On megoldása

Az egyes SAP rendszerek között működő egykapus bejelentkezést (SSO) a SAP
Logon Ticket alapú azonosítási eljárásával tervezzük megvalósítani. Ezen tervek
szerint a SAP Portál lesz az ún. ticket kiállító rendszer, ahol a felhasználóknak be
kell lépni a rendszerbe az egyedi SAP azonosítójukkal.
Magán a SAP portálon történő belépéshez a jelszóval történő azonosítást állítjuk be
alapértelmezetten, de – a fenti leírtak értelmében - lehetőség van más eljárás
használatára is: pl. a X.509 kliens certificate haszná-latára.
A többi SAP rendszer, mint ticket elfogadó kerül beállításra.
A Portál központú SSO-val az authentikáció és az különböző típusú front-end-eken
keresztül az egyes alkalmazások elérésre az alábbiak szerint történik. Ez
alapértelmezett eljárást mutatja be, az Ügyfélkapuval történő integrációt a következő
fejezet vázolja.

144
Ábra 5-7 Portal alapú SSO (service.sap.com)
Portál alapú SSO authentikáció SAP környezetben

0.) A felhasználó a böngészőn keresztül HTTPS protokollal felhívja az SAP Portál
bejelentkező képernyőjét.
1.) Felhasználó megadja portál bejelentkező képernyőjén az azonosításához
szükséges adatokat vagyis a felhasználónevét és a jelszót.
2.) A kapott adatok alapján a Portál, a beállított felhasználó törzsben (User
Persistence Store) ellenőrzi és azonosítja a felhasználót. A SAP Portál esetében a
User Store az előző fejezetben ismertetett, CUA rendszerként kijelölt SAP Help
Desk, azaz a Solution Manager rendszer ABAP adatbázisában van,
3.) A sikeres authentikáció után a Portal a felhasználó http/s session-je számára
előállít egy SAP logon ticket-et, ami mint ideiglenes - session - cookie tárolódik a
böngészőben. A logon ticket tartalmazza a szükséges adatokat felhasználó
azonosításához az SSO-ba bevont rendszerek számára. A Logon Ticket titkosított és
a portáltól származó digitális tanúsítvánnyal (certificate) van ellátva. (mely
alapértelmezetten 1024 bit-es DSA kódolású)
4a.) Azoknak a rendszereknek melyeket a felhasználók közvetlenül a böngészőből
érnek el, a SAP logon ticket-et a böngésző továbbítja.
4b.) A portálon keresztül elért rendszereknek (pl. portálon futó alkalmazások back-
end rendszerei) a Logon Ticket-et a portáltól kapják meg.
Az egyes SAP rendszerek a Logon Ticket-en található digitális aláírás alapján
győződnek meg arról, hogy a logon ticket valóban az adott rendszertől származik és

145
a benne szereplő felhasználói adatok hitelesek. Ha Logon Ticket érvényes és a

felhasználó a kérdéses rendszerben létezik, akkor a rendszer őt azonosított
felhasználónak tekinti. Innentől a konkrét rendszerben beállított jogosultságai által
meghatározott funkciókhoz férhet hozzá.
Az adott böngésző session megszüntetésével a session cookie - és így az ott tárol
logon ticket is - törlődik a felhasználó böngészőjéből.
A portálba történő bejelentkezés után a felhasználó egy portál adott oldalán
kialakított link-eken keresztül érheti el az egyes SAP rendszereket. Az alábbi ábra
egy olyan képernyőt mutat, ahol egy oldalon belül jelennek meg az egyes SAP
rendszerekbe történő belépést lehetővé tevő linkek.
Ábra 5-8 Példa SSO Portálra
A link-ekre kattintva, a rendszer és az elérés típusának megfelelő frontend eszköz

kerül elindításra:
• SAPGui for Windows esetén, a portál egy SAPgui shorcut-ot generál, ami
letöltődik a felhasználó gépére, ott automatikusan meghívódik rá a lokálisan
telepített SAPGui program. A shortcutban található Logon ticket információ
alapján a SAPGui azonosítja a felhasználót a SAP szerveren. A shorcut fájlba
elhelyezett logon-ticket érvényessége – alapértelmezetten - 2 perc, melynek
lejárta után a ticket-et tartalmazó short-cut fájl a SAP rendszerbe történő
belépésre már nem használható. Erre azonban nincs is szükség, mivel logon-
ticket-re és a shortcut-fájlra is csak a bejelentkezéshez van szükség, a
SAPGui session fenntartásához (és így a felhasználó munkavégzéséhez) nem

146
kell. A SAPGui session elindulása után a shortcut azonnal törlődik is a

felhasználó gépéről.
• A portál oldalon elhelyezett link-ről indítva a SAPGui tetszőleges kezdő
tranzakcióval felhívható, így pl. a hagyományos kezdő menüvel (ECC 6.0 HR
esetén pl. SMEN)
• BI rendszer MS Office-ba integrált ún. Business Explorer kliensének felhívása
során a Portál oldalon elhelyezett linkre kattintva szintén a SAPGui indul el az
előbb már ismertette módon, azzal a különbséggel, hogy az SAPGui session
megnyílásakor automatikusan meghívódik az „RRMX” tranzakció, ami rögtön
indítja az Excel alapú BEx-et, a felhasználó gépén. Az Excel elindulása után a
felhasználónak ott már nem kell külön azonosítani magát.
• Browser alapú elérés esetén - pl. a ECC 6.0 rendszerben megvalósított
Learning Solution kezdő oldalának felhívásakor az alkalmazás indító URL-jét
egy ún. BSP iview-ba foglaljuk és ez jelenik meg,a felhasználó számára, mint
aktív html link. Az azonosítás az adott SAP rendszerben a már említett,
böngészőben tárolt session cookie segítségével történik. Az alkalmazás –
BSP iview beállítástól függően – a portál kereten belül vagy egy önálló
böngésző ablakban is elindulhat.
5.3.1.2 Web AS JAVA authentikációs modulok

A SAP Web AS JAVA az ún. „Java Authentication and Authorizatin Service” (JAAS)
nyílt szabványt valósítja, a JAAS szabvány alapján a felhasználó authentikációja
több séma (technológia) szerint valósulhat meg. A szabvány négy kötelező sémát ír
elő az azt implementáló megoldások számára:
• BASIC- egyszerű user/password alapú authentikáció, mely esetben az
authentikációs adatok nyílt formában a http header-ben kerülnek átadásra az
authentikáló rendszerhez
• FORM- az alkalmazás egy bejelentkezési űrlapot generál, melyet a browser
tipikusan http POST-tal ad át
• DIGEST- a BASIC-hez hasonlatos, de a jelszó nem nyíltan, hanem hash-elve
adódik át
• CLIENT-CERT- a kliens digitális tanúsítványával azonosítja magát
147
Az első három esetben a https használata javasolt, a negyedik esetben kötelező.

A JAAS emellett lehetőséget ad egyedi sémák plug-in szerű implementálására is. Az
egyes sémákat implementáló logikákat a továbbiakban Login Moduloknak nevezzük.
A modul-ok egyszerű Java osztályok, melyek az javax.security.auth.spi.LoginModule
adott interfészt valósítják meg.
Az alábbi ábra ábrázolja a login module működését (JAVA alapú authentikáció az
SAP-ban).
Ábra 5-9 Java login modul (help.sap.com)
A login module a környezetéről (pl. a http hívás paramétereiről) callback-eken

keresztül tájékozódhat.
Az egyedi és fejlesztett login modulokat login szekvenciákba lehet rendezni. A
szekvencia nyilatkozik a login modulok végrehajtási sorrendjéről, illetve arról hogy
melyik modul authentikációja szükséges, és melyik elégséges a felhasználó végső
authentikációjához. A rendszer a szekvenciának megfelelő sorrendben meghívja az
egyes login modulokat, és kiértékeli az authentikáció eredményét. Amennyiben elér
egy sikeresen authentikáló elégséges besorolású modulhoz, és az előtte definiált
szükséges modulok authentikációja sikeres volt, a felhasználó beléptetése sikeres
volt.
Az SAP Web AS JAVA 7.0 teljes körűen megvalósítja a JAAS szabványt, és a
kötelező sémákon felül számos egyéb authentikációs sémát is biztosít (pl. fentebb
ismertette SAP LogonTicket, Kerberos, vagy SAML, stb.).
Az authentikációt nem a meghívott alkalmazás menedzseli, hanem a keretrendszer,
melyben minden alkalmazáshoz egyedi login modul szekvencia (Login Modul Stack)
rendelhető.
148
A Web AS JAVA-val természetesen jó pár előre definiált Login Modul Stack került
kiszállításra, melyek, mint template-ek használhatók a különböző saját vagy SAP
standard alkalmazásokban. Ez az architektúra egyrészt lehetővé teszi, hogy a
rendszerhez való hozzáférést több különböző – akár egymással párhuzamosan élő -
authentikációs eljárással biztosítjuk, másrész, hogy bizonyos funkciókhoz erősebb
authentikációs eljárást kössünk, mint a rendszer egészéhez.
A JAAS-nak megfelelően lehetőség van saját plug-in jellegű login modulok
megvalósítására is.
5.4 A SAP IDM architektúrája

A SAP Netweaver Identity Management (IDM) rendszer az alábbi főbb szoftver
komponensekből áll.
• Identity Center szerver
• IDM konnektorok
• Virtual Directory szerver
• SAP Identity Provider
A komponenseket az alábbi ábrán foglaltuk össze, és a következő fejezetekben
röviden ismertetjük őket.
Ábra 5-10 SAP IDM komponensei (service.sap.com)

149
5.4.1 Identity center

A IDM központi eleme az ún. Identity Center, amely:
• a központi adatbázisa és management eszköze a felhasználói azonosítóknak,
jogosultságoknak, szerepeknek, felhasználói csoportoknak
• az említett entitások terítése az IDM architektúrában a kapcsolódó
alrendszerek között (provisioning)
• a szerep vagy felhasználó igényléshez kapcsolódó engedélyezési folyamatok
kezelése (központi workflow-k)
• jelszavak kezelése.
• rendszer és audit információk naplózása
• általános célú naplózás illetve ez a központi adatforrása a BI-on alapuló
jelentéskészítésnek.
Az Identity Center gyűjti össze a különböző szerep- és felhasználó-törzsek adatai az
egyes alrendszerekből (az ún. „repository”-kból) és uniformizált formában tárolja őket
a saját adatbázisában. Szintén az Identity Center felelős azért, hogy a konszolidált
központi adatbázisból a változásokat elterjessze az alrendszerek felé, illetve figyelje
az esetleges változásokat az alrendszerekben (ha az ott megengedett).
Az Identity Center egy robusztus, nagy kapacitású központi motorja az IDM
architektúrának, mely több példányban is futatható (egy vagy több szerveren) így
nagymennyiségű adat szinkronizációjára is képes a különböző adat-források között.
Az Identity Center alapja, a központi adatbázisa, az ún. “Identity Store” (Identity
Center database), mely uniformizált módon tárolja a heterogén alrendszerekből
felolvasott adatokat (pl. alkalmazotti azonosítója, szervezeti egysége,
felhasználóneve, szerepeik, jogosultságok, csoportok)
A rendszerkörnyezetben az Identity Center adatbázisa akár Oracle RAC
infrastruktúrában kerülhet elhelyezésre.
Az adatbázis struktúrája szinte tetszőleges mértékben bővíthető - az adott feladat
vagy egyes alrendszerek igényei szerint - ügyfél specifikus mezőkkel, melyekhez
számos paraméter definiálható. E paraméterek befolyásolják a mezők, a
mezőtartalom jelentését, viselkedését: pl. időbeli érvényesség rendelhető egy
mezőnek, lehetséges értékek, láthatóság stb.
A mező-tartalmak – és nem csak a jelszavak – titkosított, kódolt formában is
tárolhatók. (pl. MD5, 3DES eljárásokkal)
150
Ábra 5-11 SAP IDM - Identity Center felépítéser
Az adatbázisban lehetőség van ún. külső attribútumokat definiálni, melyek egy külső
repository-ban létező mezőre hivatkoznak, és amely attribútumokat nem akarjuk
duplikáltan tárolni az adatbázisunkban.
Természetesen bármely attribútum vagy bármely paraméter módosítása szorosan
integrálva van az audit- és naplózó szolgáltatásokkal, így minden változás
visszakövethető, kimutatások, jelentések készíthetők róluk.
Az Identity Center “motorja” egy több komponensből álló futtató környezet, mely
magába foglalja a Java alapú Runtime Engine-t, a Dispatcher-eket, Event Agent-
eket. Ezek futtatásához a SAP Java Virtual Machine-t (SAP JVM 5.1) szállítjuk.
Ugyanez a JVM kerül telepítésre a SAP NetWeaver JAVA AS-eket futtató
szerverekre,node-okra is. A futtató környezet jól skálázható komponensekből áll,
melyekből párhuzamosan több példány is futhat (egy vagy több hoszton), köztük a
felhasználói kérések irányítását a Dispatcher-ek végzik.

151
Az adminisztrátorok és a végfelhasználók számára az Identity Center funkcióinak

elérésére a SAP portálba integrált felhasználói felület áll rendelkezésre.
A felhasználói felület funkciója rugalmasan konfigurálható, az adott felhasználó
szerepének megfelelően. A felületről alapvetően különböző típusú „taszkokat” hajt
végre a felhasználó. Egy-egy felhasználói folyamat több egyszerű elemi taszkokból
épül fel, mint pl.: feltételes taszk (conditional task), többszörös feltételes taszk (switch
task), jóváhagyási taszk, végrehajtó taszk (action task) stb.
A taszkok végrehajtásának eredményétől függően újabb taszkok indíthatók, ezek
tulajdonképpen tetszőleges módon összeláncolhatók.
A taszkok mindig az Identity Store rekordjain operálnak, úgymint a felhasználónkon,
jelszavakon, szerepeken, elemi jogosultságokon és ezek egymáshoz rendelésein.
(ún. assignment)
A fejlesztéshet és bizonyos konfigurációkhoz szükség van egy önálló “Management
Consol”-ra is, mely célra egy Windows operációs rendszert futtató munkaállomás
kerül kijelölésre.
A felhasználó az Identity Storage-ban tárolt adatok módosítását kezdeményezheti
egy előre definiált taszk végrehajtásával vagy egy háttér-folyamattal (ún. job)
Mindkettőt a runtime környezet hajtja végre. A taszkokat többnyire a felületről
indíthatjuk, de indíthatunk job-ot is innen.
Azonban a job-ok indítása általában nem a felületről történik: azt hozzákapcsolhatjuk
pl. egy adat megváltozásához valamely kapcsolt repository-ban. A repository-hoz
egy ún. event agent-et rendelünk, mely detektálja az ott végrehajtott
adatváltoztatásokat és indítja az IDM-ben a megfelelő job-ot, a változás
propagálásához.
Az Identity Center egységes és központi adatbázisával tudjuk biztosítani, hogy
felhasználó-törzs az egész infrastruktúrában egységes. Az IDM-ben definált
folyamatok lehetővé teszik a változások, változtatások előre lefektetett szabályok
szerinti ellenőrzését, azok kontrollját meghatározott személyekre kiterjedő
engedélyezési láncok kialakításával. Ez egyaránt vonatkozik a felhasználókra,
szerepekre illetve a kettő „összerendelésére” mint önálló entitásra.

152
5.4.2 Az IDM konnektorok

Egy heterogén rendszerkörnyezetben az IDM konnektorok segítségével lehetséges a
különböző gyártóktól származó felhasználói-törzs adatbázisokat az IDM
architektúrába integrálni, mint külső repository-kat, ezáltal felépítve a központi
felhasználó és szerep-adminisztrációhoz szükséges adatbázist. A normál rendszer-
adminisztráció során az IDM rendszer a konnektorok révén értesül az
alrendszerekben esetleg bekövetkező változásokról, majd ezek illetve a központilag
végrehajtott módosítások alapján a releváns információt teríti a több repository felé.
A léteznek konnektorok SAP és nem-SAP rendszerek felé, vannak rendszer-
specifikus és általános célú konnektorok és vannak melyeket a SAP vagy szoftver-
partnerei fejlesztettek.
Néhány általános célú konnektor, melye része a SAP standard megoldásnak:
• SPML (Service Provisioning Markup Language) konnektok: általános célú,

Web Service alapú konnektor olyan J2EE kompatibilis alkalmazás szerverek
felé melyek támogatják ezt a nyílt iparági szabványos protokol-t. (mint maga a
SAP NetWeaver JAVA)
• A nem SAP, de J2EE kompatibilis alkalmazás szerverre fejlesztett
megoldások esetében (EBPM) e standard konnektor használatát tervezzük,
az IDM integráció során.
• ABAP konnektor: alkalmazás (SAP) specifikus konnektor, mellyen keresztűl a
Web AS ABAP alapú rendszerekkel biztosítható teljes körű adatszinkronitás.
Ez konnektor a SAP saját, távoli-eljáráshíváson (Remote Function Call)
alapúló megoldása. Segítségével akár egyedi SAP rendszereket, akár egy
teljes SAP CUA (központi felhasználó-adminisztrációs) rendszerkörnyezetet is
integrálhatunk az IDM architektúrába. SAP rendszerek központi felhasználó-
adminisztrációs architektúrájának (CUA) bekötése során elegendő, ha csak az
ún. központi CUA rendszert kötjük ( a piros vonal a lenti ábrán) be az IDM-be,
a változások ugyanis rajta keresztül eljutnak az egyes SAP rendszerekbe
(CUA child rendszerekbe).

153
Ábra 5-12 Identity Center – CUA integráció ABAP konnektorral
• ABAP for SAP Business Suite konnektor: ez szintén egy ABAP alapú
konnektor azonban ennek segítségével nem csak felhasználó-törzshöz
közvetlenül kapcsolódó információk terítése lehetséges, hanem a SAP IDM
bizonyos üzleti objektumok (pl. üzleti partner, vállalt kód) és a hozzájuk
kapcsolódó alkalmazás szintű – de csak az adott alrendszervben releváns -
beállítások központosított kezelését is megvalósítja. A rendszer a standard
részeként számos üzleti szerepet szállít ki, melyekkel a különböző üzleti
objektumokhoz való hozzáférés közvetlenül az IDM fennhatósága alá
rendelhető. Sőt, ezen alkalmazás oldali objektumok köre bővíthető, az erre
célra szolgáló általános ABAP interface (BADI) objektum-specifikus
megvalósításával.
• MS Active Directory konnektor: Ez egy technológia konnektor mely a Microsoft
Windows Server központi címtár adatbázisához (Active Directory-jához) való
kapcsolódást valósítja meg.
• LDAP konnektor: szintén egy technológia konnektora a SAP IDM-nek,
segítségével bármely, az általános LDAP protokollon keresztül elérhető címtár
integrálhatunk az IDM architektúrába.
• Általános ASCII konnektor: ún. ASCII-file alapú felhasználó-törzsek
integrálásra alkalmas megoldás.

154
• Általános SQL DB konnektor: Technikai konnektor adatbázis alapú

felhasználó törzsek elérésére ODBC/JDBC vagy OLE DB technológiával.
A SAP IDM számára a SAP szoftver-partnerei kifejlesztettek számos, ún. gyártó
specifikus konnektort is. Ezek használatába vételéről a rendszer-környezet részletes
tervezése során tudunk dönteni. Ilyen 3rd party konnektorok:
• Konnektor MS Exchange Server 2003 vagy magasabb verziójához.
• Konnektor IBM Cognos felé – előfeltétel az IBM Cognos v8 és MS Windows
platform.
A tervezett IDM rendszeren belül a konnektorok is – az Identity Center-el együtt - a
“Runtime” környezet részét képezik, így a telepítésük, futtatásuk is az IDM
alkalmazás szervereken történik.
5.4.3 Virtual Directory Server - VDS

A SAP IDM részeként az ún. virtuális címtár (Virtual Directory Server – VDS) egy
általános, több célú, de egységes hozzáférési pontot biztosít a különböző kliens
alkalmazásoknak, akik így – a VDS-en keresztül – hozzáférhetnek az Identity Store
adataihoz és az Identitiy Center szolgáltatásaihoz.
A VDS egyrészt alkalmas a különböző repository-kon alapuló felhasználói törzs
egységes formában történő megjelenítésére – másrészt, az Identity Center felöl
érkező különböző szinkronizációs és adminisztrációs kérések leképezésére ezen
adatbázisok felé és viszont.

155
Ábra 5-13 VSD felépítése és benne a folyamat lépései
A VDS önálló, Java alapú felhasználói felülettel (1) rendelkezik, melyen keresztül a
konfiguráció és az adminisztráció is történik. A beállításokat a konfigurációs
állományok (2) tartalmazzák, melyeket a teljesítmény optimalizáció érdekében egy
konfigurálható cache-en (11) keresztül olvas be a rendszer.
A kliensek (3) a megfelelő kliens protokollon keresztül kapcsolódnak: az LDAP (4)
protokoll pl. natívan része az VDS kernelnek (6), míg ha más kliens protokoll
használata szükséges, akkor a kliens kapcsolódás az ún. „bővíthető transzformációs
keretrendszer” (5) - extensible transformation framework - segítségével történik, mely
a beérkező directory szerver kéréseket átfordítja a VDS belső formátumára.
A VDS kernel a kliensek kéréseit - a kernelen belüli feldolgozás után - a hozzá
kapcsolt adatforrásokon (9) hajtja végre, melyekhez a megfelelő protokollon
keresztüli hozzáférést az ún. konnektor keretrendszer (7) és az olyan adatforrás-
specifikus API-k (8) biztosítják, mint pl. a JDBC – adatbázis kapcsolathoz, a JNDI
(Java Naming and Directory Interface) LDAP alapú címtárak felé. Ahogy a kliens
kapcsolódási oldalán, úgy az adatforrások felé is számos különböző - nyílt iparági
szabványként elterjedt - protokollt valósítanak meg a különböző adapterek: pl. SPML,
DSML, LDAP.
A VDS kernel alapfunkcióinak– mint pl. attribútum konverziók, authentikáció,
statisztika gyűjtés – kiterjesztésére, módosítására az ügyfél által implementálható
Java class-ok állnak rendelkezésre. (“Extensible core-code functionality” (10))

156
A VDS kernel rendszernaplót (12) és audit naplót (14) is vezet és gyűjti a rendszer
működéséről a statisztikai információkat (13), melyek a Java alapú felhasználói
felületen keresztül tekinthetők meg.
Mint láthatjuk, az Identity Center-hez hasonlóan a VDS-nek is vannak beépített
konnektorai a különböző alkalmazások, címtárakhoz, felhasználó-törzsekhez felé.
Természetesen a VDS-nek magához az Identity Server-hez is van “konnektora” így
annak adatbázisán (az identity store-on) közvetlenül is végrehajthatja a kliensek felöl
érkező kéréseket, műveleteket.
A VDS, az ún. kernel szolgáltatásait - mint pl. a címtár virtualizáció, “namespace”
konverziók, attribútum és schema leképezések, attribútum érték-konverziók stb. – a
teljes rendszerkörnyezet számára Web Service-ek formájában is elérhetővé teszi.
A Virtual Directory Server az IDM architektúrában standalone módon telepíthető egy
megfelelő JAVA VM-re. (támogatott SAP JVM 5.1, SUN JVM 1.4.2, 64bit)
5.4.4 SAP Identity Provider

A SAP Identity Provider (SAP IdP), mint a 7.2-es SAP IDM megoldás része, egy
SAML 2.0 kompatibilis “azonosítás szolgáltatót” valósít meg, a 7.2-es SAP
NetWeaver Java alkalmazás szerveren, mint technológia platformon. Az IdP
segítségével a SAML 2.0 szabványnak megfelelő, SAP és nem SAP alapú
alkalmazások - azaz ún. SAML 2.0 kompatibilis szolgáltatási pontok (Service
Provider-ek) – között egy heterogén Single Sing On infrastruktúra kiépítésére van
mód.
Mind a SAP ABAP, mind a JAVA alapú alkalmazásai természetesen támogatják a
SAML 2.0-át, így ezen rendszerek Web Service szolgáltatásai – a PI-on mint Service
Bus-on keresztül is meghirdetve – kapcsolóhatók egy ilyen SSO domain-hez.
Ez egész pontosan azt jelenti, hogy egy felhasználó az ebbe a körbe tartozó
szolgáltatások igénybevételekor automatikusan egy “trusted” Identity Provider-hez
kerül átirányításra, ahol megtörténik az authentikáció. (pl. jelszó, Kerberos realm
vagy pl. X.509 tanúsítvány segítségével) A sikeres authentikációt követően a
felhasználó az IdP-től kapott, aláírt SAML 2.0 SSO tokennel (“asserton-nal”)
azonosíthatja magát az igénybe veendő szolgáltatási ponton.

157
A Service Provier és az Identity Provider között mind az ún. „front-channel” - azaz a

felhasználó browser-én keresztüli - mind „back-channel” - azaz direkt -
kommunikáció támogatott.
A Single Sign On funkció mellet a SAML 2.0 protokoll segítségével – az Identity
Provide-en keresztül – a Single Log-Out (SLO) funkció is megvalósítható, azaz,
amikor felhasználó egy konkrét alkalmazásból kijelentkezve – a IdP segítségével –
kijelentkeztetésre kerül a többi, azonos domain-be tartozó alkalmazásból.
Mindazonáltal az Identitiy Provider mint az architektúra része, lehetővé teszi, hogy
igény esetén tetszőleges, (SAP vagy nem SAP, de) a SAML 2.0-t megvalósító
“service provider” az SSO domain részévé váljon.
A másik fontos scenarió ami megvalósítható a SAML 2.0-t támogató Identity Provider
komponens segítségével, az ún. “Cross-domain Identity Federation”, azaz a
felhasználói információk domain-ek között “megosztása” és erre alapozva az SSO
infrastruktúra kiterjesztésére.
A felhasználó azonosításához a domain-ek között meg kell állapodni egy ún.
“felhasználó név-azonosítóban” (name ID-ban), ami alapján az IdP-ben és az
alkalmazásban is egyértelműen azonosítható a felhasználó. A SAML 2.0 standard
számos lehetőséget kínál ezen “name ID” megválasztására.
lehetséges Name Leírás

ID
E-mail E-mail cím.
Kerberos Kerberos Principal Name (KPN)
Persistent A name ID egy permanens azonosító „sztring”, amit az IdP
generál Service Provider-nek, vagy a Service Provider-ek egy
csoportjának.
Transient A name ID egy ideiglenes azonosító sztring, amit a IdP generál
Service Provider-nek, a biztonsági session időtartamára.
Unspecified Alkalmazás specifikus azonosító, a SAP mint Service Provider
esetében ez pl. lehet maga a felhasználó név vagy a név-alias.
Windows Name A name ID a Windows domain-ben a felhasználó neve.

158
X.509 Subject A name ID a X.509 kliens tanusítvány “subject” mezője.

Name
5.4.5 Az IDM általános szolgáltatásai

A fenti komponens-specifikus funkciókon túl, a SAP NetWeaver Identity Management
rendelkezik további olyan szolgáltatásokkal, amelyek általánosan elérhetők a
rendszerben. Ezeket foglaljuk össze az alábbiakban:
• Szinkronizáció: hattér-job-ok segítségével a rendszerben tárol összes
információ szinkronizálható a Identiy Store és a kapcsolt repository-k között.
• Web service-ek: az IDM a Virtual Directory Service-en kereszül web szerviz
alapú hozzáférést is biztosít a Identity Store adataihoz és az Identity Center
funkcióihoz.
• Jelentés készítés SAP BI alapon: a natív riport-készítő felületen túl, (ami
elérhető az Identity Center-ben,) a SAP NetWeaver Business Information
segítségével is lehet riportokat lehozni az IDM adatbázisáról, működéséről.
Ehhez a SAP BI az adatokat a VDS-en keresztül, SAP konnektor segítségével
nyeri ki a rendszerből.
• Általános kiterjeszthetőség: a SAP IDM több komponensében is lehetőséget
ad a funkciók és a gyári kiszállítású struktúrák kiterjesztésére. A SAP ilyen
„standard megoldásokat” és a speciális rendszer-rendszer kapcsolatokat
megvalósító konfigurációs csomagot, ún. provisioning frame-work-öt szállít a
rendszerhez.
Az ABAP alapú rendszerekben az ún. Business Add-In-ek révén, implementálható
interface-ek állnak rendelkezésre, pl. az alkalmazásokkal való integráció ügyfél
specifikus továbbfejlesztésére..
5.4.6 Az SAP IDM szerepek kialakításának irányelvei

Az IDM alapvetően 2 féle koncepciót támogat a felhasználók és jogosultságaik
összerendelése, kezelése kapcsán:
• Szerep-alapú kezelés (role-based provisioning)
• Szabály-alapú kezelés (rule-based provisioning)
159
Az szerep-alapú kezelés során a felhasználókhoz a jogosultságokat az ún. üzleti

szerepeken (business role) keresztül rendelhetjük hozzá.
Az üzleti szerepeket az IDM-en belül definiáljuk és velük mintegy modellezzük a
teljes SAP rendszer működési környezetét, a benne értelmezett összes folyamatot
és szereplőt figyelembe véve.
Az üzleti szerep:
általában egy létező szerep absztrakt leírása, az adott szervezet specifikus
tartalommal.
csak az Identity Center-ben érhetők el.
a szerepek hierarchiában szervezhetők, köztük öröklés, mint reláció értelmezhető.
ilyen üzleti szerep lehet pl. az „alkalmazott”.
Az IDM-en belüli jogosultságok (privileges) vagy technikai szerepek (technical roles),
az egyes alrendszereken belül létező konkrét jogosultságokat vagy rendszer-szintű
szerepeket jelenítenek meg.
technikai leírása egy konkrét rendszer üzleti szerepének.
Rendszerfüggő értelmezése/jelentése van
a technikai szerep ugyan az IDM-ben kerül létrehozása, de mindig egy a konkrét
alrendszerben létező valós szerepet/jogosultságot reprezentál.
a technikai szerepek között nincs hierarchikus kapcsolat, ilyen reláció csak közvetett
módon, a szerep-hierarchián keresztül lehetséges.
technikai szerepre példa az ABAP szerep egy konkrét SAP rendszerben, UME (user
management engine)/JAVA szerep egy NW AS Java-ban, a portal szerep, vagy egy
LDAP csoport.
A szerep alapú összerendelés megvalósítása során az üzleti szerepekhez
hozzárendeljük az összes szükséges technikai szerepet – mindegyik rendszerből
azt, ami az szerepkörnek megfelel. Pl. az „alkalmazott” mint üzleti szerephez
hozzárendelhetjük
a „login” technikai szerepet a vállalat Windows domain-jéből
az e-mail felhasználó szerepet a vállalati levelező rendszerben
„végfelhasználó” szerepet a portálon
Mint említettük, az üzleti szerepeket hierarchikus módon lehet egymáshoz rendelni,
mely egyúttal öröklési relációt is megvalósít köztük, azaz egy származtatott

160
(specifikusabb szerep) örökli a felmenő szerep technikai szerepeit. A hierarchikus

szerep-kialakításra mutat példát az alábbi ábra.
.A szerep-alapú felhasználó összerendelés szerint a felhasználókhoz az üzleti-

szerepek kerülnek kiosztásra, mely maga után vonja, hogy a technikai szerepeknek,
azaz az egyedi jogosultságok/szerepek hozzárendelését az alrendszer felhasználó
törzsében a konkrét felhasználóhoz, csoporthoz. Ez a folyamat ún. „provisioning.”
A szabály alapú kezelés során, egy konkrét üzleti szerepbe nem jól illeszthető
technikai szerep kerül közvetlenül hozzárendelésre a felhasználóhoz – ami aztán
maga után vonja az adott alrendszerben is a konkrét jogosultság kapcsolását a
felhasználóhoz. A felhasználó és a technikai szerep összerendeléseket ilyenkor
köthetjük valamilyen szabályhoz, amely teljesülése esetén hozzárendelés
automatikusan megtörténik – az IDM-ben és az alrendszerben is.
A normál üzemi környezet kialakítása során alapvetően a szerep-alapú kezelés
megvalósítása és fenntartása az elsődleges cél. A szabály alapú szerep-
hozzárendelést csak bizonyos kivételes esetek kezelésére tartjuk fenn.
A felhasználók és az üzleti szerep összerendelése, az ún.”assignment” is önálló
entitásként kerül letárolásra az Identity Store-ban, ennek köszönhetően számtalan
attribútum rendelhető hozzá, pl.
az összerendelés módja (közvetlen, automatikus, öröklés)
ki, miért, milyen okból hozta létre/szüntette meg
status információk
audit információk
érvényesség kezdete, érvényesség vége.
161
Az “érvényesség” attribútum lehetővé teszi, hogy a szerep-hozzárendelést időben

ütemezzük és bekorlátozzuk, illetve annak lejárta előtt értesítést küldjön róla a
rendszer. Pl. egy egyszerű, általános “assignment” reláció életciklusa így néz ki.
felhasználó megigényli a szerepet egy konkrét időintervallumre (”3-tól 6-ig)”. A

jóváhagyási folyamat (Validate-Add) elindul
a jóváhagyásért felelős vezető jóváhagyja a szerepigénylést.
3.-tól elindul az “Add” folyamat, mely rövid idő alatt kiosztja a szerepet/jogosultságot
az alrendszerben.
Az “Add” folyamat végétől él a jogosultsága a felhasználónak (3. és 4. között csak a
folyamat lefutásához szükséges technikai idő telik el)
N nappal a lejárati idő előtt a “Notify” taszk elindul és értesítés küld a lejáratról
A lejáratkor a “Remove” taszk elindul és elveszi a szerepet/jogosultságot a
felhasználótól
a “Remove” taszk véget ér, a jogosultság elvételre került.
Kontextus alapú szerep hozzárendelés

A fent ismertetett szerep-alapú kezelésnek egy speciális esete az ún. kontextus
alapú szerep-hozzárendelés. Ebben az esetben a személy-szerep összerendelés,
mint kapcsolathoz egy ún. kontextus – egy tetszőleges kapcsolati attribútum
rendelhető – ami rendszerint valamilyen, a kontextusból eredő módon, korlátozza a
hozzárendelt szerep hatáskörét, érvényességét.
Tipikus kontextus lehet pl. valamilyen szervezeti egységre (vagy pl. intézményre),
területi (pl. telephelyre) vonatkozó korlátozása az adott szerep-hozzárendelésnek.
A kontextusok használatával csökkenthető az üzleti szerepek összes száma, ugyanis
nem kell pl. minden „intézmény” számára egy adott szerepet létrehozni, amennyiben
pl. az intézmény kerül kontextusként meghatározása. (pl. azonos funkcionalitással
de eltérő adatkörrel rendelkező a szerepet kell létrehozni)
Az üzleti szerepekbe definiálhatunk „kontextus függő” technikai szerepeket, mely
szerepek csak a kontextus bizonyos értéke esetén rendelődnek hozzá a
162
felhasználóhoz – és így az összerendelés kontextusától függően a felhasználók

eltérő funkcionalitással is rendelkezhetnek az alrendszerben – ugyanabból az üzleti
szerepből kiindulva.
Az üzleti szerepek alá rendelt technikai szerepek esetében mindig meg kell
határozni, hogy a kontextus milyen szabály alapján legyenek leképezve az egyes
technikai szerepekre. Ha az alrendszer nem támogatja a kontextusok kezelését,
akkor ezek egyedi technikai szerepeket jelentenek, a kontextusként használt
attribútum lehetséges értékeinek számosságában, az IDM-ben és ugyanennyi egyedi
szerepet/jogosultságot az alrendszerben.
SAP IDM integrációs képességek
A komponensek általános áttekintéséből láttuk, hogy IDM rendszer igen széles körű
intergrációs lehetőségekkel bír mind a technológia szintű kapcsolatok kialakítás, mint
az alkalmazás-folyamat szintű integráció területén.
Technikai integrációnak tekintjük amikor a SAP IDM, az LDAP alapú címtár
integrációs scenario-kban egyaránt lehet:
LDAP kliens, azaz adatot tud kiolvasni, módosítani, szinkronizálni LDAP-on
keresztül. Ehhez az Identity Center vagy Virtual Directory Server LDAP
konnektorárát tudjuk használni.
LDAP szerver: azaz amikor külső rendszerek felé úgy viselkedik, mint egy LDAP
szerver és rajta keresztül hozzáférés biztosít az Identity Store-ban univerzális
formában tárolt információkhoz. Ez a VDS kernel natív LDAP támogatásán keresztül
valósul meg.
Szintén technikai integráció tekinthető a J2EE kompatibilis megoldásokkal történő
intergráció. (pl. Weblogic)
Mindkét technikai scenario-nak kitüntetett jelentősége van egy SAP
implementációban is, hiszen segítségükkel oldhatjuk meg a már létező/üzemelő
komponensek integrációját az új SAP IDM-el.
A Virtual Directory Server mint az IDM egyik komponensének jelentőségét, az SAP
implementáció szempontjából is az adja, hogy rajta keresztül valósíthatunk meg több
folyamat szintű integrációs scenariót:
a Humánerőforrás management-ért (HCM) felelős rendszerrel való integráció,
melyen keresztül a felhasználó valamint a „felhasználó-szerep összerendelés”

163
(assignment) mint IDM entitások életciklusát hozzáköthetjük az „alkalmazott” mint

HCM objektum státuszához és változásaihoz.
SAP IDM - HCM integráció

Az SAP rendszer-környezet nem tartalmazza a munka-vállalók nyilvántartásért
felelős Humánerőforrás gazdálkodási (HR) rendszert vagy modult, így az SAP-n
belül feltehetőleg nincs információ arra vonatkozólag, hogy egy felhasználók
rendelkezik-e munkaviszonnyal, vagy tagja-e az érintett szervezetnek. Azonban, ha
ezeket az információkat egy külső humán rendszerből kinyerjük az IDM számára,
akkor az egységes és minden érintett alkalmazásra/rendszerre kiterjedő eljárások,
(mely pl. a felhasználó létrehozását, eltörlését, szerepköreinek módosítását vagy
felfüggesztését jelentik) integrálhatók a releváns humán folyamatokkal (felvétel,
kilépés, szervezeti egységek közötti mozgás,stb).
Az ún. Humán Capital Management integráció – érelem szerűen – SAP HR
rendszerekkel valósítható meg legkönnyebben, mivel mind a SAP HR mind az IDM
oldalon kész eljárások állnak rendelkezésre az információ kinyerésére, továbbítására
és feldolgozására e 2 rendszer között.
A SAP HR és a IDM között a technológia kapcsolat a Virtual Directory Server saját –
nativ - LDAP típusú kernel-protokollján alapszik, azaz a humán rendszer az IDM-
nek LDAP-on keresztül adja át az alkalmazottra vonatkozó információkat,
változásokat. E standard interface más HCM rendszerek számára is elérhető és az
IDM-ben standardként kiszállított releváns folyamatok – összefoglaló nevükön az ún.
HCM integrációs framework - ebben az esetben is használhatók a felhasználó és
jogosultságainak kezelésre.
Az alapértelmezett „új dolgozó felvétele folyamat” az alábbiak szerint került
kialakításra az SAP IDM-ben, a HCM integrációs framework felhasználásával:

164
Ez már a másik integrációs scenario megvalósítását vonja, maga után, a SAP IDM –
GRC integrációt.
SAP IDM – SAP BusinessObject Access Control (Governance and Risk Analisys)
integráció
Az integráció megvalósításához az ún SAP BusinesObject Access
Control/Governance and Risk Analyis (SBOB GRC) framework kerül telepítésre a
SAP IDM-en. A framework előre definiált Identity Center taszkokat és Virtual
Directory Server konfigurációs beállításokat tartalmaz és mely lehetővé teszi, hogy
adminisztrációs folyamatokat kockázat-elemzéssel egészítsük ki, még a felhasználó
és a szerep összerendelés végrehajtása előtt.
A megoldás biztosítja, hogy a kockázat elemzés egyszerre hajtódik végre az összes
érintett cél rendszerre, amelyek a SBOB GRC hatásköre alá vannak rendelve. A
GRC által végrehajtott ellenőrzések még a jogosultságok/szerepek tényleges, fizikai
kiosztása előtt megtörténik, így a beállított szabályoknak – és üzleti igényeknek -
megfelelően a SoD (Segregation of Duties) ellenőrzések is végrehajthatók.
A standard részeként megvalósított és kiszállított folyamat látható az alábbi ábrán

165
Egy új alkalmazott belépett..A Humánerőforrás elindít egy szerep-összerendelési

folyamatot az alkalmazottra a SAP IDM felé, az új alkalmazott és vezetőjének
adatival kiegészítve.
Ennek eredményekén egy work-flow folyamat indul az IDM-ben. Az alkalmazott
vezetője további szerepeket és jogosultságokat rendel az új munkatárshoz, amelyek
a szükségesek a leendő munkaköréhez. A szerepekről és jogosultságokról a
szükséges információ elérhető a Identity Center-ben. Maguk a szerepek egészen
addig nem kerülnek tárolásra a felhasználó azonosítójával, amíg a jóváhagyási és
ellenőrzési folyamatok sikeresen véget nem értek.
A fentiek hatására tipikusan több folyamat indulhat el. Azon szerepek vagy
jogosultságok, amelyek nem igényelnek kockázat-elemzést, normál esetben a
vezetői jóváhagyást követően azonnal elosztásra kerülnének a megfelelő alrendszer
felé. Az kockázatelemzésre váró jogosultságok miatt azonban ezek a szerepek is
bevárják az elemzés eredményét (egy ún. „pendig provisioning” folyamatban)
A SAP IDM egy „Web service” hívást hajt végre a SAP BusinessObject Access
Control rendszer felé, mellyel a kockázat elemzés végrehajtását kéri. A kérés
aszinkron módon kerül feldolgozásra, így a hívó folyamat csak a kérés fogadásáról
kap visszajelzést a SBOB Access Control-tól.
A kérés a SBOB GRC input-sorában kerül tárolásra. majd lefutnak a meghatározott
SoD és megfelelőségi ellenőrzések.

166
Amennyiben az ellenőrzés kockázatot derített fel, a GRC-ben elinduló workflow

folyamat megpróbál egy felelős vezetőt találni aki jóváhagyhatja, módosíthatja a
(vagy elvetheti) a kockázatot tartalmazó kérést. Egyébként – ha a kérés nem
tartalmazott detektálható kockázatot, az elemzési folyamat automatikusan lefut a
GRC-ben.
A SAP IDM csak egy meghatározott ideig vár a kockázat elemzés válaszára, ha az
ezen időn belül nem érkezik meg, a feldolgozást sikertelennek tekinti. A feldolgozás
eredményéről egyébként szintén Web-Sevice hívás útján értesül (polling) vagy egy
esemény érkezik a GRC felöl.
A kockázat és a SoD elemzés eredményétől függően a módosítási kérés az Identity
Centerben elfogadásra vagy elutasításra kerül. Sikeres ellenőrzés esetén, a
manager által hozzárendelt szerepek és jogosultságok terítésre kerülnek az egyes
alrendszerek felé, mellyel egyúttal a felhasználó azonosítója is létrejön e
rendszerekben.
A rendszer értesítést küld a felhasználónak és/vagy manager-nek.
A folyamat természetesen módosítható és az adott igényeknek megfelelően testre
szabható.

167
SAP technológiai architektúra Integrációs lehetőségek
6 Integrációs lehetőségek
RFC, Web Service, file, ALE, konnektorok

Business Framework Architecture, Workflow, SOA, kommunikációk
6.1 Adatkinyerések
Az SAP rendszerből nyomtatott vagy elektronikus formátumban tudunk adatokat
kinyerni. Az elektronikus adatkinyerésnek az egyszerű fájl letöltést, valamint a
hálózati kapcsolatokon történő távoli rendszerbe való adatátadást értjük. Az
elektronikus adatkinyerés közvetlen módjaként meg kell említeni az SAP adatbázis
tábláinak az adatbázis-kezelő eszközeivel remote módon történő olvasását.
6.1.1 PC fájl letöltés

Az SAP rendszer bármely lista esetén felajánlja a Rendszer -> Lista menü alatt az
eredmény elmentését, SAP office dokumentumként történő továbbítását, stb. A
mentés a SAPGUI programot futtató PC lokális fájlrendszerébe menti el a listát RTF
(Reach Text Format), egyszerű ASCII vagy táblázatos formában. Ez utóbbi nem
közvetlenül MS Excel formátumot jelent, hanem tabulátorokkal történő
mezőelválasztásokkal készíti el a fájlt, amit később az Excel fel tud olvasni.
Ábra 6-1 SAP standard lista letöltés ©SAP

168
Saját programok, listák esetén lehetőségünk van arra, hogy az eredményt a kért
formátumban adja ki a program. Itt két alap kimenet lehetséges: a SAPGUI-t futtató
munkaállomás, vagy az alkalmazás szerver. Az első esetben a programot futtató PC
lokális fájlja lesz, és így nem érhető el többé másnak, a második esetben viszont
megfelelő eszközökkel mindenki (akinek joga van) elérheti. Ha Excel kimenet a
megkívánt, akkor több lehetőségünk is van. Az SAP funkciós modulok formájában
rendelkezésünkre bocsátja az eXtended eXceL (XXL) megoldásokat, melyekkel
Excel formátumban azonnal állományokat hozhatunk létre, makrókat hívhatunk, stb.
A másik módszer az ALV (ABAP List Viewer) alkalmazása. Ennek létezik egyszerű
lista változata, illetve Enjoy kontrolos változata is. A lényege, hogy nekünk csak a
tábla formátumát kell kialakítanunk az SAP felületen, majd egy gomb megnyomására
az ABAP futtató környezet elkészíti a kívánt Excel vagy akár pivot táblát.
Ábra 6-2 ALV letöltés kiválasztása©SAP
Az ábra tetjén kissé jobbra látható a „Local File... (F)” quick info, ami jelzi, hogy a
fölötte levő 4 gomb közül az egyiket kiválasztották a lista letöltéséhez. A feljövő
Popup ablak már nem látszik a screenshot-on. A „számológép”, vagyis tábla
kalkuláció választásával rögtön Excel formátumban is letölthető az eredmény, ahogy
az alábbi ábra mutatja.

169
Ábra 6-3 ALV eredmény letöltése táblázatkezelő megoldásba ©SAP
Listák készítésére ajánlott az ABAP Query rendszer, valamint a QuickViewer

megoldás. Mind a két alkalmazás lényegében programozási ismeret nélküli
listakészítést tesz lehetővé. A keletkezett listákat a „kódgenerátor” felruházza a
változatos megjelenítési, illetve mentési lehetőségekkel. Így helyet kap többek között
az ABC megjelenítés mellett az Excel is.
6.1.2 Elektronikus adatcsere rendszerek között (ALE, BAPI)

Adatok kinyerésének azt a módját, amikor két rendszert alkalmazás szinten
kapcsolunk össze az SAP az ALE (Application Link Enabling) segítségével valósítja
meg. Különböző logikai rendszereket definiálva meghatározzuk a
partnerkapcsolatokat, a kicserélendő adatokat, és az adatcserére használni kívánt
interfész típusát. Az adatok meghatározásánál lényegében IDOC (Intermediate
Document) típusokat, formátumokat határozunk meg. Az SAP az ERP rendszeren
belül is ebben a formátumban kommunikál az integrált modulok között, így az adatok
leírása a modulokhoz tartozó bizonylatfajtát határozza meg. A partnerkapcsolatban a
gyakoriságot, a tömeges adatátvitelt és további technikai adatokat határozunk meg.
Az interfész meghatározásakor több lehetőségünk van. Lehet fájl, RFC és BAPI

170
alapú interfész. (Ez utóbbi kettő hálózat alapú kommunikációról később még
olvashatunk.)
• A fájl alapú interfész az úgynevezett EDI (Electronic Data Interchange)
alrendszert használja. Az SAP az ALE interfész segítségével az alkalmazás
szerver megfelelő könyvtártában elhelyez egy ún. IDOC (Intermediate
Document) formátumú fájlt, amit átad az EDI alrendszernek. Az EDI
alrendszer az IDOC formátumú fájlt vagy konvertálatlanul elküldi a
célrendszerre, vagy valamilyen EDI szabványnak megfelelő konverziót
követően elküldi egy EDI szolgáltatónak.
• RFC alapú kommunikáció esetében az SAP az úgynevezett tranzakciónális
RFC megoldást használja. Vagyis a két rendszer RFC kapcsolatban van,
viszont az SAP gondoskodik arról, hogy az adatot egyszer biztosan átküldje.
Két SAP rendszer között ezt a megoldást szokás használni.
• BAPI alapú kapcsolatnál a BOR (Business Object Repository) objektumainak
metódusait használhatjuk fel és azok Visual C++, BASIC vagy Java-ból
történő meghívásával kommunikálunk az SAP rendszerrel.
6.1.3 Végfelhasználói funkciók

A belső felhasználók számára a rendszerben elhelyezkedő programokat általában
két nagyobb részre osztjuk: a tarnzakciók, melyekkel általában adatbevitelt és
kezelést végzünk, valamint a riportok, amik lista jelleggel jelenítenek meg nagyobb
eredményhalmazt. A tranzakciók esetében ritkán kerül sor nyomtatásra, azonban ha
igen, akkor is a trnazakciók előtérben futnak. A riportok futtatásánál a legtöbb
esetben szelekciós feltételek adhatók meg, amik szabályozzák a futást (pl. egy adott
személyügyi törzsszámra akarjuk csak futtatni a riportot). A riport indítása után a
feltételek az ún. szelekciós képernyőn adhatók meg. Egy adott feltételhalmaz
elmenthető a riporthoz ún. változatként, amit bármikor később is előhívhatunk és
használhatunk. Amikor egy riportot háttérben futtatunk, az eredmény szempontjából
fontos futtatási változatot és végrehajtási nyelvet is meghatározhatjuk. Ezzel a
háttérjob tudni fogja, hogy milyen paraméterekkel futtassa a riportot és az ereményt
mely nyelvnek megfelelően írja ki.

171
Ábra 6-4 Riport futtatása közvetlenül háttérbe, spool eredménnyel©SAP
Az ábrán látható módon a végfelhasználók eldönthetik a riportok esetében, hogy

online vagy háttérben szeretnék végrehajtani ill. megadható a kívánt változat is. A
háttérben futtatott riportok eredménye a beállításoktól függően a spoolba kerülnek
(esetleg elkészültük után azonnal nyomtatóra is kiküldésre kerülnek).
A nyomtatás a rendszerben ún. spool processzek segítségével történik oly módon,
hogy a nyomtatandó adathalmazt a processz megformázza a kiválasztott nyomtató
meghajtójának (SAP-ban eszköztípusnak) megfelelően és betárolja a spool
alrendszerbe. Amennyiben nyomtatási kérelem is keletkezik, akkor innen elküldi a
nyomtatónak (azonnal vagy később kézzel indítható módon). A rendszerben lokális,
hálózati ill. PC-hez kötött nyomtatók is definiálhatók. A kezelésükért a spool
processzek a felelősek, azonban a definíciójuk más jelleggel alakítandó ki
kommunikációs típustól függően. Definiálható ún. default front-end nyomtató is, ami
az online végfelhasználó PC-jén definiált alapértelmezett nyomtatóra küldi az
eredményt. Paraméterezéssel speciális nyomtatványokhoz beállítható külön
nyomtató (ilyen pl. az illetékszámfejtési nyomtató, vagy esetleg egy nyomtató pool)
is. Ez egyben azt is jelenti, hogy nem csak a nyomtató speciális, hanem a
customizing területen kerül definiálásra a nyomtatványhoz tartozó nyomtató. A
felhasználók jogosultság függően használhatják a nyomtatókat, ill. a felhasználói
törzsben definiálható alapértelmezett nyomtató.
6.1.4 SQL adatkinyerés

Helyi és távoli adatbázisokból többféle képpen lehet adatokat kinyerni:
• Adatbázis szintű
• Kernel szintű
• Alkalmazás szintű
172
Az alábbi ábra részletezi ezek elhelyezkedését.
Ábra 6-5 Adatbázi kapcsolati fajták
Az adatbázis táblái elérhetőek nemcsak az SAP-ból, hanem SQL interfészen

keresztül is. Két rendszer közti adatátviteli kapcsolatra szokták alkalmazni az
adatbázis linket is. Ebben az esetben az SAP tábláira olvasási jogokkal egy
adatbázis linket rakunk, aminek a segítségével más rendszerekből is láthatjuk a tábla
tartalmát. Az SAP táblákat SQL szintről nem szabad módosítani, mert ilyenkor az
adatintegritás nem biztosított. Problémát okozhat a hálózati kapcsolat megszakadása
is. Ez a megoldás nehezen nyomon követhető.
Egy másik megoldás lehet az ODBC kapcsolat kiépítése, amit speciális esetben
szintén alkalmazhatunk.
Az adatbázis szintű kapcsolatoknak hozzáférés szempontjából két fajtája ismert. Az
egyik esetben csak olvasnak az SAP adattáblákból, a másik esetben az SAP olvas
vagy ír távoli adattáblákba. Az első eset csak platform függetlenségi illetve biztonsági
szempontból kérdéses. Ugyanis így az interfészt át kell írni ha platformváltás történik,
ill. biztonsági rés, hogy egy nem az adminisztrációhoz tartozó adatbázis szintű
felhasználó SAP táblákat ér el. A második esetben, amikor az SAP olvas vagy ír
távoli táblákat Oracle esetében szinonímát szokás létrehozni az SAP adatbázis
owner környezetében. Amennyiben a régi technológiát használjuk, az ABAP EXEC-
SQL parancs segítségével elérhető a tábla. Másik lehetőség, hogy a szinoníma Z
173
vagy Y kezdetű névvel jön létre úgy, hogy az SAP Data Dictionary-ben látható legyen
a tábla struktúra. (1. létrehozzuk a megfelelő struktúrájú ABAP táblát, 2. töröljük
adatbázis szinten, 3. létrehozzuk azonos névvel a szinonímát.) Így az ABAP
programokból akár közvetlenül is elérhetők a távoli táblák Open-SQL parancsokkal.
Mindkét megoldásnak alapvető hibája, hogy a kapcsolat megszakadásával nem
kezelhető ABAP-Dump lép föl. Ez ellen nem tudunk mit tenni. Azt az esetet, amikor
külső rendszer írja az SAP táblát kihagyjuk, ugyanis ez tiltott konzisztencia és
alkalmazás szintű zárolási okokból.
Az alkalmazás szintű kapcsolatok az SAP-ból, mint alkalmazásból RFC, IDOC,
fájltranszfer segítségével küldjük, fogadjuk az adatokat. Ekkor az adatkinyerés és
feldolgozás is védett, kontrolált környezetben zajlik, hibák teljes mértékben
kezelhetők.
A kernel szintű kapcsolat igazából csak részben tartozik a kernelre, ugyanis standard
ABAP programokat írunk, ahol a távoli adatbázis elérését az adatbázis-interfész,
vagyis a kernel biztosítja a különböző adatbázis kliensek segítségével. Az új kernel-
ek tartalmaznak már mindenféle támogatott adatbázis-kezelőhöz kliens csomagot,
így pl. Linux-on futó Oracle alapú SAP is képes kommunikálni távoli MSSQL
adatbázissal. A kapcsolat leírását a DBCON tábla tartalmazza, melynek tesztelésére
az SAP az ADBC_TEST_CONNECTION riportot készítette. Javasolt a jelenleg is
üzemelő dblink technikákat ilyen formán átírni. De fontos tudni, hogy ez a megoldás
csak az SAP-ból indított query-k és módosítások esetén használható, hiszen az SAP
kapcsolatot nem adjuk meg a távoli rendszernek, csak az SAP-ban a távoli adatbázis
elérését.
Megjegyzendő, hogy az SAP a HANA side-car megoldása esetén (vagyis amikor a
standard SAP ERP mellett egy HANA platform fut gyorsításként, akkor) is ezt a
technológiát alkalmazza.
Az ABAP programokban az SQL utasításokat hasonlóan kell megírni, mint egy
standard ODBC, JDBC kapcsolat esetén.

174
6.2 Adatkommunikációk
Külön kezeljük az adatkommunikációkat, ugyanis ezek két irányúak lehetnek a
rendszerben.
Alapvetően fájlos és hálózati kommunikációkat használhatunk a rendszerben,
ugyanakkor a hálózati kommunikációnak több fajtája is lehetséges.
A kommunikációk során beszélünk szinkron és aszinkron kommunikációról. A
szinkron, amikor közvetlenül történik, az aszinkron, amikor valamikor megtörténik,
másik processzek hajtják végre. A fájl alapú kommunikáció mindig aszinkron, mégha
eseményekkel verzéreljük is. A hálózati kommunikációk esetén aszinkronitás
lehetőséget biztosít biztosabb átvitelre, mert csak akkor kommunikál ha valóban él a
kapcsolat.
6.2.1 Fájl alapú kommunikációk

ABAP programból két irányba lehet fájloks kommunikációt végrehajtani. Az egyik a
kliens oldalon, a másik a szerver oldalon történik.
A kliens oldali kommunkáció attól függően, hogy SAPGUI vagy Web felületet
használunk kicsit máshogy történik. A SAPGUI esetében maga a frontend szoftver
levizsgálja a végfelhasználói gépet és támogatást nyújt fájlok felolvasásában,
keresésében, illetve letárolásában. Ezekre az ABAP környezetben külön funkciós
elemek, illetve objektum-orientált osztályok metódusai állnak rendelkezésre.
A Web felületen (BSP illetve WebDynpro) külön UI elemeket ad az SAP, melyekkel a
le és feltöltések elvégezhetőek. Fontos azonban megjegyezni, hogy ezek a
folyamatok Internet felületre kiengedett rendszer esetén ki vannak téve
támadásoknak, vagyis ilyenkor vírus-, típus-, méret vizsgálat elengedhetetlen.
A szerver alapú kommunikáció történhet háttér futtatással is, vagyis amikor a

végfelhasználó nincs a közelben. Az SAP képes bináris, text fájlok olvasására,
írására unicode, nem-unicode, illetve definiált kódlap használatával. A fájlok kezelés
Windows esetében a SAPService<SID> user nevében zajlik, a többi operációs
rendszer esetében pedig a <sid>adm user nevében. Vagyis ügyelni kell arra, hogy a
kommunikációnál használt könyvtá illetve fájlok az SAP számára olvashatók, illetve
igény esetén írhatók legyenek.
175
Az SAP nem végez fájlrendszerbeli műveleteket, mint pl. fájl törtlés. Csak ír vagy
olvas állományokat, amikhez hozzáfér. Ugyanakkor lehetőséget biztosít operációs
rendszer szintű parancsok, programok indítására is.
6.2.2 RFC kommunikáció

Az RFC (Remote Function Call) kommunikáció az IBM által kifejlesztett CPI-C
(Common Programming Interface for Communication) alapjain nyugszik. Ez a
kommunikáció igen egyszerű, mert csak hat utasításból, funkcióból áll:
• Kapcsolat kiépítése:
o CMINIT: inicializálja a kapcsolatot kommunikációs paraméterekkel, amit
az ún. side information táblából nyer
o CMALLC: Allokálja a beszélgetésre a csatornát, vagyis kiépít egy
logikai kapcsolatot
o CMACCP: A másik oldal elfogadja a beszélgetési igényt, és elküldi a
kezdési kérelmet
• Kommunikáció:
o CMSEND: Üzenet küldése
o CMRCV: Üzenet fogadása (státusz üzenettel együtt)
• Kapcsolat bontása:
o CMDEAL: Csatorna és beszélgetés befejezése
Szerencsére az SAP rendszerekben nem kell C szintű kódokat írnunk ezen

kommunikációk kiépírésére, csak ún. RFC célokat kell meghatározzunk ahhoz, hogy
egy RFC szerverrel kommunikálni tudjunk.

176
Ábra 6-6 RFC hívási lehetőségek (service.sap.com)
Ahogyaz ábra is mutatja egy SAP rendszer nem csak RFC kliens, hanem szerver is
lehet. Legegyszerűbb ezt elképzelni ha van egy HR emberi erőforrás, bérszámfejtési)
és egy FI (pénzügyi és kontrolling) rendszerünk. Ezek kommunikálnak, mert az FI
rendszernek le kell adnia a költséghelyeket, a HR rendszernek meg fel kell adnia a
fizetések utalási információit, valamint a költséghely terheléseket.
Az ábra ugyanakkor azt is szemlélteti, hogy igen régi, de még néhol, nagy
vállalatoknál ma is fellelhető R/2-es, mainframe rendszerrel is tudunk kommunikálni,
vagy akár egy nem SAP programmal, rendszerrel.

177
Ábra 6-7 RFC cél megadása (SM59) ©SAP
A fenti ábra egy másik SAP rendszerbeli célt határoz meg. Az alábbi ábra viszont
egy tesz függvény hívását a távoli rendszerből.
Ábra 6-8 RFC függvény teszt hívása RFC célon ©SAP

178
Ábra 6-9 RFC főggvény meghívási eredménye (3 szerver) ©SAP
Ábra 6-10 RFC meghívási eredmény megjelenítése ©SAP
A külső rendszerekhez történő kapcsolódás elősegítésére az SAP lehetőséget

biztosít ún. konnektorok használatára. Az SAP számos konnektort
(http://service.sap.com/connectors) bocsát az ügyfelek, partnerek rendelkezésére,
melyek segítségével az SAP rendszerekből, illetve rendszerekbe adatokat
továbbíthatnak. Ezen konnektorok legtöbbje RFC, BAPI hívásokra képes felületet ad
a programozónak, illetve felhasználónak. Alapvetően egy RFC library, amit felkínál
(féleg C/C++ fejlesztőknek), azonban Java környezetre kifejlesztette a Java
Connectort, vagy JCo-t, amit belsőleg is használ a rendszerben (ABAP-Java
kapcsolatnál például). Ezek mellett ki kell emelni a legifjabbikat, a .NET Connector-t.

179
Az SAP .NET Connector egy programozási környezet a Visual Studio .NET

belsejében, mely lehetővé teszi a kommunikációt SAP rendszerek és a Microsoft
.NET platform között. Támogatja az RFC (Remote Function Call) hívásokat és Web
szervizek használatát, ezzel különböző alkalmazások, Web formok, Windows formok
és konzol alkalmazások írását teszi lehetővé. Használhatók a Common Language
Runtime (CLR) programozási nyelvek, úgy mint a Visual Basic .NET, C# vagy a
Managed C++.
Az alábbi ábra szemlélteti a működési logikát:
Ábra 6-11 SAP .NET connector (scn.sap.com)
Egy másik kapcsolódási pont az SAP-ból történő levelezés, FAX küldés. Az SAP
alapvetően két lehetőséget biztosít arra, hogy a rendszerben levő ún. SAPoffice
környezet a vállalat általános levelező rendszeréhez lehessen kötni. Az egyik
megoldás az SAP alkalmazásszervereken beállítható SMTP alkalmazása, a másik
az SAP Exchange Connector bevezetése.
Ez a konnektor lehetővé teszi, hogy a felhasználók SAP-s alkalmazásokból vagy a
SAPoffice-ból dokumentumokat küldjenek, vagy fogadjanak egy a rendszerrel
összekötött MS Exchange Szerver postafiókjából. A felhasználóknak arra is van
lehetőségük a konnektor segítségével, hogy dokumentumokat váltsanak az MS
Exchange szerver segítségével pl. Internet, fax, X.400 vonalakon. Csatolt fájlok (pl.
R/3 dokumentumok, MS Office dokumentumok, fax bitmap) szintén mindkét irányba
továbbíthatók.
Az alábbi ábra szemlélteti a konnektor alapvető elhelyezkedését:

180
Ábra 6-12 SAP Exchange Connector (scn.sap.com)
Amint az ábrán látható, az SAP a külső levelező, FAX továbbító, stb. rendszerekkel a
SAPconnect felületen keresztül biztosítja a kapcsolatot. Ez a komponens az SAP
rendszer standard módon kiszállított része. Third-party megoldásokkal lehet külső
rendszereket az SAP-hoz kapcsolni. Az Exchange Connector esetében az SAP
készítette a SAPconnect-nek megfelelő kommunikációs felületet, nem a partner
(Microsoft).
A mai verziók esetében nem kell már külön speciális levelezési konnektort kiépíteni,
mert működik közvetlenül az SAP-ból is.
6.2.3 BAPI és IDOC

Az SAP üzleti objektumokkal dolgozik, azonban ezeket táblákban tárolja, funkciós
építőkockákkal (funkciós modulokkal) kezeli és tranzakciókat készít hozzájuk. Ez a
technikai megvalósulás nem praktikus alkalmazás oldalról, mert ott ténylegesen
üzleti objektumokat, pl. számla, alkalmazott, stb. kell kezelni. Ezért az SAP
kialakította az ún. Business Framework Architecture (BFA) megoldását.

181
Ábra 6-13 SAP Business Framework Architektúra
A logikai modell az alábbi ábrán látható főbb elemekből áll. Az üzleti objektumokat
(Business Object) a repository-ban kapnak helyet, ahol kereshetők, komponenseik
elemezhető és elolvasható a dokumentáció is róluk.
Az üzleti Objektumok a standard táblákra, tranzakciókra épülve egy újabb réteget
képeznek, azonban objektum-orientált szemlélettel. Így minden üzleti objektumnak
vannak többek között attribútumai és metódusai is. A metódusok közül azok, melyek
az SAP rendszeren kívülről is meghívhatók, azok a BAPI-k.

182
Ábra 6-14 BAF részei: BOR, BO, BAPI
A BAPI-k technikailag RFC képes funkciós elemekként vannak megvalósítva, így

akár RFC-ként is hívhatók külső rendszerbenől, de lehetőség van az objektum
környezet felépítésére és a közvetlen metódus hívásra is.
A BAPI-k hívásához, kezeléséhez tartozik az IDoc-ok használata is. Alapvetően az

SAP kialakította a fenti ábra jobb felső sarkában is látható ALE (Application Link
Enabling) technológiát, ami lazán csatolt, üzenet alapú, alkalmazás szintű
kapcsolatot jelent a rendszerek között. Egyszerűbben ez azt jelenti, hogy üzeneteket
(mint pl. anyagtörzs, számla) közvetítenek egymás közt a partner rendszerek (pl.
SAP mandantok). Azért laza a kapcsolat, mert csak a partner kapcsolatban derül ki a
valós technológia (RFC, BAPI, fájl, WebService...) és aszinkron módon működik. Az
RFC-k (és BAPI-k) esetén ún. tranzakcionális RFC-t használ a rendszer, ami
biztosítja, hogy az üzenet csak egyszer menjen át a fogadó oldalra.
Az üzenetek megvalósulásai verzió függőek. Ezeket a tényleges üzeneteket
nevezzük IDoc-nak, vagyis Intermediate Document-nek. A partnerkapcsolatban
határozható meg, hogy melyik IDOC verziót használják a rendszerek. Erre azért van
szükség pl., mert a régebbi rendszerek nem ismerik az újabb adattartalmakat.

183
6.2.4 WebService-ek
Az SAP egy standardizált architektúrát és számos eszközt kínál Web szolgáltatások
készítésére, hívására. Ez magába foglalja az SAP NW Developer Studio-t és az
ABAP Workbench-et is. Lényegében azt jelenti, hogy minimális erőfeszítéssel
kínálhatók Web szolgáltatások SAP rendszerekből. Meglevő BAPI-k, remote képes
funkciós modulok, Enterprise Java Bean-ek (EJB-k), Java osztályok és SAP XI
szerver proxy-k használhatók Web szolgáltatások beállításához.
Az SAP WebAS implementálta a Web szolgáltatásokhoz szükséges alap
standardokat, mint pl. XML, SOAP, WSDL és UDDI. Az ABAP Workbench kínál
eszközöket web szolgáltatások publikálására, keresésére és felhívására is. Így az
SAP megoldások működhetnek szerverként és kliensként is a web szolgáltatások
használatakor.
Fontos, hogy az RFC és a BAPI-kat technikailag leképező remote funkciókhoz
közvetlenül is lehet WSDL állományt generálni. Ekkor csak a standard authentikáció
működik. Ha többet szeretnénk, vagy nem is RFC képes funkcionalitást szeretnénk
kiajánlani, akkor arra fejleszteni kell burkoló környezetet. Erre az ABAP Workbench
esetén az Object Navigator ad lehetőséget. Ugyanakkor a SOAMANGER használata
is szükséges.
Ábra 6-15 SAP SOAMANAGER tranzakció (Web alkalmazás) ©SAP

184
Az alkalmazásban nem csak a kiajánlandó WebService-ket kell felvenni, hanem a

használni kívánt távoli Web szolgáltatások külső konfigurációja is itt történik. Amint
lehetőség van a technikai elérésükre, az Object Navigator segítségével ún. Proxy
Class-t kell készíteni, aminek a metódusai a Web szolgáltatás egyes funkciói
lesznek.
Ábra 6-16 WebService Proxy generálás©SAP
Az SAP legenerálja a szükséges adatszótár elemeket is (pl. tábla típus, struktúrák,

stb.).
6.3 SAP Process Integration, Process Orchestration

Az SAP már régóta felmérte, hogy az interfészeknek nagy szerepe van az
implementációk során. Kifejezetten akkor kerül elő ez a kérdés, amikor heterogén,
vagyis több szállítótól érkező termékeket használ és azokat kell integrálni.
Természetesen erre a piaci szegmensre is elkészítette saját szoftverét, amit több
lépcsős fejlesztés után kínál ügyfeleinek.
A technológiai interfész központ neve az évek során változott, funkcionalitása bővült.
Alapvetpen a következő szolgáltatásokat nyújtják az egyes követő termékek:

185
• SAP Exchange Infrastructure (XI): EAI (Enterprise Applivation Integration),

vagyis interfész központ (adat kommunikáció)
• SAP Proccess Integration (PI): EAI és ESB (Enterprise Service Bus), vagyis
szolgáltatási központ is, ami kínálja és regisztrálja a lehetséges (web)
szolgáltatásokat (nem csak adat, hanem funkció „kommunikáció”)
• SAP Process Orchestration (PO): EAI, ESB és BPM (Business Process
Management), vagyis máf folyamat vezérlés is van
Az SAP itt az XI és PI után már a PO, vagyis Process Orchestration termékét
javasolja. Ennek több oka van:
• A PI alapvetően kommunikációs központként szolgál alkalmazások között.
Ezen felül lehetőséget biztosít Enterprise Service Repository (ESR)
felépítésére, ami lehetővé teszi a szolgáltatások használatát is.
• A PO ugyanakkor az adatcseréket vezényli, koordinálja és felügyeli a
szolgáltatásokat, adatkapcsolatokat és az alkalmazásokat automatizált
környezetben.
• A PO egyben tartalmazza a middleware technikát (PI), a folyamatok kezelését
(BPM, Business Process Management) és a szabályok definiálási és
használati lehetőségét (BRM, Business Rule Management).
Az EAI rendszerek alapvetően fájlos kapcsolatokat (FTP, vagy könyvtár
használatával) mindig felkínálnak, valamint Web Service protokolokat és JDBC alapú
adatbázis kapcsolatokat, mint standard funkciók. SAP PI és PO számos egyéb
kapcsolatot kínálnak, azonban a két környezet közt alapvető különbség, hogy az
SAP PI ún. dual-stack installáció, vagyis ABAP és J2EE motorral is rendelkezik, az
SAP PO viszont már csak J2EE alapon működik. Így az adapterek, amiket az ABAP
Integration Broker kínált fel korábban (XI, PI), az már a az új verzióban (PO) a J2EE
környezetben jelenik meg. Rövid lista a standard adapterekről, melyek lényegében
az AAE (Advanced Adapter Engine) szolgáltatásai:
• RFC Adapter
• SAP Business Connector Adapter
• File/FTP Adapter
• JDBC Adapter
• JMS Adapter
• SOAP Adapter
186
• Marketplace Adapter
• Mail Adapter
• RNIF Adapter
• CDIX Adapter
• IDoc Adapter (Advanced Adapter Engine)
• HTTP Adapter (Advanced Adapter Engine)
Amint látható több lehetőségünk is van a kapcsolódó rendszerek adat szintű
összeköttetésére. Amennyiben standar módon támogatja valamely kapcsolódó
rendszer a fenti adapterek által nyújtott protokolokat, lehetőség nyílik azok
használatára további speciális adapterek vásárlása nélkül. Ennek megfelelően a
nem-SAP rendszerek esetén a File/FTP, JDBC (adatbázis szintű kapcsolatokhoz),
SOAP (Web Service kommunikációkhoz) adatpterek használata a legelőnyösebb.
Alábbi lista az esetlegesen fellépő fejlesztési igényeket csoportosítja:
• Küldő oldalon: standardizálás (standard funkciók, adatkinyerők, protokolok
használata), adat „szélesítés” (általánosítás)
• Fogadó oldalon: meglevő interfészek átalakítása ha nem használható, vagy
költséges a protokolja
• EAI rendszerben: speciális konvertáló, szűrő, map-pelő rutinok készítése.
• A fenti felsorolásban nem szerepel az SAP, ugyanis nem feltétlen vesz részt
minden kommunikációban, lehet, hogy két nem-SAP rendszer kapcsolata is
az EAI környezetbe kerül.
A fent említett PI alapú AAE a PO esetében további kiterjesztésre kerül biztosítva a
lehetőséget, hogy akát külön komponensként is futhasson, tartalmazva saját
környezet leírást, szolgáltatási könyvtárat, felhasználó kezelést, monitorozást, stb.
Történetileg az XI ill. PI dual-stack megoldások ABAP része tartalmazta egy részét
az adaptereknek, pl. IDOC, RFC, WSRM (Web Service Reliable Messaging). A Java
oldalon található adaptereket az ún. Adapter Engine (AE) szolgáltatta. Később,
lényegében a PI létrejöttével a Java környezetre húzták át az alap adaptereket,
amihez fejleszteni kellett az adaptermotort, így előállt a már korábban is említett
Advanced Adapter Engine (AAE). A PI 7.11 verziótól lehetőség van Java-only
installációra, ahol az AAE szolgáltat minden kapcsolati protokolt. A PI 7.31 verziótól
kezdve tovább bővítették az adapterkezelőt a fent leírt funkciókkal és így már az
Advanced Adapter Engine Extended (AEX) technológia áll rendelkezésünkre. Ez
187
kapcsolatok és üzenetkezelés szempontjából ugyanazt nyújtja, mint az AAE,

azonban külön is életképes, hiszen rendelkezik minden alap funkcióval, többek
között:
• Saját SLD (System Landscape Directory),
• Saját Integration Directory,
• ESR (Enterprise Service Repository),
• Monitoring,
• User management (UME).
Azonban az AEX nem kínál folyamat integrációt, ugyanis a dual-stack világban ez az
ABAP oldalon fut (Cross Component BPM, ccBPM). A Java-only megvalósításhoz
ezér az SAP a PO-t ajánlja, ahol a NW BPM veszi át ezt a szerepet. (Hasonlóan az
ABAP oldalon már régóta és a Business Rul Framework, amit a dual-stack installáció
használ is, viszont Java-only megoldásnál a NW BRM technika áll
rendelkezésünkre.)
Bár az SAP nem tervezi a PI dual-stack megoldás támogatásának megszakítását
2020 előtt, azonban az újabb feature-öket a Java környezetben hozza ki, így
érdemes a Java-only megoldást implementálni.
Az SAP PI az alábbi, nyílt szabványokkal támogatott képességekkel rendelkezik

• SOA
o Az Enterprise Services Repository (ES Repository) top-down
megközelítésű szolgáltatás-orientált alkalmazás-fejlesztést tesz
lehetővé. A Repository segítségével minden, az alkalmazások
integrálásához szükséges információ (szolgáltatások, műveletek,
interfészek, adattípusok, transzformációs programok) egy központi
helyen tartható karban. A Repository a metaadatokat a SOA nyílt
szabványainak felhasználásával reprezentálja (XML, XSD, WSDL, stb.)
o A Services Registry az UDDI 3.0 szabvány alapján lehetővé teszi a
szolgáltatások regisztrációját, keresését, és fogyasztását, így fontos
megvalósító eleme a szolgáltatás-újrafelhasználás alapelvének
• Folyamat automatizálás
o A Business Process Engine (BPE) komponens lehetővé teszi önálló,
automatizált folyamatok futtatását a PI környezetben, mely többféle
188
mintázat (pl. üzenetek gyűjtése, vagy szétosztása, szinkron/aszinkron

konverzió) megvalósítását biztosítja. A folyamatleírások BPEL4WS 1.1
és WS-BPEL 2.0 szabványokon alapulva az ES Repositoryban
hozhatók létre.
• Service Bus
o A Service Bus legfontosabb eleme az Integration Server, mely az
alkalmazások közötti üzenetcsere központi vezérlője. Az Integration
Server a küldő rendszerektől érkező üzeneteket a beállított komplex
kritériumok (pl. az üzenet egyes elemeinek értéke) alapján továbbítja a
fogadó rendszerek felé. Mind a küldés mind a fogadás történhet
szinkron vagy aszinkron módon. Az üzenettovábbítási szabályok az
Integration Directory-ban, konfigurációval állíthatók be. A küldő
rendszer által használt üzenettípus többfajta transzformációs
technológia (grafikus, Java, XSLT, ABAP) felhasználásával a fogadó
rendszerek által elvárt üzenettípusra konvertálható.
o Az Advanced Adapter Engine az Integration Engine-nel együttműködve
teszi lehetővé, hogy a különböző kommunikációs technológiával
rendelkező rendszerek üzenetet tudjanak cserélni. Az Adapter Engine a
J2EE Connector Architecture szabványnak megfelelően számos
adapter felhasználását teszi lehetővé. A PI az alábbi főbb
adaptertípusokkal kerül kiszállításra:
o Idoc (SAP Intermediate DOCument), RFC (Remote Function Call)
o SOAP (Web Services hívásokhoz)
o File (FTP és filerendszer)
o JMS
o JDBC
o Email
o A fentieken felül számos szofverszállító kínál további adaptereket
o Az adapterek nagy részének funkcionalitása saját fejlesztésű Java
modulokkal bővíthető, vagy módosítható.
o Az adapterek segítségével környezetünk SOA képessége jelentősen
megnövelhető, hiszen nem SOA képes alkalmazásain funkcionalitását
a PI felületén szolgáltatásként kiajánlhatjuk. A PI-on meghívott
189
szolgáltatás-hívást a PI a háttérrendszer felé, az az által is értelmezett

protokollon keresztül továbbítja (pl. JDBC, JMS, file). Hasonlóképpen a
PI lehetővé teszi, hogy egy nem SOA képes rendszer a PI-on keresztül
webszolgáltatásokat hívjon meg. A szolgáltatások WS-Security
használatával titkosíthatók, illetve digitálisan aláírhatók,
o Reliable Messaging: a Service Bus biztosítja, hogy az üzenetek mindig
az elvárt szolgáltatási szintnek (Quality of Services) megfelelően érjék
el a célrendszereket. Az adatkonzisztencia biztosítására (pl. többszörös
üzenetküldés elkerülésére) a PI az Exactly Once (EO), Exactly Once In
Order (EOIO), és Best Effort (BE) szinteket támogatja.
• Infrastruktúra szolgáltatások
o A PI infrastruktúra szolgáltatásai magukban foglalják a szoftver-
életciklus kezelést, a magas rendelkezésre állást, a skálázhatóságot, a
felhasználókezelést, az üzenetarchiválást, a konfigurációs felületeket, a
monitorozást, és adminisztrációs eszközöket.
Folyamat- Folyamat
automatizálás monitoring
Service Bus
Dynamic Routing Transzformáció Konnektivitás
Reliable Messaging
Infrastruktúra JEE5 / ABAP
Software Lifecycle Skálázhatóság Konfiguráció

Biztonság High Availability Monitoring
User Management Archiválás Adminisztráció
Process Integration
3rd Party 3rd Party

SAP Alkalmazás Middleware
Ábra 6-17 SAP PI sematikus felépítése (service.sap.com)

© SAP AG 2007, SAP TechEd ’07 / SOA100 / 11

190
A megoldásban az SAP PI becsomagolja a belső web szolgáltatásokat ezzel

biztosítva egységes felületet a külső interfészek számára, valamint a belső
különböző rendszerkomponensek között is a szolgáltatás repository adja meg a
lehetséges adatkinyerési, adatátviteli szinteket szabványos interfészeken keresztül.
Az SAP PI rendszer biztosítja a mintaalkalmazást, amin keresztül az elektronikus
adatcsere kapcsolatok, mint integrációs pontok tesztelhetők a külső kapcsolódó
rendszerek számára.
6.4 SAP HelpDesk

SAP ügyfeleinek számos szolgáltatási szintet és azon belül különböző
szolgáltatásokat nyújt. Alábbiakban kifejezetten az SAP Helpdesk funkcióval
foglalkozunk, ami része már a legalacsonyabb, ún. SAP Standard Support
szolgáltatási szintnek.
A SAP Standard Support keretében az alábbi szolgáltatások érhetők el:
• Folyamatos javítás és újítás (szoftverek bővítő és javító csomagjainak
fejlesztése és kiszállítása, valamint tudásbázis használata SAP OSS Notes)
• Üzenet kezelés (HelpDesk)
• Távoli szolgáltatások (Ún. OSS kapcsolatot igényel (lásd később), évenként
egy installációhoz egy ún. GoingLive Check vizsgálatot tartalmaz, ami lehet
bevezetési, verzióváltási és más jellegű GLC. Ezen felül ún. EarlyWatch Alert
(EWA) riportok készítése a rendszer technikai performanciáját vizsgálva.
Évenként két EarlyWatch szolgáltatás igényelhető a támogatás keretében ,
amennyiben az EWA riportok nagyobb hibát jeleznek.)
• SAP Solution Manager használata támogatás keretében (alapvetően a
helyileg elhelyezkedő SAP Solution Manager rendszer szolgáltat performancia
javító információkat a rendszerekből gyűjtött statisztikai adatok alapján.
Amennyiben lehetőség van SAP távoli kapcsolat kiépítésére, ezeket az
adatokat el is küldi az SAP AGS (Active Global Support) szakembereinek, akik
részletesebb és pontosabb információkat tudnak nyújtani.)
Az SAP HelpDesk funkció elérhető web felületen az Internet-en az SAP Service
marketplace portalján http://service.sap.com/message. Ezen a felületen lehet
hibajegyeket, üzeneteket feladni az SAP-nak. megfelelő konfiguráció segítségével a
191
hibajegy előrehaladásáról e-mail értesítés kapható. A beküldött üzenetek egy belső

tudásbázisba kerülnek, aminek a segítségével további javítások, bővítések
végezhetők a termékeken. Az üzenet prioritása szerint reagálnak a munkatársak. 1.
prioritású üzenetet csak produktív rendszer meghibásodása esetén lehet feladni,
ugyanakkor ezen üzeneteket 7x24 órában dolgozza fel a support szervezet.
Magasabb szintű támogatás érhető el az ún. SAP OSS (Online Support Service)
kapcsolat kiépítésével. Ez a kapcsolat egy akát VPN alapú direkt kapcsolat az SAP
support szervezetéhez a rendszereink felől A kapcsolat csak akkor él, ha belülről,
ügyfél oldalról megnyitják a kapcsolatot, ill. egy vaga több rendszer számára
kapcsolatot engedélyeznek limitált időre. Amennyiben ez a fizikai kapcsolat létrejön,
szükség van még a vizsgálandó rendszerbe ideiglenes támogató felhasználóra. A
támogató kolléga csak ebben az esetben képes belépni a vizsgálandó rendszerbe.
Az SAP kollégák csak vizsgálatot végezhetnek, nem módosíthatnak, nem állíthatnak
be semmit az ügyfél rendszerében, még kérésre sem.
Ábra 6-18 SAP OSS fizikai kapcsolat (service.sap.com)
A fizikai kapcsolat kialakítására számos lehetőség kínálkozik. Az ábrán a mai

technológia mellet a legkorszerűbb, ugyanakkor biztonságos VPN alapú megoldást
javasoljuk. Amint látható IPsec képes router-re van szükség, valamint két külső IP
címre (egy a csatornához, egy pedig magának az ügyfél oldalon elelyezkedő SAP
Router host-nak) és a SAP AG kollégákkal történő egyeztetés után üzembe
helyezhető. Természetesen az üzemeltető csapatnak kell megnyitnia belső kérelem
alapján az SAP-s rendszer kapcsolatokat. Biztonsági megfontolásból érdemes a

192
fizikai kapcsolatot is csak addig nyitva tartani, amíg az SAP szintű kapcsolat nyitva
van a környezetben.

193
SAP technológiai architektúra Általános adminisztráció
7 Általános adminisztráció
7.1 Általános ABAP rendszerüzemeltetés

Ebben a fejezetben a WebAS ABAP alapú rendszerek általános
rendszeradminisztrációját tárgyaljuk. Ebben a fejezetben tárgyaljuk az operációs-
rendszer és adatbázis releváns feladatokat is.
7.1.1 Áttekintés
Annak érdekében, hogy az installált SAP rendszerek minél megbízhatóbban, minél
jobb teljesítményt nyújtva tudjanak működni, az üzemeltető személyzetnek az adott
rendszer típusától függő gyakorisággal bizonyos napi, heti, havi és eseti analíziseket
kell a rendszerben elvégezni. Ezek a rendszeres analízisek lehetővé teszik, hogy a
rendszerben bizonyos problémák kiteljesedése az időben történő beavatkozás
következtében megakadályozásra kerüljön. Ezt a vizsgálatot támogatja az SAP
Solution Manager rendszer, mely lehetővé teszi a központi rendszermonitorozást,
valamint az EWA (Early Watch Alert) riportok kezelését is.
Különösen a rendszer teljesítménye tekintetében előfordul azonban olyan eset,
amikor a rendszeresen végzett analízisek ellenére is drasztikus teljesítményromlás
következik be. Ebben az esetben a napi analízisek jelentősége fokozottabban
megnövekszik, mivel a hangolással járó paramétermódosítások rendszerre gyakorolt
hatását nagyon pontosan és precízen rögzíteni kell.
Az analízisek az alábbi főbb területekre bomlanak:
• Operációs rendszer és hálózat
• Adatbázis kezelő
• SAP rendszer
Az analíziseket a fenti területeknek megfelelő elemző lépéseket tartalmazó ellenőrző
listák alapján érdemes elkészíteni.
Célszerű ezeket az analíziseket elektronikus formában tárolni és egy megfelelő
elévülési időt figyelembe véve, ezeket törölni. Abban az esetben, ha az analízisekből
egy, a rendszer későbbi üzemeltetése számára tanulságos esettanulmányt lehet
összeállítani, akkor azt célszerű egy külön tároló helyen tartani és az elévülési időn
túl is megtartani.
194
7.1.2 Napi feladatok

Az analíziseket a feladatokhoz rendelt személyzetnek kell rendszerenként megadott
gyakorisággal elvégeznie.
A napi analízisek végrehajtását az alábbi típusú feladatokra kell szétbontani:
• Operációs rendszer vizsgálatok
• Hálózati vizsgálatok
• Adatbázis kezelő vizsgálatok
• SAP rendszer vizsgálatok
Az Adminisztrációs asszisztens (SSAA, SAPP System Administration Assistant)

továbbra is rendelkezésre áll az ABAP rendszerekben. Az adminisztrációs
feladatokat napi, heti, havi és nem tervezett feladatok szerint rendezi fa struktúrába
rendszerenként. Amennyiben a funkciót központilag használják, egy helyen
végezhető az adminisztráció. Az asszisztenst arra tervezték, hogy összegyűjtse,
központosítsa az adminisztrációs feladatokat és logikailag, valamint gyakoriság
szerint rendezze azokat. Mindazonáltal nem fed le minden feladatot, hanem a
legfontosabb és leggyakrabban használt feladatokat szándékozik felajánlani tömör
formában. Ez a lista adminisztrációs koncepciónak, vezérfonalnak is tekinthető a
napi munkához. Az analizáló eszközök könnyebb elérése végett a feladatokhoz
hozzá van rendelve az alább tárgyalt tranzakciók zöme. A kezdő technikai
kollégáknak hasznos eszköze lehet még akkor is, ha standard módon nem
használják.
7.1.2.1 Rendszernapló ellenőrzése (SM21):

Ellenőrzés célja: Esetleges hibák felderítése, és kijavítása a rendszerben. Az
ellenőrzést óránként célszerű végrehajtani. Az információ jellegű üzeneteket a
rendszer zöld, a figyelmeztetéseket sárga, a hibákat piros színnel jelöli.

195
Ábra 7-1 SM21 ©SAP
A mellékelt ábrán egy tipikus Transaction log feltelés látható. A hiba periodikusan ír a
rendszernaplóba. Több hiba esetén a hibákat csoportosítani kell, megoldásukhoz
ötlet hiányában az OSS használata ajánlott.
A rendszernaplót az SM21 tranzakció segítségével lehet a rendszerre globálisan,
vagy SAP instanciánként ellenőrizni. A rendszernaplót minden nap át kell vizsgálni. A
naplóban ellenőrizni kell minden warning és error típusú problémát. A
naplóbejegyzéseket az alábbi logikai csoportokba kell a fontosságuk szerint sorolni:
• Kritikus rendszerüzenetek
• ABAP dump-ok
• Egyéb hibaesemények
• Warning-ok
7.1.2.2 Nyomtatási rendszer ellenőrzése (SP01):

Ellenőrzés célja: A nyomtatások feldolgozásának ellenőrzése.
A tranzakció segítségével, a kimenő nyomtatási kérelmek láthatóak. A nyomtatási
kérelmek státuszai, a következők lehetnek:
• Comp. (zöld) a nyomtatás sikeresen eljutott a külső spool rendszerbe.
• In proc. : a nyomtatás éppen folyamatban van.
• Wait. : A nyomtatási job várakozik a nyomtatásra.
196
• Error: Hiba történt nyomtatás közben. Ez esetben a státusz feliratra duplán

kattintva bővebb információ kapható. A leggyakrabban előforduló hibaeset,
hogy egy nagyobb nyomtatási kérelem (50-60 oldal) lefoglalja a spool
processzt az adott applikációs szerveren, ezért a feldolgozatlan spool
kérelmek nem kerülnek azonnal kinyomtatásra.
Ábra 7-2 SP01 / SP02 ©SAP
7.1.2.3 Workprocesszek ellenőrzése (SM50, SM51, SM66)

Ellenőrzés célja: Hosszan futó, vagy nagy memória felhasználással járó
workprocesszek felderítése, szükség esetén megszakítása. A processzek nagy
memória felhasználás esetén un. Privilige módba mennek át. Ez az eset legtöbbször
hibás szűkítési feltétellel megadott riportok futtatásakor fordul elő. A hiba
észlelésekor fel kell venni, a kapcsolatot, a riportot futtató felhasználóval.
Amennyiben szükséges a riport futtatása, ha lehetőség van rá, háttér jobként kell
beütemezni. A processzek megszakítását, a Processz à Megszakítás core nélkül
menüponttal tehetjük meg. A következő ábrán épp egy hosszan futó job látható.

197
7.1.2.4 Zárolási objektumok ellenőrzése (SM12):

Ellenőrzés célja: Zárolás alatt maradt objektumok ellenőrzése.
Bizonyos programok futásának megszakadása esetén, előfordul, hogy adatbázis
objektumok zárolva maradnak. Ezek a címben szereplő tranzakció végrehajtásával
felderíthetőek. Ha egy objektum 1 napnál régebben zárolva van. először a futó
jobokat kell ellenőrizni. Elképzelhető, hogy egy batch job 1 napnál régebben fut, és ő
zárol objektumokat. A zárolás alatt maradt objektumokat manuálisan lehet feloldani,
a Zárolási bejezés à Törlés menüpont segítségével.

198
7.1.2.5 Jobok ellenőrzése (SM37):

Ellenőrzés célja: A beütemezett háttér jobok hibamentes lefutásának ellenőrzése.
Az ellenőrzés első képernyőjén az utolsó ellenőrzési időpont óta eltelt időtartamot
célszerű megadni, kiválasztott periódusnak. A jobok státusza következő lehet:
Engedélyezve: A job ez esetben sikeresen be lett ütemezve, és futása engedélyezve
van a tervezett időpontban.
Futtatható: A job a megadott indítási feltételnek megfelel, és vár egy szabad
workprocesszre amelyben végrehajthatja feladatát.
Aktív: A job éppen végrehajtás alatt van.
Kész: A job sikeresen lefutott.
Megszakítva: A job futása megszakadt. Ez esetben történt probléma. Ehhez
kapcsolódóan további információt nyerhetünk, az eseménynaplóból, a job naplóból,
és egy esetleges ABAP dump-ból.
7.1.2.6 ABAP dump-ok ellenőrzése (ST22):

Ellenőrzés célja: Programok futásának megszakadásáról kaphatunk bővebb
információt. Optimális esetben a rendszerben nem találhatók dump-ok.

199
A program hibákat több dolog okozhatja: Program hiba, felhasználói hiba, rendszer
hiba.
A rendszer hibák memória, processzor, vagy diszk kapacitás hiánnyal, hibával állnak
kapcsolatban. Ezekre utaló nyomok felfedezhetőek a hiba részletes leírásában.
Y vagy Z névtartományba tartozó program hiba esetén fel kell venni a kapcsolatot a
program készítőjével, és felhívni a figyelmét az előforduló hibára.
Egyéb név tartományba eső program esetén a http://service.sap.com/notes címen
található OSS útmutatók között kell keresést végrehajtani. Miután kiderült, hogy a
program milyen modulhoz tartozik, fel kell venni a kapcsolatot az adott modul
felelősével, és szintén fel kell hívni a figyelmét, az előforduló hibára.
Ábra 7-6 ST22 ©SAP
7.1.2.7 Adatbázis műveletek (DBACOCKPIT)

A WebAS ABAP 7.00 verziótól az SAP átalakította az adatbázis-kezelést támogató
tranzakciókat méghozzá oly módon, hogy egy központi, ún. DBA Cockpit-be helyezte
azokat. A tranzakciók továbbra is elérhetők, azonban azok már a DBA Cockpit
részeként nyílnak meg. Alapvetően nagyon sok, szerteágazó tranzakciót
implementált az SAP egy felületre ezzel könnyítve a DBA-k feladatát. A DBA Cockpit
egy platform független eszköz, mely lehetővé teszi az adatbázisok monitorozását és
adminisztrálását egy központi grafikus felhasználói felületről. A legegyszerűbb elérni
200
az eszköztárat a DBACOCKPIT tranzakcióval. A legtöbb régi tranzakció is elérhető

(elvileg), amennyiben azokat kívánnánk használni, azonban az eredeti tranzakció
azonosítóját ki kell egészíteni az ’OLD’ szóval. Pl. DB02 helyett DB02OLD.
A központi DBA funkciók elérésének több előnye is van:
• Lokális és távoli adatbázisok elérése egy tranzakcióból:
A DBACOCKPIT tranzakcióból monitorozhatunk lokális és távoli adatbázisokat
függetlenül attól, hogy SAP vagy nem-SAP adatbázisok. Ugyanakkor a
rendszer meg tudja különböztetni, hogy MSSQL, DB2, Oracle vagy MaxDB
adatbázisokhoz kell-e kapcsolódnia monitorozás céljából. Célszerű az SAP
Solution Manager rendszerében is fellelhető DBACOCKPIT-et úgy
konfigurálni, hogy itt lehessen elérni központilag az összes adatbázis
monitorozását.
• Több adatbázis platform kezelése:
A különböző adatbázis-kezelők esetén a DBACOCKPIT ugyanazt a
környezetet használja azonban a képernyők tartalma változhat DB szállító
szerint. Ez megkönnyíti a helyzetet abban az esetben ha több különböző DB
platform kerül használatra az IT környezetben.
• Finomított biztonság az adatbázisok korlátozott eléréséhez:
Az új jogosultsági koncepció lehetővé teszi, hogy különböző hozzáférési
jogokat adjunk adminisztrátoroknak a különböző adatbázisokhoz. (Az SP12-
ben kiszállított SAP_BC_DB_ADMIN_MSS jogosultsági szerep minden
szükséges jogot megad a felhasználónak a cockpit használatához.)
7.1.3 Heti feladatok
Bizonyos feladatokat érdemes hetente, vagy alkalmanként végezni a rendszerben,

mivel adatgyűjtésre van szükség hozzájuk.
7.1.3.1 Rendszer teljesítmény ellenőrzése (ST03n):

Ellenőrzés célja: A válaszidő monitorozása, esetleges szűk keresztmetszet keresése.
Ebben a tranzakcióban kapunk bővebb információt a rendszer válaszidejéről,
leghosszabban futó programokról. A rendszer válaszidejének 2000ms alatt kell lenni.
Célszerű a rendszer válaszidejéről grafikont, táblázatot készíteni napi felbontásban,
így könnyebb észrevenni a kirívó értékeket. Legfontosabb mérőszámok: Dialóg
steps, Av. response time, database requests.
Magas válaszidők esetén célszerű megvizsgálni a hosszú ideig futó programokat,
illetve a magas adatbázis igénnyel rendelkező programokat.

201
Ábra 7-7 Workload analízis (ST03N) ©SAP
Ellenőrizni kell valamennyi applikációs szerveren a teljesítmény adatokat a dialog, az

update és a batch típusú feldolgozásokat tekintve. A napi működést leginkább az
átlagos dialog és update válaszidők határozzák meg.
Amennyiben a rendszer teljesítménye, vagy valamely applikációs szerver
teljesítménye lecsökken, akkor értesíteni kell a rendszer hangolására szakosodott
specialistát, aki további részletes teljesítményvizsgálatokat fog majd a rendszerben
elvégezni annak megállapítására, hogy mely rendszerkomponensek miatt alakult ki a
teljesítmény csökkenése.
7.1.3.2 Terheléselosztás (SMLG)

Meg kell vizsgálni, hogy az alkalmazásszerverek terheléselosztási szempontból
megfelelően működnek-e. A bejelentkezett felhasználók, válaszidők szintén fontosak.
Be kell állítani a maximális válaszidő és engedélyezett felhasználószám
paramétereket szükség esetén.
7.1.3.3 Temse ellenőrzése (SP12):

Ellenőrzés célja: A Temse (spool adatbázis) konzisztenciájának ellenőrzése.

202
Hetente el kell végezni a Temse adatbázis konzisztencia ellenőrzését, illetve

reorganizálását, az inkonzisztens TemSe állományok megszüntetését. Ezeket a
funkciókat a Temse Database menüből érhetjük el.
A TemSe állományok egy része diszkes állományokban van, míg más részük
adatbázis táblákban helyezkedik el. Nagy mennyiségű nyomtatások esetében a
spool kérelmek hosszú ideig történő tárolása miatt az érintett adatbázis táblák
indokolatlanuk nagymértékben megnőhetnek.
Az üzemeltetésnek nem feladata az, hogy elbírálja a hosszan tárolt spool
kérelmekkel kapcsolatosan, hogy azok tárolása indokolt-e, vagy sem. Ennek
megfelelően az üzemeltetésnek jelezni kell az alkalmazás modulok felelősei felé a
gigászi méretű spool kérelmeket, hogy az adatbázis ezen területen történő
indokolatlanul nagy növekedését elkerüljék.
7.1.3.4 SAP pufferek ellenőrzése (ST02):

Ellenőrzés célja: Az SAP puffereket kihasználtságának ellenőrzése.
A pufferek túl magas a swap-elését, a rendszer megkülönböztető piros jelzéssel
jelöli. Ilyenkor a probléma kernel paraméterhangolással orvosolható. A „Aktuális
paraméterek” nyomógombbal információt kapunk a hangolandó kernel
paraméterekről. A sok swap-elés esetén az adott pufferhez tartozó paraméterek
növelése szükséges.

203
Ábra 7-8 SAP pufferek ©SAP
7.2 SAP rendszerek naplói és auditálhatósága

Az alábbi fejezet az SAP rendszerek általános naplózási valamint az audit adta
lehetőségeit tárgyalják.
7.2.1 Auditálhatóság
Az adatbázis tábláiban van "minden" adat, ezeket sokféle szempontból
csoportosíthatnánk, a jelen fejezet témája okán most két részre különítjük el a
táblákat: a rendszertáblák, illetve az üzleti adatokat tartalmazó táblák.
Szinte minden esemény nyomot hagy a műveleti statisztikában, az adatbázis
naplótábláiban vagy a fájlrendszerben helyet foglaló naplófájlokban. A legegyszerűbb
eszköz nem más, mint a táblák nagy részében megtalálható "utolsó módosító",
"módosítás dátuma" típusú mezők, amelyekbe a működő folyamat során - akár
dialóg üzemben, akár háttérben - a többi mezőtartalommal egy időben belekerül a
megfelelő érték, és amely bármikor megtekinthető. Az "utolsó módosító" mezőbe a

204
felhasználónév kerül, és a felhasználói törzsben tárolt személynév és egyéb adatok

segítségével az adatmódosításokat végző felhasználó egyértelműen személyhez
köthető.
A fontosabb üzleti objektumok módosítás-történetét egy, erre a célra kifejlesztett
eszközzel, a módosítási bizonylattal tároljuk. Egy ilyen bizonylat éppúgy szigorú
számadású, mint például egy pénzügyi könyvelési bizonylat. Tartalmazza a
módosítás időpontját, a végrehajtó felhasználó-azonosítóját, a módosítás jellegét, a
módosítás által érintett táblamező eredeti és új tartalmát. A módosítási bizonylatok
több szempont szerint kereshetők, tetszés szerinti ideig megőrizhetők, de
archiválhatók is.
További - általános - lehetőség, hogy bizonyos, kritikus tartalmú táblákat technológiai
szinten is naplózunk (tábla-naplózás). Ez azt jelenti, hogy minden egyes bejegyzés
létrehozása, módosítása, törlése körülményei bekerülnek a táblanaplóba. A naplózás
táblánként kapcsolható.
Létezik egy Alkalmazási Napló is, ebbe kerül minden olyan információ, amit egy
program futása során - az üzleti folyamat követése érdekében - tárolni és később
visszakeresni szükséges.
7.2.1.1 Rendszeradatok naplózása, audit lehetőségek

Az üzemeltetéshez kapcsolódó tevékenységek (csak néhány kiragadott példa:
transzport-műveletek, üzemmód-váltás, rendszer-indítás, paraméterek módosítása,
nyomtatási kérelem) döntő többsége "saját" naplót ír, nem is beszélve a processzek -
beállítható mélységű - naplóiról. A naplók egy része egyszerűen, operációsrendszer-
eszközökkel jeleníthető meg, más része pedig e célra kifejlesztett programokkal.
Egyes naplókat a biztonságos tárolás végett kódolva tárolunk.
A fontosabb események és az esetleges hibák mindenekelőtt a rendszernaplóban
jelennek meg, részletes információt biztosítva az okok felderítéséhez. A programok
futási hibái emellett még külön hibanaplóba kerülnek.
Kiemelt fontosságú minden, a felhasználótörzzsel és a jogosultságokkal kapcsolatos
művelet. Ide értjük a felhasználók adatainak változását, az adatokhoz, funkciókhoz
való hozzáférési jogosultságok felhasználóhoz való rendelését is. Az ezeket érintő
módosításokat részletesen naplózza a rendszer, módosítási bizonylatok formájában.
Egy külön eszköz, a Jogosultsági Információs rendszer mutatja az aktuális tartalmat

205
és a módosítástörténetet, amelyből például kiderül, hogy egy adott felhasználó adott

jogosultsággal mettől meddig rendelkezett, vagy az elmúlt időszakban hányszor
próbált sikertelenül bejelentkezni, netán rendelkezik-e jelen pillanatban bizonyos - az
előre megadott - kritikus jogosultsági kombinációk valamelyikével.
Azonban ha rendelkezik egy felhasználó egy adott jogosultsággal, nem biztos, hogy
használta valaha is. A felhasználók tevékenységei (mint például a bejelentkezés,
programok indítása, a jelszava változott, egy - biztonsági szempontból kritikus -
objektumot elhelyezett egy transzport-kérelemben) szintén naplózhatók: erre szolgál
a Biztonsági Napló, amelyet be-ki lehet kapcsolni, és amely tartalma szintén
kereshető.
A felsoroltakon kívül számos egyéb lehetőség van a tevékenységek utólagos
követésére, álljon itt egypár példa: a jogosultsági vizsgálatok nyomkövetése,
kapcsolatfelvétel külső rendszerekkel, az adatbázis interfész vagy a puffer használat
nyomkövetése.
Az Audit Információs Rendszer mindenre kiterjedő, menübe rendezett programokat
tartalmaz a naplók, logok, nyomkövetések, módosítási bizonylatok stb.
megtekintésére. A rendszer-audit mellett igen fontos az üzleti audit is.
7.2.1.2 Üzleti adatok naplózása, audit lehetőségek

Az Audit Információs Rendszer üzleti audit része nem egyszerűen csak az üzleti
törzsadatok, mozgásadatok, a funkciókat vezérlő beállítási táblák tartalmának
megjelenítésére és módosításainak követésére szolgál a rendszerben, hanem egy
teljes körű információs rendszer, ami az adó, pénzügyi, számviteli, kontrolling,
konszolidációs, személyügyi, bérszámfejtési, tervezési, logisztikai műveletek
könyvvizsgálói és belső ellenőri szinten történő vizsgálatára alkalmas.
Az üzleti adatok módosításainak naplózására különösen a módosítási bizonylat és az
Alkalmazási napló, de a többi felsorolt lehetőség is a rendelkezésre áll.
7.2.2 Általános naplók

Az SAP rendszer a működésével és az felhasználók rendszerren belüli
tevékenységével kapcsolatban számos naplót vezet és részletes adatokkal

206
támogatja a rendszer-audit folyamatát is. Az alábbiakban a leglényegesebb ilyen

eszközöket vesszük sorra.
7.2.2.1 Rendszernapló
Az SAP a rendszer alapvető működését befolyásoló eseményekről rendszernaplót
vezet. Létezik applikációs szerverenkénti és egy központi rendszernapló is. A
rendszernapló tartalmazza az esemény bekövetkezésének időpontját, a felhasználó
nevét, a tranzakció nevét, a hiba rövid megnevezését és az SAP szerviz processz
azonosítóját. A rendszernapló adatai operációs rendszer szintű fájlokban vannak
eltárolva. Az applikációs szerverek lokális rendszernaplói körpufferes szervezésűek.
A központi rendszernapló rendelkezik egy aktuális és egy „archive” rendszernapló
fájllal.
7.2.2.2 Az audit információs rendszer

Az audit információs rendszer (Audit Information System AIS) standard módon kerül
kiszállításra. Segítségével az SAP rendszer biztonságtechnikai szempont-okon
alapuló részletes vizsgálatát lehet elvégezni. Az AIS egy hierarchikus struktúra
formájában mutatja azokat az információkat, amelyek alapján egyszerűen át lehet
tekinteni a biztonsági követelmények szempontjából szükséges, a rendszerben
elvégzendő beállításokat, amelyek már végrehajtásra kerültek, illetve azokat,
amelyeket még el kell végezni. Az AIS üzleti folyamatok és rendszer-biztonsági
folyamatok felülvizsgálatára lett kifejlesztve.
7.2.2.3 Biztonsági audit napló

A biztonsági audit napló (Security Audit Log) standard része a rendszernek.
Segítségével rögzíteni lehet a rendszerbiztonsággal kapcsolatos beavatkozásokat,
amelyek a rendszer ellenőrzése szempontjából szükségesek. Ezekhez az
információkhoz egy „audit report” formájában lehet hozzáférni. A rendszer a rögzített
információkat egy napló állományban tárolja. Az alábbi információk rögzítésére van
lehetőség a naplóban:
• sikertelen és sikeres dialóg felhasználói bejelentkezési kísérletek,
• sikertelen és sikeres RFC felhasználói bejelentkezési kísérletek,
• funkciós modulok RFC-n keresztül történő meghívása,

207
• felhasználói törzsadatrekordok módosítása,

• tranzakciók sikeres és sikertelen indítása.
• az audit konfigurációban történő módosítások
7.2.2.4 Statisztikák
Az SAP rendszere naplózza a rendszerben történő aktivitásokat tranzakciónkénti és
felhasználónkénti csoportosításban is. Ezeket az ún. Workload analízis segítségével
lehet elemezni.
7.2.2.5 Alkalmazásnapló
Az alkalmazásnapló rögzíti az alkalmazás végrehajtási folyamatát oly módon, hogy
azt később szükség esetén e napló alapján rekonstruálni lehessen. Amíg a
rendszernapló rögzíti a rendszer-eseményeket, addig az alkalmazásnapló rögzíti az
alkalmazásban bekövetkező eseményeket. A rendszer külön tranzakcióval
rendelkezik az alkalmazás eseményeinek a definiálására, illetve a rögzített
alkalmazásnapló megtekintésére.
7.2.2.6 Változási bizonylatok naplózása

Az üzleti folyamatok adatkomponensei gyakran módosulnak. A rendszer
ellenőrizhetősége érdekében erősen javasolt a kritikus üzleti folyamatok során
történő adatmódosítások rögzítése. A rendszer az úgynevezett változási bizonylatok
(Changing Documents) segítségével naplózza az üzleti folyamatok
adatobjektumaiban bekövetkezett változásokat.
7.2.2.7 Táblamódosítások naplózása

Azon táblák esetében, amelyekre az SAP „data dictionary”-ben be van állítva a
táblamódosítás rögzítése funkció, lehetőség van a táblamódosítás eseményeinek a
rögzítésére. A módosítások rögzítését egy rendszerparaméter segítségével lehet
aktiválni, vagy tiltani.
7.2.2.8 Felhasználói törzsrekordban történt módosítások naplózása

A felhasználói törzsrekord adataival kapcsolatos módosítás a rendszerben
automatikusan naplózásra kerül. E változásokat a rendszerben meg lehet jeleníteni.

208
Az így gyűjtött információkat archiválni lehet. Az archiválással egyidőben az archivált

adatok automatikusan ki is törlődnek az adatbázisban tárolt napló-rekordokból.
Felhasználói törzsrekordban történt módosítások naplózása
A felhasználói törzsrekord adataival kapcsolatos módosítás a rendszerben
automatikusan naplózásra kerül. E változásokat a rendszerben meg lehet jeleníteni.
Az így gyűjtött információkat archiválni lehet. Az archiválással egyidőben az archivált
adatok automatikusan ki is törlődnek az adatbázisban tárolt naplórekordokból.
7.2.2.9 Hálózati napló

A fontosabb hálózati elemeknek, mint például egy tűzfalnak is fontos a naplója az
SAP szempontjából. Amennyiben az SAP szerverek a hálózattól tűzfalakkal vannak
leválasztva, úgy a tűzfalak igen részletes naplókat készíthetnek mindennemű SAP
forgalomról. A tűzfalakkal történő naplózás az SAP-nak adatokat szolgáltató
rendszerek aktivitásának naplózására illetve a rendszert adminisztráló SAP IT
személyzet tevékenységének naplózására is alkalmazható.
Ebbe a kategóriába tartozik még az SAP walldorfi központja felé kiépített
szervizkapcsolat létrehozására szolgáló SAProuter napló is. A rendszerben történt
események visszakövethetősége érdekében további SAProuterek alkalmazásával
részletes hálózati aktivitási listákat lehet készíteni. Az SAProuterek naplózási
részletességének szintjét az SAProuter indítási paramétereivel lehet beállítani.
Megfelelő architektúra kialakításával az SAProuterek segítségével az egy
telephelyen elhelyezkedő SAP kliensek hálózati forgalmának naplózására is
lehetőség van.
7.3 SAP Adatvédelem

Az SAP rendszer egy integrált adatbázison alapuló rendszer. Ezen adatbázisban
tárolt adatok biztonságát az operációs rendszer, az adatbázis-kezelő és az SAP
alkalmazás szintjén kell biztosítani. A hálózaton továbbított adatok biztonságáról
hálózati szinten kell gondoskodni.
A rendszeren belül végzett minden adatmódosítás naplózott az adatbázis rétegben
fizikailag tárolt információk a közvetlen felhasználói hozzáféréstől védettek, így a
tárolt információk hitelesnek tekinthetők.

209
7.3.1 Operációs rendszer szintű védelem

Az SAP rendszer adatainak védelmét az operációs rendszer szintjén az alkalmazott
operációs rendszer eszközeivel kell megvalósítani. Ez a védelem egyrészt az SAP
rendszer által használt operációs rendszerben definiált felhasználók jelszavának a
védelmét jelenti, másfelől az operációs rendszer eszközeivel adminisztratív úton kell
gondoskodni arról, hogy más operációs rendszer felhasználók az SAP rendszer
állományaihoz ne férhessenek hozzá.
A SAP rendszer unix környezetben történő adminisztrációjára 2 felhasználóra van
szükség: a SAP rendszer adminisztrátorra ( <sid>adm, néven ahol sid a SAP
rendszer azonosítója) és az Adatbázis adminisztrátorra (pl. ora<sid>). Windows
környezetben a <sid>adm a tulajdonos és azzal dolgozik az adminisztrátor, azonban
a fájlok kezelése és biztonsági feladatok a SAPService<SID> szolgáltatás típusú
felhasználó kezében van.
Az operációs rendszert javasolt úgy beállítani, hogy sem operációs rendszer
adminisztrátor (root), sem az SAP vagy Adatbázis adminisztrátor felhasználók
számára ne legyen lehetőség távoli-terminál alapú bejelentkezésre a rendszer
hosztjain. Az adminisztrátoroknak, üzemeltetőknek, saját, egyedi, nevesített
felhasználókkal rendelkezniük, ezek használatával kell a rendszer hosztjaira belépni,
majd a hoszton, naplózott eljárással kell identitás váltást végrehajtani (pl. sudo) a
SAP vagy Adatbázis adminisztrátor felhasználók nevére.
Az külső – nem SAP - rendszerek felöl érkező operációs rendszer szintű
kapcsolatokat (pl. NFS-en megosztott könyvtárakhoz való hozzáférés, SCP, SFTP
alapú adatkapcsolat) számára is mind nevesített, a partner rendszerre jellemző
felhasználót kell létrehozni. A SAP munka-területeivel (pl. fájl alapú interface-ek
kijelölt kommunikációs könyvtárai) kapcsolatos írási/olvasási stb. feladatokhoz
szükséges jogosultságot, a SAP operációs rendszer szintű csoportján (a sapsys
csoport) keresztül kell megadni e külső rendszereket reprezentáló felhasználóknak
7.3.2 Adatbázis-kezelő szintű védelem

Egy SAP rendszer az adatbázishoz meghatározott adatbázis felhasználó
segítségével kapcsolódik. Ezen adatbázis felhasználó tulajdonában vannak az SAP
adat-szótárában (Data Dictionary) definiált, az adatbázis-kezelő eszközeivel
létrehozott adatbázis táblák. Az SAP felhasználók előtt közvetlenül nem ismertek az
210
adatbázis felhasználó neve és jelszava. Ezt ezen felhasználók elől elfedi a bázis-
rendszer adatbázis interfésze. Az SAP által használt adatbázis felhasználó és az
adatbázis adminisztrátor felhasználók jelszavának védelméről az adatbázis-kezelő
eszközeinek felhasználásával adminisztratív módon kell gondoskodni.
További védelmet jelent az adatbázis számára, ha távoli gépről nem engedjük meg a
közvetlen adatbázis kapcsolatot sem az adminisztrátoroknak, sem külső
rendszereknek. Az alkalmazás szerverek természetesen kivételek, azoknak
közvetlenül látni kell az adatbázis szerver, így e hosztokat explicite engedélyezni kell.
7.3.3 Hálózat szintű védelem

Az SAP kliens szerver architektúrájából adódóan gondoskodni kell az alkalmazás
szerver és kliensek között a hálózaton átküldött adatok védelméről. A kétfajta kliens
protokoll esetében eltérő, de egyenszilárdságú eszközök állnak rendelkezésre.
A telepített SAPGui kliens által használt DIAG és RFC protokoll védelmére a SAP az
SSL-hez (Secure Socket Layer) hasonló SNC (Secure Network Communication)
protokoll dolgozta ki, míg a Web alapú, böngészőn keresztüli elérésére (SAPGui for
HTML használata) az SSL protokoll használható.
Az SNC protokoll használatához a SAPGui kliens és az Web AS ABAP alkalmazás
szerver között, mind a frontend mind a szerver oldalon egy kompatibilis, SAP által
bevizsgált külső biztonsági szoftverre van szükség, mely végrehajtja az „encryptálás”
és a „decryptálás” feladatat. A biztonsági megoldás által szállított és az említett
komponensre telepített biztonsági library-nak támogatni kell az ún. Generic Security
Services Application Programming Interface Version 2 (GSS API v2) biztonsági API-
t, amint azt a SAP az SNC specifikációban rögzíti.
Az SNC-vel ún. alkalmazás szintű, a végpontok közötti (end-to-end) biztonság
valósítható meg. Minden kommunikáció amit a két, SNC mechanizmus által védett
komponens között történi titkosított: pl. a SAPGui és az alkalmazás szerver között, a
SAP alkalmazás szerverek között, vagy pl. lokális nyomtatás során az alkalmazás
szerver és a SAPlpd printer daemon között.
A különböző SNC implementációkkal (az alkalmazott biztonsági szoftvertől függően)
az adatbiztonságnak az alábbi három szintje valósítható meg:

211
Csak azonosítás (Authentication): ebben az esetben az SNC csak a kommunikáló

partnerek (kliens-szerver, szerver-szerver) egyértelmű és megbízható azonosítására
használható.
Adat integritás védelme: a rendszer ilyenkor képes felismerni, ha a csatornánk
átküldött adat véletlenszerűen vagy szándékosan megsérült illetve manipulálták.
Titkosítás: a titkosítás a legmagasabb szintű védelmet jeleni, mely magába foglalja
integritás védelmet is és egyúttal biztosítja, hogy az adat illetéktelenek kezébe ne
kerülhessen, a titkosítást csak a kommunikációban résztvevő partnerek számára
legyen visszafejthető.
Az SAP 4.5 verziójától kezdve a rendszer részeként standard módon kiszállított SAP
„Security Library” (SAPSECULIB) library viszont külső szoftver igénybe vétele nélkül
használható a SAP szerver komponensek közötti adat-kapcsolat titkosításához,
valamint a saprouter-ek között a kommunikáció védelmére a SAP support hálózata
felé kiépíthető kapcsolatban.
A HTML Gui használata minden olyan esetben sokkal egyszerűbb, ahol a
kommunikációs csatorna a kliens-szerver kapcsolat szintjén teszi indokolttá a
titkosítást, ugyanis a HTMLGui mind http, mint https protokoll felett működik, külön
„külső” titkosító szoftver/library használata nélkül.
A kommunikáció biztonsága érdekében a Secure Socket Layer protokollt fogjuk
használni.
Az SSL segítségével titkosítható az egyébként nyílt szöveges HTTP adatforgalom a
böngésző és a Web AS között. A titkosításon túl, az SSL protokoll segítségével a
kommunikációban részvevő szereplők azonosítani is tudják egymás. Az azonosításra
a következő lehetőségeket biztosítja az SSL használat:
• Szerver oldali azonosítás (Server-side authentication): a kapcsolat
felépítésekor a Web AS azonosítja magát a kliensen egy érvényes és hiteles
SSL szerver tanúsítvány segítségével, megakadályozva, hogy a kliens egy
„hamis” kiszolgálóhoz kapcsolódjon
• Kliens oldali azonosítás (client-side azonosítás) Kliens tanúsítvány
használatával a felhasználó azonosítja magát a szerveren, kiváltva pl. a
felhasználónév/jelszó alapú azonosítást.
• Kölcsönös azonosítás (mutual authentication): mind a szerver mind a kliens
kölcsönösen azonosítva lesz.
212
A HTTPS protokoll használata során az SSL titkosítást végződtethetjük az SAP

alkalmazás szerveren, vagy a Web-es elérés terhelés elosztásáért is felelős ún. SAP
Web Dispatcher alkalmazás proxy-n.
Ez utóbb megoldás azért is szerencsésebb, mivel a várhatóan igen nagyszámú
konkurrens felhasználó esetében a SSL kapcsolat kezelése (encryptálás és a
decryptálás) jelentős plusz terhelés növekedést jelentene SAP alkalmazás szerverek
számára. A különálló hosz(tok)on futó SAP Webdispatcher viszont ezt a feladatot
átveszi az alkalmazás szervertől, azaz:
• a felhasználó felől érkező HTTPS kérést decryptálja és a http kérés
formájában továbbítja az alkalmazás szerver felé
• amenyiben az SSL protokoll-hoz kötött felhasználó-azonosítás van
használatban (pl. X.509 kliens tanusítvánnyal történő azonosítás esetén)
akkor az authentikációhoz szükséges adatokat a WebDispatcher http-header
mezőkben továbbítja az alkalmazás szerver felé.
• az alkalmazás szervertől http protokollon keresztül kapott választ https
protokollal továbbítja a kliens felé.
A https protokoll terminálás azt is lehetővé teszi, hogy a forgalmat a védett hálózaton
belül monitorozzuk és naplózzúk.
A fentiekből az is következik, hogy erős authentikáció használata esetén csak akkor
lehet a https kapcsolatot az SAP Webdispatcher elött végződtetni (pl. a tűzfalon) ha
az önmagában is képes az authtenikációs adatokat továbbítani a SAP Web AS felé.
Mivel erre a SAP Webdispatcher képes, ezért javaslatunk értelmében ezt érdemes
erre a célra használni.
7.3.4 Titkosítás, hitelesítés

Az SAP alkalmazások a Secure Store and Forward (SSF) mechanizmust használják
az adatok és objektumok titkosítására és hitelesítésére. Az SSF segítségével
lehetőséges a SAP rendszerben keletkezett digitális dokumentumok, a felhasználó
vagy az intézmény általi digitális aláírására és titkosítására, a dokumentum
hitelesítésére és integritásának ellenőrzésére, azok eltárolása, vagy nem
biztonságos csatornákon való továbbítása során.

213
A SSF gyakorlatilag egy SAP funkció gyűjtemény melynek használatával nem csak a
standard de a rendszerben definiált saját dokumentumainkat, objektumainkat is
védhetjük, a jó pár standard módon támogatott SAP dokumentum mellet.
Az SSF nem maga hatja végre a digitális aláírást, hanem külső biztonsági könyvtár
szolgáltatásait veszi ehhez igénybe, és feltételezi, hogy a digitális aláírásokhoz a
megfelelő biztonsági infrastruktúra kiépítésre került, azaz pl. a felhasználók
rendelkeznek digitális aláírásra is alkalmas kliens tanúsítvánnyal
Az SSF az SNC-hez hasonlóan - olyan SAP által bevizsgált és elfogadott külső
biztonsági termékekkel képes együttműködni, amelyek megvalósítják a már emlitett
GSS-AP1 v2 sztenderd interfészt.
Az SAP rendszerek képesek kezelni a PKI alapú certifikátokat mind kliens, minde
szerver oldalon.
7.3.5 Hálózati elérés biztonsága

A SAP rendszereknek mind a Web alapú mint a SAPGui klienssel történő elérését a
hálózaton keresztül biztonságos módon, a szerverek megfelelő hálózati védelmének
biztosítása mellet kell megoldani. A külső „publikus” hálózat (Internet vagy a
kormányzati gerinc hálózat) felől érkező felhasználók közvetlenül csak a DMZ-ben
elhelyezett proxy-k meghatározott belépési pontjaihoz férhetnek hozzá, a SAPGui
és a HTTPS protokollon keresztül. A felhasználói kérések, ezen proxy-n keresztül
lépnek be a szerver zónába és jutnak el a SAP rendszerekhez. A szerver zóna felé
csak a DMZ-ből, onnan is csak a proxy komponenseket futtató hosztokról szükséges
hálózati kapcsolatot engedélyezni a tűzfalakon.
7.3.5.1 SAP Web Dispatcher

A Web alapú elérés esetén (pl. SAP Portal, SAP CRM) a SAP rendszerek
biztonságos elérését többek között az SAP Web Dispatcher-en keresztül lehet
megvalósítani. A Web Dispatcher amellett, hogy alkalmazás szintű proxy-ként
működik a Web AS instanciák közötti terhelés elosztást is megvalósít.
A Web alapú elérés során a felhasználók a DMZ-ben-ben elhehelyezett Web
Dispatcher instancia tűzfalon engedélyezett protját érik el HTTPS protokollon

214
keresztül. A Web Dispatcher a HTTPS csomagot kibontva elemzi a kérést és azt a –

message szervertől kapott információk alapján – a terhelés megosztás beállított
szabályainak megfelelően kiválsztott Web AS hosztnak továbbítja a SAP szerver
LAN-ra.
A kérés továbbitása törtéhet HTTP protokollon (pl. a DMZ és a szerver hálózaton
elhelyezett hálózati forgalom analízáló eszközök használata miatt) vagy a Web
Dispatcher ismét titkosíthatja azt SSL segítségével, amit aztánt a SAP alkalmaz
szerver „decryptál”.
Ha a HTTPS csomagban már egy létező session-höz érkezik újabb kérés, akkor azt
az aktív session-t birtokló Web AS instanciához továbbítja, a terheléstől függően. Az
egyes session-öket és az öket aktuálisan kiszolgáló Web AS instanciákat a Web
Dispatcher nyilvántartja.
Amennyiben a SAP Server LAN-on több Web-es alkalmazás transzparens
kiszolgálását kell megoldani (úgymint a SAP Portál, a SAP BI web-riporting) az
egyes szolgáltatások más és más szolgáltatási portokon hirdetjük meg a DMZ külső
határfelületén. Az egyes szolgáltatási portokoz, külön-külön Web Dispatcher-
instanciák tartoznak, amelyek már a megfelelő szolgáltatást nyújtó SAP rendszer
Web-AS instanciája felé továbbítják a kéréseket.
A szolgáltatásokhoz való hozzáférés is egységesen a Portálon történő egykapus
beléptetéssel történik, akár a telepített SAPGui-n, akár a Web böngészőn keresztül is
érik el a felhasználók ezeket a funkciókat.
Ábra 7-9 SAP WebDispatcher - zónák (service.sap.com)

215
Az SAP elérése web alapú klienssel HTTPS (akár SOAP) protokollon keresztül
7.3.5.2 SAProuter
Az RFC (Remote Function Call) és DIAG (Dynamic Information and Action Gateway)
kapcsolatok esetén a SAProuter-t használjuk port és protokoll ellenőrzésre. Az
SAProuter egy alkalmazás szintű proxy, ami a tűzfalon beállított cím és port-
szűrésekkel hatékony védelmet biztosít a SAP szerver hálózatok számára, a nem
engedélyezett hozzáférésekkel szemben.
Ábra 7-10 SAProuter biztonsági elhelyezése©SAP
A tűzfalakon beállítható port szűrésekkel, elérhetjük, hogy a felhasználók a publikus

hálózatból a szerver LAN-on belül csak egy adott hosztothoz és ahhoz is csak egy
adott porton keresztül férhetnek hozzá TCP/IP-vel. Ha ezen a hoszt-on célszerűen a
saprouter fut, segítéségével meghatározhatjuk, hogy a saprouter-en keresztül:
• melyik SAP rendszereket melyik hoszton
• ezen hosztokon mely TCP portokat
• és e portokat is csak a SAP protokollok használatával lehet elérni.
A saprouter standard konfigurációja szerint a publikus felhasználói hálózat felöl a
szerver LAN felé csak a saprouter host 3299-es TCP portjának elérését kell
engedélyezni. (mely port azonban konfigurálható)
A saprouter-en definált ún. route-permission tábla, a kiindulási címtartománytól, az
elérni kívánt SAP hoszt és SAP szolgáltatás függvényében engedélyezi vagy tiltja a
kliens és szerver közötti kapcsolatot. A saprouter-en mind az engedélyezett, mind a
tiltott kapcsolatok irányába történő kísérletek naplózásra kerülnek.
A SAPGui kliens felöl egy ún. SAP router sztring-el határozhatjuk meg, mely SAP
rendszer, mely szolgáltatását akarjuk elérni.

216

217

SAP Arch Selmeci AMK

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP Arch Selmeci AMK

Uploaded by

Copyright:

Available Formats

ALBA REGIA MŰSZAKI KAR

SAP technológiai architektúra

2 SAP ERP RENDSZER JELLEMZŐI..........................................................................................................7

2.1 SAP RENDSZERJELLEMZŐK ......................................................................................................................7

3 SAP NETWEAVER TECHNOLÓGIAI FELÉPÍTÉSE ......................................................................... 38

3.1 HÁROM RÉTEGŰ KLIEN-SZERVER ARCHITEKTÚRA ............................................................................... 38

4 FEJLESZTÉS AZ SAP KÖRNYEZETBEN ............................................................................................ 54

4.1 SAP ADATSTRUKTÚRA (ABAP)........................................................................................................... 54

Selmeci Attila Óbudai Egyetem

4.2 BŐVÍTHETŐSÉG, FEJLESZTÉSI LEHETŐSÉGEK........................................................................................ 61

5 JOGOSULTSÁG- ÉS FELHASZNÁLÓKEZELÉS, AUTHENTIKÁCIÓ........................................... 124

5.1 SAP FELHASZNÁLÓ ADMINISZTRÁCIÓ ................................................................................................ 124

Selmeci Attila Óbudai Egyetem

5.4.1 IDENTITY CENTER ............................................................................................................................................... 150

6 INTEGRÁCIÓS LEHETŐSÉGEK ........................................................................................................ 168

6.1 ADATKINYERÉSEK ............................................................................................................................... 168

7 ÁLTALÁNOS ADMINISZTRÁCIÓ ..................................................................................................... 194

7.1 ÁLTALÁNOS ABAP RENDSZERÜZEMELTETÉS.................................................................................... 194

7.1.3.4 SAP pufferek ellenőrzése (ST02): ........................................................................................................ 203

Selmeci Attila Óbudai Egyetem

Selmeci Attila Óbudai Egyetem

2 SAP ERP rendszer jellemzői

2.1 SAP Rendszerjellemzők

2.1.1 Moduláris felépítés

Selmeci Attila Óbudai Egyetem

funkciókat ellátó modulok között külön adatátvitelre. Egy felhasználó szemszögéből

2.1.2 Valós idejű működés

Selmeci Attila Óbudai Egyetem

• Az adatok azonnali széleskörű ellenőrzése minimalizálja az adatbevitelkor

Selmeci Attila Óbudai Egyetem

2.1.4 Egységes felület

Selmeci Attila Óbudai Egyetem

Egy tranzakción belül a beviteli képernyők az adott funkciónak, munkafolyamatnak

2.1.5 Folyamatok automatizálása (Workflow)

Selmeci Attila Óbudai Egyetem

Az SAP workflow funkcionalitása lehetővé teszi a papír alapú bizonylatok kiváltását,

2.1.6 Változások követése

Ábra 2-1 Unicode, nyelvi csoportok, átfedések

Selmeci Attila Óbudai Egyetem

ezelőtti alapítása óta folytatja a unicode sztenderd fejlesztését és kiterjesztését,

2.1.8 Archiválás általában

Selmeci Attila Óbudai Egyetem

2.1.9 Adattárolás, PBS támogatás

Ábra 2-2 Archiválás PBS technika © PBS

A hierarchikus tároló-rendszerek és archív rendszerek alkalmazásának előnye a

Selmeci Attila Óbudai Egyetem

Az SAP transzport rendszere lehetővé teszi beállítási és fejlesztési objektumok

2.1.12 Sztenderd SAP monitorozás

Selmeci Attila Óbudai Egyetem

• Adatbázis kezelő vizsgálatok

Selmeci Attila Óbudai Egyetem

megtekinthetők. Az integrált dokumentumok kellő időben garantálják a szükséges

2.1.14 Migrációt támogató eszközök az SAP-ban

Selmeci Attila Óbudai Egyetem

Egy vagy több

Ábra 2-3 Általános BatchInput feldolgozási folyamat (LSMW) © SAP

Mivel a migráció kritikus fontosságú egy új informatikai rendszer üzembe állítása

Selmeci Attila Óbudai Egyetem

• A betöltésre előkészített adatokat standard betöltő programokkal töltjük be az

Selmeci Attila Óbudai Egyetem

Az LSMW, mint migrációs eszköz a betöltési folyamat nagyfokú automatizálását teszi

2.2 SAP Rendszerhasználat - GUI

Selmeci Attila Óbudai Egyetem