DEBRECENI EGYETEM

SAP Rendszerüzemeltetés

Rácz Anett

Debreceni Egyetem

Informatikai Kar

TÁMOP 4.1.1.C-12/1/KONV-2012-0013

Integrált szervezeti és komplex felsőoktatási

szolgáltatások, valamint képzések fejlesztése a

versenyképes Debreceni Egyetemért

Tartalomjegyzék

1 Bevezetés ....................................................................................................................... 4

2 Valós alkalmazások, beszámolók .................................................................................. 6

2.1 Heidelberg Egyetemi Kórház .................................................................................. 6

2.2 Bangkok Airways légitársaság ................................................................................ 7

3 Bevezetés az SAP rendszerüzemeltetésbe ..................................................................... 9

3.1 SAP megoldások ..................................................................................................... 9

3.2 Induló lépések ....................................................................................................... 11

3.2.1 Kliens adminisztráció .................................................................................... 13

3.3 Az SAP rendszer indítása, leállítása ..................................................................... 15

3.3.1 SAP rendszer indítása SAP MMC-ben.......................................................... 17

3.3.2 A rendszer leállítása SAP MMC-ben ............................................................ 19

3.4 Első bejelentkezés ................................................................................................. 22

3.5 Licencelés ............................................................................................................. 25

3.5.1 Feladat ........................................................................................................... 27

3.5.2 Kérdések ........................................................................................................ 28

4 User menedzsment....................................................................................................... 28

4.1 Felhasználó létrehozása ........................................................................................ 29

4.2 Felhasználó menedzsment .................................................................................... 33

4.3 Felhasználó csoportok ........................................................................................... 36

 4.4 Jelszavak kezelése ................................................................................................. 37

4.5 Rendszeradminisztrátori üzenet küldése ............................................................... 38

4.5.1 Pop up rendszer üzenet küldése az összes felhasználónak ............................ 38

4.5.2 Személyes pop up küldése ............................................................................. 39

4.6 User adminisztrációs példa feladatok ................................................................... 40

4.6.1 Feladat ........................................................................................................... 40

4.6.2 Feladat ........................................................................................................... 41

4.6.3 Feladat ........................................................................................................... 41

4.6.4 Feladat ........................................................................................................... 41

4.6.5 Feladat ........................................................................................................... 41

4.6.6 Feladat ........................................................................................................... 42

4.6.7 Kérdések ........................................................................................................ 42

5 Jogosultságok, szerepkörök ......................................................................................... 42

5.1 Egyszerű szerepkör ............................................................................................... 44

5.2 Összetett szerepek ................................................................................................. 47

5.3 Jogosultságok nyomon követése ........................................................................... 48

5.4 Jogosultság kezelése és szerepkör példák ............................................................. 49

5.4.1 Feladat ........................................................................................................... 49

5.4.2 Kérdések ........................................................................................................ 49

6 Rendszer konfiguráció ................................................................................................. 49

6.1 Rendszer paraméterek konfigurációja................................................................... 49

2
 6.1.1 Feladat ........................................................................................................... 55

6.1.2 Feladat ........................................................................................................... 56

6.1.3 Kérdések ........................................................................................................ 56

6.2 Működési módok .................................................................................................. 56

6.2.1 Feladat ........................................................................................................... 62

6.2.2 Feladat ........................................................................................................... 62

6.2.3 Kérdések ........................................................................................................ 63

7 Háttérfolyamatok ......................................................................................................... 63

7.1 Háttérfolyamatok készítése ................................................................................... 64

7.2 Háttérfolyamatok monitorozása ............................................................................ 66

7.3 Ütemezett feladatok .............................................................................................. 67

7.4 Kérdések ............................................................................................................... 69

8 Backup és restore műveletek ....................................................................................... 69

8.1.1 Adatbázis és tranzakciós log mentés ............................................................. 70

8.2 Kérdések ............................................................................................................... 72

9 Tippek hogyan légy jó SAP adminisztrátor................................................................. 72

10 Hasznos tranzakciók listája ......................................................................................... 75

11 Irodalomjegyzék .......................................................................................................... 76

3
1 Bevezetés

Ebben a kurzusban megismerkedhetünk azokkal az alapvető rendszeradminisztrációs

feladatokkal, amik elengedhetetlenek egy SAP adminisztrátor számára. A kurzus előzetes

SAP GUI navigációs ismereteket feltételez, melyek az előfeltételként meghatározott

tárgyak teljesítését jelenti.

Adminisztrátorként a kezdeti feladatok egyike a rendszer installálás és konfiguráció

valamint a licence kezelés, ezzel egy stabil, biztonságos rendszer állíthatunk fel. Ezekkel

az iniciális feladatokkal az Induló lépések, Rendszer konfiguráció és Licencelés

fejezetekben foglalkozunk.

A rendszeresen ismétlődő feladatok közé tartozik például a user adminisztráció és a

jogosultság kezelés. A javaslat az, hogy ezen feladatokat két külön személy végezze, de

különösen kisebb cégek esetén erre sajnos nincs lehetőség és ezért jellemzően egy ember

felelős ezen adminisztrációs feladatokért. Ezeket a kérdéseket a User menedzsment és a

Jogosultságok, szerepkörök fejezetekben tárgyaljuk.

Egy stabil rendszer biztosítása és a túlterhelés elkerülése érdekében az adminisztrátornak

jól szervezetten kell koordinálnia a feladat ütemezést. A háttérfolyamatok létrehozásával,

monitorozásával valamint az operációs módokkal foglalkozunk a Működési módok és a

Háttérfolyamatok fejezetekben.

A váratlan, kritikus helyzetek kezelésével foglalkozunk a Háttérfolyamatok monitorozása

fejezetben. A váratlan hibajelenségek azonnali kezelésével rövidíthetjük a rendszer leállási

idejét. A rendszer folyamatos monitorozásával csökkenthetjük a nem várt események

megjelenését.

4
A legtöbb adminisztrátori feladat a rendszer alsóbb rétegéhez kötődik így ezen ismeretek

átvihetők különböző SAP rendszerek között függetlenül attól, hogy mely komponenseket

használja az adott cég.

Az adminisztrátori feladatok több területre oszthatóak a cég méreteit, kapacitását és az

iparágat figyelembe véve. Egy lehetséges felosztás lehet a következő:

- Rendszer adminisztráció: Monitorozás, rendszer konfiguráció, logon és

performancia menedzsment.

- User adminisztráció és autorizáció: Habár a két kapcsolódó terület ellátására két

külön ember javasolt legtöbbször egy alkalmazott felelős ezekért a feladatokért.

- Háttérfolyamatok kezelése: Job ütemezés, működési módok menedzselése.

- Programozói feladatok, transzport rendszer kezelése. (Bővebben az ABAP

kurzuson).

- Recovery menedzser: Elkészíti, teszteli és végrehajtja a nem tervezett leállást

követő SAP rendszert helyreállító lépéseket.

- Hálózati adminisztrátor: A hálózati elérés menedzselése és a rendszer hálózati

kapcsolatainak biztosítása, karbantartása.

- Infrastruktúra menedzser: A technikai, fizikai infrastruktúra karbantartása.

- További feladatok, mint például: backup menedzsment, rendszer biztonsági

feladatok, adatbázis adminisztráció, operációs rendszer adminisztráció, desktop

support.

5
2 Valós alkalmazások, beszámolók1

Ebben a fejezetben áttekintünk néhány, az SAP megoldások bevezetésével kapcsolatos

siker történetet. A világ minden tájáról és alkalmazási területek széles spektrumából

mintegy 100.000 SAP felhasználó alkalmaz valamilyen SAP megoldást az üzleti

folyamataiban.

A következőkben olvashatunk néhány összegzést, ami egyes cégek siker történetéről szól.

Hogyan és milyen céllal vezették be az SAP-t az üzleti és kutatási folyamataikba.

Kiemeljük az előzetesen megfogalmazódott célokat, az előnyöket és a stratégiát. Még több

beszámolót találunk a www.sap.com oldalon. Kettőt emelnénk ki ezek közül:

2.1 Heidelberg Egyetemi Kórház

A cél a beteg-orvos kapcsolat javítása volt különböző IT-alkalmazások segítségével. A

Heidelbergi Egyetem az SAP-vel és az abcmedien-vel közösen kifejlesztett egy terhes

gondozással kapcsolatos applikációt, amely nemcsak a nőket segíti és csökkenti a

különböző kockázati tényezőket, de segédkezik további kutatásokban is. Az SAP-vel és az

abcmedien-vel közös konzorciumban kifejlesztett terhességi applikáció vezető azon a

téren, hogy valós idejű adatfeldolgozást használ az SAP HANA felhő platform

segítségével valamint SAP Mobile Platform-ra is elkészült egy változat, ami egy innovatív

interfészként szolgál a Heidelbergi Egyetem számára az orvos-beteg kapcsolatot illetően.

Tekintve hogy a terhes gondozás nem igényel gyakori orvosi találkozókat, nehézkes az

kismamáktól a megfelelő visszajelzéseket összegyűjteni. A közeli kapcsolattartás az

anyákkal a terhes gondozás alatt megoldható ezen applikáció segítségével, ami a diszkrét

1
forrás: www.sap.com

6
és finoman fogalmazott pszichológiai kérdéseket intéz a felhasználók felé, hogy azonosítsa

és meggátolja az esetleges egészségügyi problémákat, mint például a depresszió.

A Heidelbergi Egyetemi Kórház Európa egyik legnagyobb vezető fejlesztő kórháza. Az ő

orvosi tudásukkal kifejlesztett terhes gondozási applikáció egy rendkívüli innováció volt,

ami azonban rengetek valós idejű adat felhőben történő analizálásával és tárolásával járt.

Ezt figyelembe véve egy nagy kihívást jelentett, éppen ezért választották a terhes

gondozást, mint elsődleges célját az fejlesztendő applikációnak. Tekintve hogy a terhesség

nem betegség, több időt eltölthetnek a megfigyeléssel, a folyamat alakításával, így később

lehetőségük lesz olyan hasonló alkalmazás kifejlesztésére, amellyel komoly betegségben

szenvedő betegeket is segíthetnek.

2.2 Bangkok Airways légitársaság

Manapság általános, hogy negatív légi utazási tapasztalatokról olvashatunk a hírekben, a

jegyáraktól elindulva egészen a szegényes reptéri és fedélzeti szolgáltatásokat is beleértve.

Másrészről a Bangkok Airways célul tűzte ki magának, hogy ügyfeleinek minden utazás

alkalmával örömteli élményeket szerezzen már attól a pillanattól kezdve hogy

megérkeznek a reptérre.

Bangkok Airways sokat fektetett abba, hogy kiépítse és fenntartsa a saját privát-

üzemeltetésű reptereit Samui, Sukhothai, és Trat városokban. Ezek a fejlesztések Ezek a

beruházások újabb légi közlekedési csomóponttal látják el Tájföldet annak érdekében hogy

megkönnyítsék az egyre növekvő légi forgalom kezelését.

Kiemelkedően fontos volt számunkra az üzemeltetési költségek megfelelő kezelése annak

érdekében, hogy az ügyfeleiknek a legjobb árat kínálhassák. A Bangkok Airways egy 45

7
éves saját fejlesztésű applikációkból álló infrastruktúrával rendelkezett a manuális

pénzügyi műveleteket illetően. Ez lehetetlenné tette, hogy valós időben láthassák a

pénzügyi tranzakciókat és elemezhessék bármely érintett területet. Azaz lehetetlen volt a

küldetésüket valóssá tenni.

Az SAP Consulting Services-ve, mint implementációs partnerrel a Bangkok Airways

igyekezett megvalósítani az elképzeléseit, melynek jelmondata: “pleasantry to the

passengers on every flight”. Ennek hátterében az SAP HANA által támogatott IT

fejlesztések álltak.

A nagy adatok mobilitással való kombinálása, a manuális helyreigazítások, mint a járat

késések vagy last minite útvonal módosítások egyszerre könnyen kezelhető folyamatokká

váltak.

Az integrált és a továbbfejlesztett külső folyamatokkal a Bangkok Airways mobil

kommunikációs lehetőségeket kínál az ügyfelei számára a többek között a

járatmódosításokhoz.

Az SAP HANA rendszerükhöz kapcsolt mobil applikációk által a Bangkok Airways

könnyen bepillantást nyerhet a pénzügyi tranzakciókba. Az applikáció az alkalmazottak

számára lett fejlesztve különös tekintettel azokra, akik a járatok menetrendjével

foglalkoznak, vagy a költségeket regisztrálják. Ami régebben manuálisan működött,

hosszadalmasan, papír alapon az most azonnali. A cégnek lehetősége van a költségek valós

idejű rögzítésére, azonnali betekintést nyerni a tranzakciók következményeire és rögtön

elemezni a járatokhoz vagy műveletekhez kapcsolódó veszteségeket vagy nyereségeket.

8
Az SAP HANA által nyújtott valós idejű kezelés által a Bangkok Airlines most a felesleges

költségek lefaragásával, jól szervezetten végzi az adatelemzéseit. Sőt, versenyképes és az

ügyfelek számára elérhető árakat tudnak kínálni.

3 Bevezetés az SAP rendszerüzemeltetésbe

3.1 SAP megoldások

Az SAP számos megoldást kínál a különböző nagyvállalatok számára. Mivel a vállalatok

igényei különböznek egymástól, nem igazán lehet két teljesen egyforma SAP rendszert

találni. A vállalatok méreteihez és ipari jellegéhez igazodva az SAP az alábbi

lehetőségeket kínálja:

 SAP Business One

”Megfizethető, bővíthető kisvállalati szoftver. Elsősorban növekvő vállalatoknak

ajánlott (100 körüli alkalmazott szám), akik a pénzügyi, HR és kereskedelmi

folyamataikat szeretnék könnyen kezelni.

 SAP ByDesign

Iparági csomagok, melyek kis és középvállalkozásoknak ajánlottak (100-500

alkalmazott körül) akik igény szerint kialakított megoldásokat keresnek a vállalati

folyamatok menedzseléséhez. A csomag az egyes iparágak jellemző folyamataival

rendelkezik. Az SAP több mint 550 különböző iparági csomagot kínál, amik az

iparági sztenderdeken túl egyedi folyamatok kezelését is lehetővé teszik. (pl.: SAP

for Media, SAP for Healthcare, SAP for Aerospace and Defense, stb.)

 SAP All-in-One

9
 Teljes körű megoldás nagyvállalatok számára (2500 fölötti alkalmazott) valós idejű

folyamatkezeléssel. Az iparági alkalmazások teljes spektrumát valamint az SAP

NetWeaver által támogatott technológiai platformot kínál ez a verzió.

 SAP Business Suite

Elsősorban olyan vállalatoknak ajánlott, akik igényei eltérnek az iparági

szabványoktól vagy éppen speciális egyedi alkalmazásokat igényelnek az iparági

sztenderdeken túl.

A fenti kategóriák áttekinthetőek a 1. ábra: SAP ábrán. Nagyon fontos, hogy a vállalat
számára leginkább megfelelő megoldást válasszuk. Az SAP weboldalán segítséget
kaphatunk, és könnyen megtalálhatjuk a számunkra legjobb opciót az SAP fitting room
használatával (http://sapbusinessonecalc.com/fittingroom/).

10
 1. ábra: SAP megoldások

3.2 Induló lépések

Ha megtaláltuk a leginkább alkalmas SAP rendszert, a következő dolgunk a bevezetése

lesz. Erősen ajánlott, hogy az SAP instanciákat tartalmazó servert csak erre a célra

használjuk. Néhány a legfontosabb rendszerkövetelmények közül:

- Windows 7 64 bit Professional vagy Windows Server 2008 operációs rendszer,

- ajánlott 4 GB RAM vagy több,

- 45 GB tárhely kapacitás, stb.

Részletes tájékoztatást a rendszer telepítésekor kapunk. Szükségünk lesz továbbá a

MaxDB Database Manager-re is. Telepítés után az adatbázis servert és a hozzá tartozó

Master jelszót kell beállítanunk. Itt meg kell említeni, hogy az SAP alapértelmezés szerint

nem írja felül tranz.log fájlt, ami a későbbiekben azt a hibát okozhatja, hogy az

11
adatbázisunk és az egész SAP rendszerünk leáll. Újraindításra csak az elegendő memória

mennyiség felszabadítása után van lehetőség, így ajánlott, hogy még ezen a ponton

gondoskodjuk erről a beállításról. Ehhez vagy azt tehetjük, hogy rendszeresen ellenőrizzük

és ürítjük a fájl tartalmát, vagy pedig engedélyezzük a felülírást a Database Manager-ben.

Tekintsünk néhány alapvető fogalmat, amik szükségesek lesznek a tananyag további

részének elsajátításakor:

- Adatbázis szerver: Ez a szerver tartalmazza az SAP rendszerünk komponenseit

valamint az adatbázist.

- Applikációs szerver: Ez a szerver tartalmazza az SAP alkalmazásokat.

Elkülöníthetünk applikációs szervereket az online felhasználóknak, a

háttérfolyamatoknak, de kezelhetjük egy szerveren is ezeket.

- Instancia: Egy instancia az SAP alkalmazás egy adott serverre telepített példányát

jelenti. Megkülönböztetünk centrális és dialóg instanciákat, ahol a centrális

instancia tartalmazza az adatbázist és csupán egy létezik belőle egy rendszeren

belül. Dialóg instanciából többet is létrehozhatunk akár egy fizikai serveren is. Az

applikációkat foglalja magában.

- SAP rendszer: A rendszer alatt egy teljes system ID (SID)-val ellátott SAP

installációt értünk. Az SAP rendszer logikailag magában foglalja a dialóg és a

centrális instanciákat, fizikailag tartalmazza az adatbázis szervert és az applikációs

szervereket.

- Kliens: A kliensek a napi tranzakciók által generált különböző applikációs adatokat

tartalmazzák egy rendszeren belül. Az SAP rendszerbe egy bizonyos kliensen

keresztül tudunk bejelentkezni. Például egy szervezet különböző részlegeihez

12
 tartozó applikációs adatok különböző saját kliensekhez tartozhatnak. A kliensek

osztoznak a rendszer erőforrásain, mint az adatbázis vagy az ABAP Dictionary.

3.2.1 Kliens adminisztráció

A kliens, ahogy azt már említettük korábban, egy technikailag különálló egység az SAP

rendszeren belül. Bár a különböző kliensek osztoznak az adattárházon, egyéni beállításokat

implementálhatnak. Éppen ezért használjuk leginkább adatok elkülönítésére azokat.

Kliens készítése

Normál esetben a kliens definíciós folyamat a következő lépésekből áll:

1. Indítsuk el az scc4 tranzakciót, hogy elérjük a kliens tábla adatait. .

2. Kattintsunk a Change gombra.

3. A felugró ablakban válasszuk a Continue gombot.

4. Hogy egy új kliens tábla bejegyzést hozzunk létre, kattintsunk a New Entries

gombra.

5. Töltsük ki a szükséges mezőket, mint például a kliens azonosító, ami egy három

számjegyből álló egyedi kód. A 000, 001, 066 kódok a rendszer számára fent tartott

védett klienseket jelölik. Végül kattintsunk a Save gombra.

6. Egy felugró ablak értesít minket arról, hogy az új kliens elkészült.

Kliens másolása

A kliens másolás egy jó opció, amikor egy meglévőhöz hasonló beállításokkal vagy

adatokkal rendelkező kliens szeretnénk létrehozni. Ez a művelet nem fogja átmásolni a

kliens specifikus adatokat, mint például az ABAP programok, vagy a tábla struktúra. A cél

kliensnek nem feltétlenül kell azonos rendszerben lennie. Nagy adathalmazok esetén a

13
másolás órákat is igénybe vehet, ezen időszak alatt minden felhasználót zárolnunk kell és

minden ütemezett feladatot el kell távolítanunk annak érdekében, hogy ne jelenjen meg

inkonzisztencia.

Nézzük lépésről lépésre a lokál kliens másolásának folyamatát:

1. Indítsuk el az SCCL tranzakciót.

2. A megjelenő Client Copy screen képernyőn válasszuk ki a profile-t a megfelelő

mezőben, ezzel definiáljuk azon adattípusokat, amiket másolni szeretnénk.

3. Adjuk meg a háromjegyű kliens azonosítót.

4. Ütemezzük a feladatot háttérfolyamatként, a Scheduled as background job gombra

való kattintással.

5. Adjuk meg az futás időpontját pont úgy, mint ahogy azt bármely más

háttérfolyamat esetén tennénk. (lásd Háttérfolyamatok készítése fejezetben).

6. Kattintsunk a Save gombra.

7. Ellenőrizzük a másolási beállításokat a megjelenő dialóg ablakban, majd

kattintsunk a Continue gombra.

Miután visszaigazoltuk a létrehozott ütemezett kliens másolási feladatot, az

háttérfolyamatként fog lefutni a megadott időpontban. A jobot nyomon követhetjük az

sm37 (Job Monitor) tranzakció segítségével.

Amennyiben egy másik rendszerben lévő klienst szeretnénk másolni, az egy kicsit több

adminisztrációs munkával jár. Az scc9 tranzakcióban nem csak a másolási profilt

hanem a forrás rendszerhez csatlakozó RFC kapcsolatot is meg kell adnunk.

Kliens törlése

14
 Egy kliens törléséhez először be kell jelentkezzünk az adott kliensre, és a következő

lépéseket kell végrehajtanunk:

1. Indítsuk el az scc5 tranzakciót.

2. A kliens tábla bejegyzést is el kell távolítanunk, ezért aktiváljuk a Delete entry from

T000 jelölőt.

3. Ütemezzük a háttérfolyamatot hasonló módon, mint az előzőekben említett jobok

esetén.

Miután ez a folyamat lefutott többé már nem érhetőek el a kliens specifikus adatok.

Csak abban az esetben futtassuk ezt a műveletet, ha biztosak vagyunk benne, hogy

többé már nincs szükségünk az itt jelen lévő adatokra. Tanácsos egy backup készítése a

teljes adatbázisról.

3.3 Az SAP rendszer indítása, leállítása

Egy SAP rendszer három rétegből áll (operációs rendszer szint, adatbázis réteg,

applikációs réteg), melyek jól meghatározott módon egymásra épülnek. Ezért a

rendszerindítás egy jól meghatározott lépésekből álló folyamat kell, hogy legyen, hiszen az

egyes rétegek nem képesek elindulni, ha az alattuk szereplő rétegek még nem aktívak.

A következő táblázatban láthatjuk a három rétegű rendszer egy áttekintését:

1. Táblázat: Az SAP rendszer három rétegű felépítése

Réteg Fizikailag SAP instancia Mit futtatunk rajta?

Operációs Asztali gépek - SAP GUI – felhasználói felület
rendszer
Adatbázis réteg Önálló adatbázis Dialóg Adatbázis: SQL szerver, DB2,
szerver instancia Oracle, stb.

15
Applikációs Applikációs Centrális SAP rendszer
réteg szerver(ek) instancia

Azaz az első lépés az operációs rendszer indítása, ami az adatbázis és applikációs réteg

alapjait szolgáltatja. Biztosítja, hogy a fizikai erőforrások az SAP rendszerünk

rendelkezésére álljanak.

Minden adat a SAP adatbázisban kerül tárolásra, ami a SAP komponenseket is tartalmazza.

Mielőtt elindul egy instancia, már egy aktív adatbázissal kell rendelkezni, hogy a benne

tárolt információk elérhetővé váljanak.

Egy SAP instancia csak akkor indítható, ha az operációs rendszert és az adatbázist már

megelőzően elindítottuk. Az instancia (vagy applikációs server) egy SAP rendszeren

belüli adminisztrációs egységként írható le. A centrális instancia pontosan egy adatbázist

és egy vagy több dialóg instanciát tartalmaz. Az adatbázis és az instanciák lehetnek ugyan

egy serveren, de javasolt, különösen robosztus rendszerek esetén, a szétválasztásuk.

Az utolsó fázisban a centrális instancia (message server és dispatcher) indul először. Két

féle instancia típust különböztethetünk meg:

- Centrális instancia (egy rendszeren belül egy) ami az adatbázist tartalmazza.

- Dialógus instanciák. Egy SAP rendszer több dialóg instanciát tartalmazhat egy

azon fizikai szerveren de érdemes ezeket elkülönítve az adatbázist tartalmazó

servertől különböző hoston tárolni. A rendszer minőségének emelése érdekében

instancia klasztereket hozhatunk létre, amelyekhez külön servereket rendelhetünk,

de emellett ugyanazon adatbázissal dolgozhatnak.

16
3.3.1 SAP rendszer indítása SAP MMC-ben

1. Jelentkezzünk be adminisztrátorként az operációs rendszerünkbe. Azaz indítsuk el

az operációs rendszert és a szervert.

2. Ezen a ponton lehetőségünk van az adatbázis manuális elindítására, bár ez a lépés

nem feltétlenül szükséges, hiszen a start script automatikusan elindítja azt, amikor

az SAP rendszert indítjuk.

3. Microsoft Windows alatt használjuk az SAP Management Console (MMC) –t.

(Lásd) 2. ábra: SAP rendszer indítása SAP Management Console-ban

2. ábra: SAP rendszer indítása SAP Management Console-ban

Az SAP Management Console csak Microsoft operációs rendszeren installálható,

más rendszerben használjuk a startsap konzol utasítást.

17
 4. Válasszuk ki a rendszert (pl: NSP) vagy a centrális instanciát (pl: S-PC) amit

indítani szeretnénk. Utóbbi esetben egy ellenőrzés történik az adatbázis

elérhetőségére, és ha szükséges az SAP automatikusan elindítja azt. Néhány percet

is igénybe vehet, amíg a rendszer elindul. A start gombra kattintva az SAP MMC

egy timeout intervallumot kér tőlünk, ami azt definiálja, hogy mennyi időt vagyunk

hajlandóak várni az SAP instancia elindulására. A definiált időintervallum

elteltével az instanciát nem fogja elindítani.

5. A megjelenő dialóg ablakban adjuk meg az adminisztrátori felhasználó nevet és

jelszót. Csak adminisztrátori jogkörrel indíthatunk és állíthatunk le egy SAP

rendszert.

6. Az SAP MMC a rendszer vagy instancia státusát a következő színezett ikonokkal

jelzi:

- Szürke ikon: Nem fut

- Sárga ikon: Indítás folyamatban

- Zöld ikon: Aktív

- Piros ikon: hiba miatt befejeződött

SAP rendszer indításakor egy instancia specifikus profil definiálja, hogy pontosan milyen

folyamatokat kell aktiválni. Ez a profil megtekinthető és szerkeszthető jobb kattintással az

instancián majd az All tasks  View Start profile pontot választva.

Az SAP rendszerbe való bejelentkezés csak akkor lehetséges, amikor már a rendszer aktív,

amit a zöld ikon is jelez, ekkor megjelenik a logon screen.

Az indításkor bekövetkezett esetleges hibák felől az adminisztrátor a start log fájlban

tájékozódhat. Ez a fájl operációs rendszer szinten a /usr/sap/<SID>/<Instance>/work

18
mappában található sapstart.log néven, (továbbá a sapstartsrv.log, dev_disp, dev_ms,

dew_w0) vagy bejelentkezés után az sm21 tranzakció tájékoztat a hibákról.

3.3.2 A rendszer leállítása SAP MMC-ben

Előfordulnak olyan helyzetek, tervezett vagy nem várt események, amik következtében a

rendszer leállítása, újraindítása szükségessé válik, mint például hardware karbantartás,

profil paraméter változtatás, vagy teljes backup. Ez egy kritikus folyamat, mert minden

aktív felhasználóra és futó folyamatra hatással van, így körültekintő tervezést igényel. A

rendszer leállítás javasolt lépései:

1. Tájékoztassuk az érintett alkalmazottakat egy rendszer üzeneten keresztül és kérjük

őket, hogy jelentkezzenek ki a rendszerből. (Lásd később a Jelszavak kezelése

2. Mint az előzőekben említettük új felhasználót csak jelszóval (generált vagy

adminisztrátor által megadott) ellátva hozhatunk létre, mely jelszót az első

bejelentkezéskor a felhasználónak módosítani kell.

A jelszavak adminisztrátor által történő módosítása lehetséges, ennek legtöbbször az az

oka, hogy az adott felhasználó elfelejtette a jelszavát, vagy túllépte a sikertelen

bejelentkezési kísérletek megengedett számát. Nagyon fontos, hogy csak biztosan

azonosított felhasználói kérésre végezzünk jelszó módosítást.

A jelszó újragenerálásának menete a következő:

1. Indítsuk el a su01 tranzakciót.

2. Adjuk meg a felhasználó azonosítóját, akinek a jelszavát módosítani szeretnénk.

3. Kattintsunk a Change Password gombra.

19
 4. A megjelenő dialóg ablakban válasszuk a Generate Password gombot, hogy egy új

véletlenszerűen generált jelszót hozzunk létre a felhasználó számára. (Esetleg

kézzel is megadhatunk egy új jelszót, ebben az esetben a jelszó ismétlése

szükséges. A véletlenszerűen generált jelszavak bizonyos tulajdonságait

rendszerparamétereken keresztül definiálhatjuk. Ilyen például:

- A jelszó maximális hossza (GEN_PSW_MAX_LENGTH)

- A számjegyek maximális száma a jelszóban (GEN_PSW_MAX_DIGITS)

- A betűk maximális száma a jelszóban (GEN_PSW_MAX_LETTERS)

- A speciális karakterek maximális száma a jelszóban

(GEN_PSW_MAX_SPECIALS)

5. Kattintsunk a Transfer gombra.

3. Rendszeradminisztrátori üzenet küldése fejezetben)

4. Mielőtt leállítanánk a rendszert, győződjünk meg róla, hogy minden felhasználó

kijelentkezett. Az sm04 tranzakcióval személyes figyelmeztető üzenetet

küldhetünk a még aktív felhasználóknak.

5. Ellenőrizzük az éppen futó és a leállás idejére ütemezett folyamatokat az sm50 és

az sm37 tranzakcióval. (Lásd: Háttérfolyamatok monitorozása fejezet)

6. Az smgw tranzakcióval az aktív RFC kapcsolatokat ellenőrizhetjük.

Javasolt egy lista készítése a leállítás előtti teendőkről, hogy ne maradjon ki egy kritikus

lépés sem. (Lásd: Tippek hogyan légy jó SAP adminisztrátor fejezet)

Most nézzük a rendszer leállításának lépéseit:

1. Windows operációs rendszerben indítsuk el az SAP Management Console –t.

2. A listából válasszuk ki a rendszert, amit le szeretnénk állítani.

20
 3. Jobb kattintás a kiválasztott elemen (instancia név vagy rendszer ID) majd

kattintsunk a stop-ra. Itt nem fontos az adatbázist is leállítani, a későbbi rendszer

indítást gyorsíthatjuk azzal, ha nem állítjuk le ezen a ponton az adatbázist, hanem a

tervezett leállás ideje alatt hagyjuk futni.

4. A megjelenő dialógus ablakban ki kell választanunk a leállítás típusát: (Lásd: 3.

ábra: Rendszer leállítás típusa dialóg ablak):

- Hard (SIGNIT): Ebben az esetben a rendszer azonnal leáll.

- Soft (SIGQUIT/SIGNIT): Egy megadott timeout intervallumon belül a

rendszer megkísérli a leállást, de ha túllépi a fenti opció (Hard

shutdown) lép életbe.

5. A rendszer adminisztrátori bejelentkezést kér.

Ezzel a rendszert vagy a rendszert és az adatbázist is leállítottuk

3. ábra: Rendszer leállítás típusa dialóg ablak

21
 3.4 Első bejelentkezés

A rendszer telepítésekor az SAP automatikusan definiálja a következő felhasználókat:

(su01) (Lásd 4. ábra: Alapértelmezett userek):

 SAP* : SAP rendszer super user

 DDIC : ABAP dictionary objektumok és software logisztikai szuper user

 SAPCPIC: kommunikációs user

 BCUSER: fejlesztő user (licence függő)

4. ábra: Alapértelmezett userek

Az alapértelmezett userek védelmében a további super userek létrehozása a sap* user

másolásával javasolt, majd az sap* user deaktiválása ajánlott.

Jelentkezzünk be az SAP rendszerünkbe az SAP GUI (SAP Graphical User Interface)-n

keresztül. Az SAP GUI eléréséhez indítsuk el az SAP Logon programot (Lásd ábra: SAP

Logon program).

22
 5. ábra: SAP Logon program

Itt láthatjuk az elérhető servereket (ábrán: NSP local) és azok leírását, mint például a SID

(system ID, server, instancia szám). Válasszuk ki a rendszert, amibe be szeretnénk

jelentkezni, majd kattintsunk a Log On gombra a képernyő bal felső sarkában vagy

kattintsunk duplán az adott server nevén.

6. ábra: SAP Logon képernyő

23
Megjelenik a Logon képernyő (Lásd: 6. ábra: SAP Logon képernyő), ahol be tudjuk állítani

a mandant ID-t (kliens) (rendszeren belüli szeparációs egység) és ki kell töltenünk a

felhasználói név és jelszó mezőket, továbbá lehetőségünk van nyelvi beállításra is,

amennyiben a kívánt nyelv támogatott és telepítve van a rendszerben. Telepítés után a

rendszer 3 mandantot tartalmaz: (scc4):

- 000: SAP sztenderd referencia mandant, ami tartalmazza a különböző érték

táblákat, az egyéni beállításokat, stb.

- 001: SAP konfigurációs mandant. Miután minden konfigurációs műveletet

elvégeztünk erősen ajánlott, hogy készítsünk egy biztonsági másolatot erről a

mandantról (pl.: 100) ami a működő kliens lesz.

- 066: early watch reportokat tartalmaz.

Első bejelentkezéskor a kezdő jelszót meg kell változtatnunk. Lehetőségünk van

párhuzamosan több munkaablakban bejelentkezni, de biztonsági és licence okok miatt nem

ajánlott. Ehelyett inkább javasolt, hogy kattintsunk a gombra vagy válasszuk a

System  Create Session pontot vagy a Ctrl+N billentyűkombinációt. Sikeres

bejelentkezés után automatikusan megjelenik a saját személyre szabott SAP Easy Access

menünk. Első bejelentkezéskor a függvények legenerálódnak, itt beállíthatjuk a

leggyakrabban használt tranzakciókat és a többi majd az első használatkor vagy

manuálisan az sgen tranzakcióban generálható.

A munkánk befejeztével a kijelentkezés több módon történhet:

- Kijelentkezés a menüsor használatával: Válasszuk a System  Log off parancsot.

- Az SAP Easy Access menüben válasszuk a sárga nyíllal ellátott ikont. Amennyiben

több sessiont futtatunk, ez az ikon csak az aktív ablakot fogja bezárni.

24
 - Adjuk ki a /nend parancsot a SAP parancssorban.

- Amennyiben az rdisp/gui_aouto_logout rendszerparaméter megfelelően

van beállítva, a rendszer automatikusan kilépteti az egy ideje nem aktív

felhasználót.

A megjelenő dialóg ablakban a rendszer figyelmeztet, hogy a nem mentett adataink el

fognak veszni és megerősítését kéri a kijelentkezési szándékunknak. Válasszuk az Igen

gombot a kijelentkezéshez.

3.5 Licencelés

Amennyiben érvényes licence-szel rendelkezünk, de a lejárati idő 14 napnál közelebbi, a

rendszer figyelmeztet minket. Ebben az esetben a “Sneak Preview License Key Request”

weboldalon (lásd 7. ábra: Sneak Preview License Key Request sablon) kitöltjük a kért

információkat, mint például a személyes adatok és a rendszer információk valamint a

hardware kulcs az SAP által automatikusan generált ID, amit az slicense tranzakcióban

találunk. (Lásd 8. ábra: Új licence telepítése).

25
 7. ábra: Sneak Preview License Key Request sablon

Az SAP License Administration képernyőn megtaláljuk a hardware kulcsunkat (Active

Hardware Key). A form kitöltése és beküldése után az SAP elküld részünkre egy NSP.txt

licence fájlt.

26
 8. ábra: Új licence telepítése

Válasszuk a New Licenses majd az Install gombot, ezután tallózzuk ki az NSP.txt fájlt,

aztán kattintsunk a confirm gombra. Egy felugró ablak tájékoztat az SAP licence sikeres

telepítéséről és a lejárati dátum frissítéséről.

3.5.1 Feladat

1. Jelentkezzen be az SAP rendszerbe és listázza ki a felhasználókat!

2. Ellenőrizze a licence lejárati időt!

27
3.5.2 Kérdések

1. Milyen SAP megoldást ajánlanál az alábbi paraméterekkel rendelkező cégnek:

o Jelenleg excelben és papír alapon intézik az adminisztrációs ügyeket.

o Az alkalmazottak száma megközelítőleg 100 fő.

o Ipari specifikus folyamatokat használnak.

2. Mik a legfontosabb rendszer követelmények az SAP rendszer telepítésekor?

3. Mely kliensek szerepelnek a rendszerben alapértelmezetten?

4. Mutassa be az SAP rendszerek három rétegű struktúráját?

5. Hogyan állíthatunk le egy SAP rendszert?

4 User menedzsment

Egy adminisztrátornak fontos feladata, hogy megfelelő hozzáféréssel és jogosultságokkal

rendelkező felhasználókat hozzon létre a rendszerben. Ebben a részben a felhasználó

kezelés alapjairól lesz szó, bemutatjuk az alapvető user adminisztrációs feladatokat, mint a

felhasználó létrehozása, másolása, felhasználói csoportok létrehozása és autorizáció

kezelés.

A felhasználó adminisztrációs feladatok dokumentálása egy igen fontos feladat. Egyrészt

rendszer-biztonsági szempontból, hiszen minden újabb hozzáférés a rendszerhez egy

potenciális problémaforrás lehet, másrészt a rendszer felhasználóit átfogó feladatok nagyon

komplexek és ezért szükséges a jól átlátható struktúra, dokumentáció.

Egy user adminisztrátor legfontosabb feladatai:

28
  Név konvenciók létrehozása a felhasználó azonosítókhoz (pl: dolgozó azonosító, a

felhasználó neveinek egyes karakterei, ideiglenes felhasználók és konzulensek

megkülönböztetése, egyéb speciális konvenciók.)

 Felhasználók létrehozása, módosítása (Lásd: Felhasználó létrehozása fejezet).

 User aktiválása (Unlock) és zárolása (Lock).

 Felhasználó törlése vagy deaktiválása.

4.1 Felhasználó létrehozása

Egy új felhasználó létrehozásával egy új elérési pontot nyitunk a rendszer felé. Ez egy

kritikus pontja a rendszer üzemeltetésnek, éppen ezért rendkívül fontos a pontos

dokumentáció. Egy felhasználó regisztrációs igénylésnek fontos tartalmaznia az alábbi

információkat:

- A hozzáférést igénylő alkalmazott felettesének aláírását.

- Az új felhasználó számára látható és módosítható adatokat kezelő szervezeti

egységek vezetőinek beleegyező nyilatkozatát.

- Ideiglenes felhasználó esetén az érvényességi időtartam kezdetét és végét.

- Az adminisztrátor szintén aláírásával jelzi, hogy elvégezte a kért regisztrációt.

További felhasználókat készíthetünk és másolhatunk meglévőeket felhasználva a su01

tranzakcióban.

Felhasználó másolása hasznos lehet, amikor egyszerre több, azonos tulajdonsággal

rendelkező usert szeretnénk létrehozni egy sablon alapján. Kiválaszthatóak azon

felhasználói adatok, melyeket másolni szeretnénk.

29
 1 Hívjuk a su01 tranzakciót vagy válasszuk a Tools  Administration 

User Maintenance  Users.

2 Válasszuk ki a felhasználót (sablont) amelyet másolni szeretnénk.

3 Válasszuk a Copy (Shift+F5) gombot.

4 Adjuk meg a referencia és az új felhasználó nevét, ügyelve a név

konvenciókra.

5 Aktiváljuk azokat a check boxokat, amelyeket másolni szeretnénk a két user

között. (Lásd 9. ábra: Létező user másolása).

6 Zárjuk be a dialógus ablakot a copy gombbal.

7 A rendszer előhozza a Maintain User képernyőt, ahol további szerkesztési

lehetőségekkel találkozunk.

9. ábra: Létező user másolása

Felhasználó létrehozása:

1 Indítsuk el a su01 tranzakciót vagy Tools  Administration  User

Maintenance  Users.

30
 2 Adjuk meg a felhasználó nevet és kattintsunk a gombra.

3 A Maintain user képernyő megjelenik, ahol a jelölővel ellátott mezőket

kötelező kitölteni, a többi opcionális. (Kötelező mezők: Last name az

Address fülön, Initial password és ismétlése a Logon data fülön.)

4 Mentés után az új felhasználó már aktív el elérhető.

A Maintain User képernyő felépítése:

 Address fül:

- Személyes információk

- Kontakt információk

- Cég adatok

 Logon Data

A felhasználó típusa:

- Dialog: Ez a típus egy konkrét felhasználót jelöl, aki számára bármilyen típusú

bejelentkezés megengedett. A felhasználó önmaga változtathatja a jelszavát,

párhuzamos bejelentkezés ellenőrzött és szükséges esetén blokkolt.

- System: Belső rendszer folyamatok számára létrehozott user típus. A GUI használat

nem lehetséges. A jelszó csak az adminisztrátor által változtatható, a párhuzamos

bejelentkezés nem megengedett.

- Communication: Rendszerek közti dialógus mentes kommunikáció

megvalósítására szolgáló user típus. Dialógus bejelentkezés nem megengedett, a

jelszó megváltoztatás lehetséges a user számára.

31
 - Service: Egyfajta dialog felhasználó, amely egy anonymus, nagy felhasználó

csoportot jelöl tipikusan limitált autorizációval. A jelszó változtatása csak az

adminisztrátornak megengedett, a párhuzamos bejelentkezés lehetséges.

- Reference: A service felhasználóhoz hasonlóan nem egy konkrét személyt jelöl,

hanem további autorizációs jogokat. A Roles fülön ezzel a típussal adhatunk

további jogokat egy dialog felhasználó számára.

Password:

- Megadhatunk vagy generálhatunk egy véletlen kezdő jelszót. Rendszer védelmi

szempontból ahol lehetséges generált kezdeti jelszavakat alkalmazzunk.

- A felhasználói jelszó újradefiniálása is itt lehetséges.

User group:

- A felhasználókat már létező felhasználó csoportokkal rendelhetjük össze itt.

Validity period:

- Külső konzultánsoknak fenntartott felhasználók esetén adható ideiglenes/időszakos

érvényességi időszak.

 Defaults fül:

Itt állíthatjuk be az alapértelmezett bejelentkezési nyelvet (a már telepített nyelvek

közül).

A nyomtató beállításokat megadhatjuk a Spool control boxban valamint egyedi

időzónát rendelhetünk a felhasználóhoz.

 Parameters fül:

A vonatkozó paraméter értékeket definiálhatjuk.

 Roles fül:

32
 A szükséges autozirációkat rendelhetjük a userekhez, továbbá ezekhez

érvényességi időszak is megadható.

 Group fül:

Beállíthatunk egy felhasználói csoportot, amihez hozzá szeretnénk rendelni a usert.

4.2 Felhasználó menedzsment

Felhasználó zárolása/feloldása:

3 egymás utáni elrontott jelszó miatti belépési hiba esetén a rendszer automatikusan zárolja

a felhasználót, amelyről tájékoztat is. (Lásd: 10. ábra: Zárolt felhasználó (túl sok hibás

belépési kísérlet)) Ez a limit módosítható a login/fails_to_user_lock rendszer paraméter

értékének átírásával.

10. ábra: Zárolt felhasználó (túl sok hibás belépési kísérlet)

Egy másik, megfelelő autorizációval rendelkező user feloldhatja a zárolást az alábbi

módon:

1. Indítsuk el a su01 tranzakciót.

2. Válasszuk ki a feloldani kívánt felhasználót.

3. Kérjük le a felhasználói információkat. A Logon data fülön láthatjuk a felhasználó

jelszavának jelenlegi státuszát. (Lásd 11. ábra: Zárolt felhasználó )

4. A User maintenance Initial screen képernyőn válasszuk a Lock/Unlock user

nyomógombot (vagy Ctrl+F5). Egy dialóg ablak tájékoztat a felhasználó

33
zárolásának okáról. Zárjuk be az ablakot az unlock gombbal (Lásd 12. ábra:

Felhasználó feloldása).

11. ábra: Zárolt felhasználó logon adatai

34
 12. ábra: Felhasználó feloldása

Hasonló módon tudja az adminisztrátor zárolni a felhasználókat (például biztonsági

okokból a SAP* felhasználót).

Különböző user-adatokat érhetünk el a felhasználói információs rendszeren keresztül

(suim tranzakció), ami a user master rekord egy áttekintését nyújtja. Itt ellenőrizhetjük

például mely felhasználók kerültek zárolásra és mikor. A felhasználókat listázhatjuk a

bejelentkezési időpontjuk vagy a legutóbbi jelszó módosításuk alapján. A felhasználókhoz

rendelt jogokat áttekinthetjük, és ezek módosításait monitorozhatjuk.

Felhasználók összevont karbantartása:

Bizonyos helyzetekben nagy segítség lehet, ha a felhasználókat nem kell egyenként

kezelni, hanem bizonyos módosításokat elvégezhetünk a felhasználók egy csoportján egy

lépésben (su10 tranzakció). Például ha egy új részleghez kell hozzárendelni a dolgozókat,

vagy bizonyos cégadatok megváltoznak, esetleg az ideiglenes felhasználók érvényességi

idejét szeretnék beállítani vagy egy egész csapatot zárolni egy munka befejeztével.

35
Az összevont karbantartás lépései:

1. Indítsuk el a su10 tranzakciót.

2. Adjuk meg a felhasználó azonosítókat melyekhez tartozó adatokat módosítani

szeretnénk, majd kattintsunk a gombra.

3. Válasszuk ki a fület ahol módosítani szeretnénk, adjuk meg az adatokat majd

aktiváljuk a Change checkbox-ot.

4. Mentsük el a módosításokat.

5. Erősítsük meg a változtatásokat a Mass changes dialógus ablakban.

4.3 Felhasználó csoportok

A user adminisztráció nélkülözhetetlen eszközei a felhasználói csoportok (user group-ok),

azaz valamilyen szempont alapján összetartozó felhasználók egy logikai csoportja. Például

egy bizonyos részleg dolgozói, hasonló pozícióban dolgozó alkalmazottak. Valamint

hasznos lehet az ideiglenes felhasználókat vagy adminisztrátorokat is egy csoportba

összegyűjteni, hogy a kezelésük ezáltal egyszerűbb legyen. A gyakorlatban az alábbi

csoportok használata a leginkább jellemző és ajánlott:

- TERM: Ezen csoport tagjai a már nem aktív felhasználók, a csoport tagjait zárolni

kell.

- SUPER: A teljes körű autentikációval rendelkező userek csoportja.

- TEMPLATE: Sablon felhasználók, amelyek profilja egy másolási sablonként

szolgál az aktuális felhasználók létrehozásakor.

36
Egy felhasználó több felhasználói csoport tagja is lehet (pl.: egy részleg vezetőjét nem csak

a részlegéhez, de a vezetői csoporthoz is hozzá lehet rendelni. Meg kell jegyeznünk, hogy

felhasználókat csak már korábban létrehozott csoportokhoz rendelhetünk.

Felhasználói csoportok a sugr tranzakcióval készíthetünk az alábbi műveleteket követve:

1. A tranzakciós képernyőn adjuk meg a csoport nevét, amelyet újonnan definiálni

szeretnénk, majd kattintsunk a new gombra, így eljutunk a Maintain user group

képernyőre.

2. A szöveges mezőben adjunk egy rövid leírást a csoportról.

3. Felhasználókat a User assignment résznél adhatunk a csoporthoz. (A su01

tranzakcióval – Groups fülön szintén adhatunk további felhasználókat a

csoporthoz.)

4. A save-re kattintva a rendszer visszaigazolja, hogy a csoport sikeresen elkészült.

4.4 Jelszavak kezelése

Mint az előzőekben említettük új felhasználót csak jelszóval (generált vagy adminisztrátor

által megadott) ellátva hozhatunk létre, mely jelszót az első bejelentkezéskor a

felhasználónak módosítani kell.

A jelszavak adminisztrátor által történő módosítása lehetséges, ennek legtöbbször az az

oka, hogy az adott felhasználó elfelejtette a jelszavát, vagy túllépte a sikertelen

bejelentkezési kísérletek megengedett számát. Nagyon fontos, hogy csak biztosan

azonosított felhasználói kérésre végezzünk jelszó módosítást.

A jelszó újragenerálásának menete a következő:

6. Indítsuk el a su01 tranzakciót.

37
 7. Adjuk meg a felhasználó azonosítóját, akinek a jelszavát módosítani szeretnénk.

8. Kattintsunk a Change Password gombra.

9. A megjelenő dialóg ablakban válasszuk a Generate Password gombot, hogy egy új

véletlenszerűen generált jelszót hozzunk létre a felhasználó számára. (Esetleg

kézzel is megadhatunk egy új jelszót, ebben az esetben a jelszó ismétlése

szükséges. A véletlenszerűen generált jelszavak bizonyos tulajdonságait

rendszerparamétereken keresztül definiálhatjuk. Ilyen például:

- A jelszó maximális hossza (GEN_PSW_MAX_LENGTH)

- A számjegyek maximális száma a jelszóban (GEN_PSW_MAX_DIGITS)

- A betűk maximális száma a jelszóban (GEN_PSW_MAX_LETTERS)

- A speciális karakterek maximális száma a jelszóban

(GEN_PSW_MAX_SPECIALS)

10. Kattintsunk a Transfer gombra.

4.5 Rendszeradminisztrátori üzenet küldése

Számos rendszer adminisztrátori interakció esetén szükséges az érintett felhasználók

előzetes értesítse, kijelentkezési felkérése. Ebben a részben foglalkozunk a pop up

üzenetek küldésével, illetve személyre szóló figyelmeztető üzenet létrehozásának lépéseit

is áttekintjük.

4.5.1 Pop up rendszer üzenet küldése az összes felhasználónak

A következő lépések írják le, hogyan küldhetünk adminisztrátori üzenetet az aktív

felhasználók számára:

1. Indítsuk el az sm02 tranzakciót.

38
 2. Kattintsunk a create gombra, így megjelenik a Create System message dialógus

ablak.

3. Töltsük ki a System message text szöveges mezőt, majd adjuk meg a server nevét, a

klienst és egy érvényességi intervallumot. (Lásd 13. ábra: Rendszer üzenet küldése

a felhasználóknak).

4. Kattintsunk a save gombra.

13. ábra: Rendszer üzenet küldése a felhasználóknak

Minden user megkapja ezt a pop up üzenetet, a következő interakciókor (tranzakció

bezáráskor vagy indítás előtt).

4.5.2 Személyes pop up küldése

Egyes esetekben előfordulhat, hogy csak bizonyos felhasználó(k) számára kell

figyelmeztetést küldenünk. A rendszerben van lehetőségünk lekérni az éppen aktív

39
felhasználókat. Az sm04 tranzakció kilistázza a rendszerbe bejelentkezett userek

azonosítóját és nevét. Több instancia esetén az al08 tranzakciót használhatjuk. Egy adott

felhasználó azonosítóját kiválasztva megtekinthetjük az általa indított folyamatokat, amiket

adminisztrátorként leállíthatunk vagy törölhetünk.

Miután meghatároztuk azon felhasználót vagy felhasználókat, akiknek személyre szóló

figyelmeztető üzenetet szeretnék küldeni, elindítjuk a se37 tranzakciót. Kövessük a

következő lépéseket:

1. Indítsuk el az se37 tranzakciót.

2. Adjuk meg a következő modult a megfelelő helyen: TH_POPUP.

3. Kattintsunk a futtatáshoz a test/execute-ra (vagy F8), adjuk meg a kért

információkat.

4. Majd F8-cal hajtsuk végre a műveletet.

Az előző üzenettel ellentétben ez a típusú figyelmeztetés azonnal megjelenik a címzett

felhasználó képernyőjén.

4.6 User adminisztrációs példa feladatok

4.6.1 Feladat

1. Válasszuk ki (az instruktor által megadott) referencia usert, majd készítsünk egy

másolatot róla (NUser01 néven), majd állítsuk az új felhasználó kezdő jelszavát a

következő értékre: sap123!

2. Jelentkezzünk be az imént létrehozott NUser01 felhasználóval és változtassuk meg

az iniciális jelszavát, ahogy azt a rendszer kéri! Ezután jelentkezzünk ki, majd

40
 kíséreljük meg a bejelentkezést a régi kezdő jelszóval háromszor egymás után,

ezzel zárolva az új felhasználót a következő feladathoz.

3. Jelentkezzünk be a saját felhasználónkkal, majd oldjuk fel a NUser01 felhasználó

zárolását a következő lépéseken keresztül!

4. Indítsuk el a suim tranzakciót és kérdezzük le a felhasználókat, akik téves

jelszóval próbálkoztak belépni.

5. Oldjuk fel a NUser01 felhasználót!

4.6.2 Feladat

1. Jelentkezzünk be a saját felhasználói adatainkkal és gyűjtsük egy listába a zárolt

felhasználókat, amely listát ezután mentsünk el valamilyen szöveges fájlba (suim).

Oldjuk fel ezeket a felhasználókat egy összevont karbantartási művelet segítségével

(su10), ahol az előzőleg mentett listát importálhatjuk.

4.6.3 Feladat

1. Jelentkezzünk be a saját felhasználói adatainkkal, majd gyűjtsük össze a már

legalább 30 napja inaktív usereket (suim). Hasonlóan az előző feladathoz, az

elkészített listát mentsük el egy szöveges fájlban, majd összevont karbantartási

művelet segítségével zároljuk a listában szereplő felhasználókat (su10).

4.6.4 Feladat

1. Készítsünk egy IT felhasználói csoportot azon felhasználók számára, akik

egységesen a “Informatics” részlegen dolgoznak.

4.6.5 Feladat

1. Adjuk meg a következő cégadatokat:

 Name: UNIDEB

41
  Country: HU

 Time Zone: Europe

2. Jelentkezzünk be a saját felhasználói adatainkkal és válaszzuk ki azokat a

felhasználókat, akik az “Informatics” részlegen dolgoznak és változtassuk meg a

cég nevét UNIDEB-re.

3. Ellenőrizzük az előző változtatást a user master recordokban. (suim)

4.6.6 Feladat

1. Küldjünk személyes figyelmeztetést a NUser01 felhasználó számára. (se37)

2. Küldjünk adminisztrátori üzenetet a felhasználóknak a következő tervezett

rendszerleállás időpontjáról. (sm02)

4.6.7 Kérdések

1. Mik a legfontosabb feladatai egy felhasználó adminisztrátornak?

2. Hogyan tudunk egy új felhasználót létrehozni a rendszerben?

3. Mik a minimálisan szükséges információk, amikor egy új felhasználót hozunk

létre?

4. Milyen okokból lehet egy felhasználó zárolva?

5 Jogosultságok, szerepkörök

A user adminisztráción túl a másik rendszer biztonsági szempontból hasonlóan kritikus

feladat a felhasználók és a megfelelő jogosultságok összerendelése. A felhasználói adatok

mandant függőek. Egy alkalmazott csak akkor tud belépni a rendszerbe, ha ott rendelkezik

érvényes belépési adatokkal (felhasználónév, jelszó). A sikeres belépést követően minden

tranzakció indításkor egy ellenőrzés fut, hogy az adott felhasználó rendelkezik-e a

42
megfelelő jogokkal az adott tranzakció futtatásához. Ez az ellenőrzés a S_TCODE

autorizációs objektumon alapszik. A felhasználó számára csak akkor jelenik meg a

tranzakciós képernyő, ha az ellenőrzés sikeresen lezajlott, különben egy hibaüzenetet kap,

ami tájékoztatja a jogosultság hiányáról. Egy tranzakción belül a különböző adatok

módosítása is különböző jogosultságokat igényel, így a felhasználók különböző adat függő

jogosultságokkal is rendelkeznek. Miközben a felhasználók különböző műveleteket

hajtanak végre egy tranzakción belül folyamatos ellenőrzés zajlik a háttérben annak

érdekében, hogy az adott felhasználó ne változtathasson meg olyan védett adatokat,

amelyekhez nincs megfelelő jogosultsága.

Információt kaphatunk a jogosultság ellenőrzések kimeneteléről a su53 tranzakcióban,

ahol a rendszer listázza az előzőleg végrehajtott ellenőrzéseket és azok eredményeit. Itt

találunk jelentéseket arról, hogy a sikertelenül lefutott ellenőrzések esetén milyen

jogosultságok hiányoztak a sikeres futáshoz.

A jogosultságokat különböző szerepkörökben gyűjthetjük össze, a szerepköröket pedig a

felhasználókhoz rendelhetjük. A jogosultság egy autorizációs objektum és annak a

megfelelő értékeit jelenti. Egy szerepkör több jogosultságot is tartalmazhat, és egy

felhasználónak lehet több szerepköre is. A javaslat az, hogy a user adminisztrátor és a

jogosultságokat kezelő személy két külön alkalmazott legyen, de ez nehezen kivitelezhető

a kisebb cégek esetén.

Két szerepkör típust különböztetünk meg:

- Egyszerű szerep esetén (logikailag összetartozó) jogosultsági objektumokat

rendelünk a felhasználóhoz.

43
 - Az összetett szerepkör esetén lehetőségünk van több egyszerű szerep egyidejű

hozzárendelésére a userekhez.

5.1 Egyszerű szerepkör

Egyszerű szerepkört a pfcg tranzakcióval hozhatunk létre. A függvény segítségével

jogosultsági objektumokat gyűjtünk össze egy szerepkört létrehozva.

14. ábra: Role Maintenance képernyő (pfcg tranzakció)

1. Indítsuk el a pfcg tranzakciót.

2. Adjunk meg egy nevet az új jogosultsági szerephez a Role beviteli mezőben.

(Ügyeljünk a javasolt név választási konvenciókra, azaz kezdődjön ’Z’ vagy ‘Y’

karakterrel.)

3. Kattintsunk a single role gombra, így megjelenik a Create Roles képernyő.

44
 15. ábra: Change Roles képernyő

a. Itt adhatjuk meg a szerepkörhöz tartozó rövid leírást, ha részletesebb

dokumentációra lenne szükség, használhatjuk a long text mezőt. A Menu

fülre áttérve mentsük a munkánkat.

b. A Menu fülön hozzunk létre egy mappát, amelyben

összegyűjthetjük azon tranzakciókat, amelyek futtatását engedélyezzük

ebben a szerepkörben. (Több mappát is létrehozhatunk az

átláthatóság kedvéért.)

c. A tranzakciók mellett ABAP programokat, Query-ket, tranzakció

változatokat, URL-eket, fájlokat, riportokat is felsorolhatunk az adott

szerepkörhöz. (Lásd 16. ábra: Tranzakciók, riportok, URL-ek, stb.

hozzáadása egy szerepkörhöz.).

45
16. ábra: Tranzakciók, riportok, URL-ek, stb. hozzáadása egy szerepkörhöz.

d. Az Authorization fülön a rendszer legenerálja az új profilt, ha a Propose

Profile gombra kattintunk.

e. A jogosultsági adatok megváltoztatása gombra

kattintva a rendszer figyelmeztet, hogy előbb mentsük el a létrehozott

szerepkört.

f. A következő képernyőn a rendszer kéri, hogy a hiányzó kapcsolódó

jogosultságokat adjuk hozzá a szerepkörhöz. Azok a mezők, ahol

elvégeztük a karbantartást zöld jelölőt kapnak és a jogosultsági objektum

46
 mellett az All Maintained jelzés megjelenik. A karbantartás után mentsük el

a változtatásokat és generáljuk le a profilt.

g. A User fülön felhasználókat adunk a létrehozott szerepkörhöz. Továbbá

érvényességi idő intervallumot is definiálhatunk. Azáltal, hogy több

felhasználót is felsorolhatunk, akik ezzel a szerepkörrel rendelkeznek a

későbbiekben, a szerepkör módosítása így ezekre és az esetlegesen a su01

tranzakcióban ide rendelt userekre is vonatkozik majd. (Lásd: User

menedzsment fejezet)

h. A save-re kattintva az új egyszerű szerepkört létrehoztuk.

5.2 Összetett szerepek

Egy jogosultság adminisztrátor munkáját nagyban megkönnyítheti, ha az e0ygszerű

szerepeket egy magasabb szinten csoportba rendezheti ezzel, úgynevezett összetett

szerepeket létrehozva. A felhasználóhoz pedig rendelhetünk ezáltal egy lépésben összetett

szerepeket is ahelyett, hogy egyesével sorolnánk fel az egyszerű szerepeket. Összetett

szerepeket az alábbi lépéseken keresztül hozhatunk létre a pfcg tranzakció segítségével:

1. Indítsuk el a pfcg tranzakciót.

2. Adjuk meg az új összetett szerep nevét, majd

3. kattintsunk a Comp. Role gombra.

4. Miután megadtuk a szerepkör egy rövid leírását, lépjünk tovább a

5. Roles fülre és soroljuk fel azokat az egyszerű szerepeket, amiket ebben az összetett

szerepben csoportosítani szeretnénk.

6. A Menu fülön az egyszerű szerepeknél megadott könyvtár struktúrát egyszerűen

átmásolhatjuk az Import menu gombra kattintva. Az elemek

47
 sorrendjét ebben a hierarchiában itt is módosíthatjuk egyszerűen drag-and-drop

segítségével.

7. A User fülön felsoroljuk azon felhasználókat, akik a későbbiekben ezzel az

összetett szerepkörrel rendelkeznek majd. Ha szükséges érvényességi intervallumot

is megadhatunk, amiben az adott felhasználó jogosultságai aktívak.

8. A Profiles fülön a rendszer hasonlóan mutatja be a generált profilt, mint az

egyszerű szerepek esetében.

5.3 Jogosultságok nyomon követése

Ahogy azt korábban már láttuk, az aktuális felhasználó esetén végrehajtott jogosultság

ellenőrzések eredményeit a su53 tranzakcióban megtekinthetjük. A rendszer itt kilistázza

a legutóbb bekövetkezett jogosultság ellenőrzések riportjait. Az elutasított jogosultság

ellenőrzések pirossal vannak kiemelve a listában. Kibontva a fastruktúrát a felhasználóhoz

már hozzárendelt jogosultságokról kapunk információt. A jogosultság adminisztrátor

betekintést kaphat más felhasználók ellenőrzéseibe is egy adott időszakra vagy instanciára

vonatkozóan például. Az ilyen fajta riportokat az st01 tranzakcióban kapcsolhatjuk be. A

jogosultsági műveletek nyomon követése a rendszer monitorozás egy részét képezi, az

st01 tranzakción belül aktiválhatjuk. Hasznos lehet, egy új szerepkör elkészítésénél,

amennyiben egy teszt userrel lefuttatjuk azokat a tranzakciókat, amik a szerepkört érintik,

így információt kapunk a szükséges jogokról. Egy hibaüzenet lekövetésére is gyakran

használjuk a jogosultság nyomkövetést. A Trace Analysis ablakban adhatjuk meg a

felhasználó nevét, a klienst, az időintervallumot, stb. A kért információkat a Start

reporting gombra kattintva kaphatjuk meg.

48
 5.4 Jogosultság kezelése és szerepkör példák

5.4.1 Feladat

1. Jelentkezzen be a saját felhasználói adataival és aktiválja a jogosultság

nyomkövetést. (st01)

2. Jelentkezzünk ki majd vissza, de már a NUser01 felhasználóval. Indítsuk el a

rspfpar tranzakciót. (A tranzakció indítását a rendszer blokkolja, mert az adott

felhasználónak nincs megfelelő jogosultsága. )

3. Jelentkezzünk vissza a saját felhasználói adatainkkal. Indítsuk el az st01

tranzakciót és kérjük le a jogosultság ellenőrzésekről szóló riportot az NUser01

felhasználóra vonatkozóan az adott idő intervallumba. Itt megtaláljuk a jogosultság

ellenőrzés miatt blokkolt tranzakció futtatási kísérletet és a részletes okokat.

5.4.2 Kérdések

1. Hol és hogyan tudjuk megtekinteni a sikeres és sikertelen jogosultság ellenőrzések

eredményeit?

2. Mi a különbség az egyszerű és összetett szerepek között?

6 Rendszer konfiguráció

6.1 Rendszer paraméterek konfigurációja

A rendszer alapvető technikai beállításait a rendszer paramétereken keresztül

menedzselhetjük. Ezen paraméterek alapértelmezett értékei a kernel kódban definiáltak, de

megfelelő jogosultságokkal rendelkező adminisztrátorok megváltoztathatják azokat a

rendszer telepítésekor létrehozott profil fájlok felülírásával. Ezek a fájlok operációs

49
rendszer szinten a “\usr\SAP\<SID>\SYS\profile” mappában találhatóak. Ezeket a fájlokat

a rendszer indításkor olvassa be, így a paraméter módosítások életbe lépéséhez egy

újraindítás szükséges. Csak kevés közülük olyan, ami dinamikusan, azaz újraindítás nélkül

módosítható.

A következő rendszer profil fájlokat különböztethetjük meg:

- Start profile (“START_<Instance><Instance number>_<Host_name>”)

Meghatározza azokat a szolgáltatásokat, amik a rendszerindításkor az egyes

instanciákon elindulnak. A SAP MMC – ben tudjuk olvasni a fájl tartalmát, az

instancián vett jobb kattintás, majd “All tasks  View start profile” pontot

választva. A következő példa mutatja, hogy egy instancia indításakor az

adatbázisnak kell először elindulnia, majd következik a message server és a

dispatcher.

50
 17. ábra: Start profile példa

- Default profile (“DEFAULT.PFL”)

Minden SAP rendszerben pontosan egy default profile létezik, ami minden

instancia által olvasható. A rendszerhez kötődő beállításokat tartalmazza, azaz

olyan paramétereket, amik minden instancia számára egyedinek tekinthető. A

következő példában láthatjuk, hogy a DEFAULT.PFL tartalmazza a rendszer nevét

(SYSTEMNAME), az adatbázis nevét, a message serverhez kötődő információkat, és

az alapértelmezett logon klienst.

51
 18. ábra: DEFAULT.PFL példa

- Instance profile (“<SID>_<Instance><Instance number>_<Host name>”)

Instancia specifikus tulajdonságokat leíró paramétereket tartalmaz. Lehetővé teszi,

hogy a különböző instanciákon különböző beállításokat alkalmazzunk. Ebből már

következtethetünk arra, hogy ez a fájl instancia függő.

19. ábra: Instance profile példa

A paraméterek megtekintésére az operációs szinten megnyitott profile fájlok áttekintése

mellet lehetőségünk van még az RSPFPAR és a RZ11 tranzakciókban.

52
Az RSPFPAR esetén a rendszerparaméterek egy listáját láthatjuk táblázatos formában, ahol

szerepel a paraméter neve, az alapértelmezett értéke, ami a kernel kódban definiált, a

felüldefiniált érték amennyiben a felhasználó megváltoztatta azt, és egy rövid leírás, ami

mellett egy hosszabb dokumentáció előhívására is van lehetőség.

Az RZ11 esetében az egyéni profile paramétereket listázhatjuk és arról is kapunk

információt, hogy az adott paraméter dinamikusan változtatható e vagy sem.

SAP rendszeren kívül is van lehetőségünk megtekinteni a profile paramétereket.

Jelentkezzünk be <SID>adm felhasználóval és használjuk a sappfpar függvényt a kívánt

rendszerparaméter nevét megadva vagy az all kapcsolóval, amennyiben az összes

paramétert látni szeretnénk.

A rendszerparaméterek változtatására két lehetőségünk van. Operációs rendszer szinten

egy tetszőleges szerkesztővel módosítjuk a profil fájl tartalmát (kifejezetten csak

vészhelyzet esetén megengedhető megoldás) de sokkal inkább ajánlott és biztonságosabb,

ha az SAP beépített paraméter editor-ját használjuk az rz10 tranzakcióban. Mielőtt

bármilyen paramétert megváltoztatnánk, győződjünk meg arról, hogy a megfelelő profil

fájlról készítettünk egy másolatot.

A profil módosítás egy két lépcsős folyamat. Először (telepítés után) a paraméterek csak

operációs szinten elérhetőek. Amikor első alkalommal futtatjuk az rz10 tranzakciót a

profil paramétereket be kell importálnunk az adatbázisba (Utilities  Import profiles  Of

active server). Ezután már kitölthetjük Profile mezőt amihez használhatjuk az F4 help-et

is, ami a lehetséges opciókat kínálja fel.

53
 20. ábra: RZ10 tranzakció, profil kiválasztása

Az Edit Profile ablakban három lehetőség közül választhatunk:

- Administrative Data: Olyan módosításokat tartalmaz, amik nem kifejezetten profil

paraméternek számít, de szorosan kapcsolódó dolgok, mint például a leírás, az

elérési útvonal, nevek, instancia nevek, stb.

- Basic maintenance: Ebben az esetben lehetőségünk van a legfontosabb paraméterek

megváltoztatására, mint például a work processek száma, a buffer és rendszer profil

könyvtárak. Módosíthatjuk továbbá a start profilt ami az rendszerindításkor

aktiválódó folyamatokat írja le.

- Extended maintenance: Ez a mód teljes hozzáférést nyújt a profil paraméterekhez.

Itt nem csak a meglévő paraméterek módosítása, de új paraméterek felvétele (a new

parameter gombra kattintva) vagy akár a régiek törlése is lehetséges. Az újonnan

felvett paraméterek elhelyezkedése nincs semmilyen hatással a rendszer

54
 működésére, de erősen ajánlott, hogy a logikailag összetartozó paramétereket

egymás után soroljuk fel.

A változtatások először az adatbázisban kerülnek tárolásra, és csak azután kerülnek át a fájl

rendszerbe. Miután módosítottunk egy paraméter értéket kattintsunk a copy gombra így az

érték ideiglenesen bekerül az adatbázisba és csak akkor kerül be a fájlba, amikor

rákattintunk a save gombra (vagy Profile  Activate) az edit profiles képernyőn. A

rendszer elvégez egy konzisztencia ellenőrzést, amikor a profil fájl szintaktikáját és

szemantikáját is megvizsgálja. Figyeljük meg, hogy a profil fájl verziószáma is változik

egy módosítás végrehajtása után. Miután a rendszert újraindítottuk a módosítás életbe lép.

Az instancia specifikus paraméterek esetében elég, ha az érintett instanciát indítjuk újra,

ellenben a default profile esetén már az összes vonatkozó instancia újraindítása szükséges

ahhoz, hogy a módosítást aktívvá tegyük.

6.1.1 Feladat

Definiálja a következő paraméterek értékét: (használja az rz11 vagy rspfpar

tranzakciókat):

- A lokális applikációs server neve.

- Work processek száma.

- A dialógus és háttér folyamatok száma, aránya a centrális instancián.

Segítség:

(“rdisp/myname”, “rdisp/wp_max_no”, “rdisp/wp_no_dia”, “rdisp/wp_no_btc”)

55
6.1.2 Feladat

Készítsen másolatot a profil fájlokról majd állítsuk be az alábbi jelszó protokolt a

rendszerünkben a vonatkozó system logon paraméter értékek felülírásával:

- A jelszó minimális hossza 8 karakter.

- Legalább egy számjegyet kell tartalmaznia.

- Legalább egy nagybetűt kell tartalmaznia.

Mentse, majd aktiválja a módosításokat.

Segítség:

(“login/min_password_lng”,”login/min_password_digits”,

“login/min_password_uppercase”)

6.1.3 Kérdések

1. Mire használatosak a rendszer paraméterek?

2. Milyen különböző profil típusokat ismerünk?

3. Hol vannak tárolva a rendszer profilok és hogyan tekinthetjük meg azok tartalmát?

4. Milyen lépéseken keresztül módosíthatunk egy rendszer paramétert?

6.2 Működési módok

Annak érdekében, hogy a teljesítményt optimalizáljuk és fenntartsuk a rendszerünk

stabilitását elengedhetetlenek a különböző üzemmódok, működési módok bevezetése. Az

adminisztrátornak figyelembe kell vennie a rendszer különböző időszakokban vett

terheltségi szintjeit (pl.: különböző igények nappal és éjszaka).

A work processeket az alábbi módon kategorizálhatjuk:

56
 - Dialog work processes – ABAP dialóg programok.

- Batch work processes – Háttérfolyamatok.

- Update work processes – Adatbázis változtatások.

- Enqueue work processes – Lock műveletek.

- Spool work processes – Nyomtatások.

A rendszer finom hangolása egy nagyon kritikus művelet. A legelső kérdés, hogy a

rendszerünk egy vagy több instanciával rendelkezik. Például bevezethetünk két külön

instanciát a dialógus és a háttérfolyamatok számára. Minden instancián meghatározott

számú work process lehet, ez a szám a megfelelő rendszerparaméteren keresztül

változtatható, ám ez a módosítás rendszer újraindítást igényel.

Jobb megoldás, ha az adminisztrátor különböző működési módokat definiál a rendszer

számára, amelyekben meghatározza a dialógus és a háttérfolyamatok arányát a megadott

work process darabszámon belül. Ezt a műveletet újraindítás nélkül, dinamikusan is

végrehajthatjuk. A műveleti módok közti átváltás nem igényel rendszer újraindítást.

Például a nappali időszakban, amikor a felhasználók aktívak, a dialógus processek

megengedett számát érdemes magasabbra állítani, ellenben éjjel megengedhető, hogy

magasabb számban forduljanak elő background processek a rendszerben. Így a work

processek teljes számának változtatása nélkül dinamikusan igazíthatjuk a háttér és dialóg

folyamatok arányát a rendszer terheltségéhez.

A „nappali” és „éjszakai” működési módokon kívül igény szerint definiálhatunk más

időszakokat is, persze vegyük figyelembe, hogy a működési módok növelése több

adminisztratív munkával jár. Másfelől viszont egy jól konfigurált rendszer kevesebb

karbantartást igényel.

57
Nézzük meg, hogyan definiálhatunk különböző működési módokat az rz04

tranzakcióban.

Határozzuk meg a
szükséges műveleti
módokat.

Az instancián
meghatározott számú
work process lehet.
Állítsuk be igény szerint a
dialóg és háttérfolyamatok
arányát a különböző
módokban.

Állítsunk be
időintervallumot a
műveleti módokhoz.

Először egy instancia definíciót kell létrehoznunk, amennyiben még nem tettük meg:

1. Indítsuk el az rz04 tranzakciót.

2. Kattintsunk az Instances/Operation modes gombra.

3. Kattintsunk a Create new instance gombra.

4. Hozzunk létre egy instanciát, töltsük ki a Host name és SAP system number

mezőket, majd kattintsunk a Current settings gombra, így a rendszer automatikusan

legenerálja a szükséges adatokat az aktuális instanciából.

5. A következő dialógus ablakban kell definiálnunk a kívánt működési módokat.

Kattintsunk a save-re.

58
 6. Válasszuk a No-t a következő pop up ablaknál, amikor a rendszer megkérdezi, hogy

ugyanezt az elosztást szeretnénk e más működési módok esetén is használni. (“Do

you want to assign this distribution to other operation modes also?”) .

Ezek után lehetőségünk van új működési módokat is létrehozni:

1. Indítsuk el az rz04 tranzakciót.

2. A következő dialógus ablakban az alábbi mezőket kell kitöltenünk: A működési

mód neve és rövid leírása.

21. ábra: Működési módok megadása

3. Miután mentettünk a beállításokat, automatikusan a kezdőképernyőre kerülünk,

ahol további működési módok megadása lehetséges.

4. Miután befejeztünk a műveleti mód létrehozását, kiválasztunk egyet majd az

Instances/operation modes gombra kattintunk.

5. A következő dialógus ablakban válasszuk ki a saját instanciánk work process

felosztását majd kattintsunk a choose gombra.

6. Változtassuk meg a háttérfolyamatok és dialógus folyamtok arányát a + és –

gombokkal, majd mentsük el a beállításokat. A work processek teljes számát nem

59
 engedi a rendszer megváltoztatni, ehhez rendszer paraméter módosítás szükséges.

Meg kell jegyeznünk továbbá, hogy egy instancián legalább 2 dialógus processnek

lennie kell, így a beállításoknál szintén nem megengedett, hogy ennél kisebb

számot definiáljunk.

7. Hasonlóan járjunk el a többi működési mód esetében is.

8. Töröljük azokat a működési módokat, amelyekre már nincs szükségünk.

Pozícionáljuk a kurzort a kiválasztott működési módra, majd a felső menüben

válasszuk az Instance  Delete entry elemet.

Ezek után állíthatjuk be a különböző időintervallumokat a működési módokhoz.

1. Indítsuk el a sm63 tranzakciót.

2. Válasszuk a normal operation ( 24 hr ) opciót, majd kattintsunk a change gombra.

3. Állítsuk be a működési mód érvényességi idejét, úgy hogy a kurzort a kezdő

időpontra pozícionáljuk, majd a fenti menüben Operation mode  Select interval

pontot választjuk (vagy F2-t nyomunk). Ezután kiválasztjuk az érvényességi

intervallum végpontját és a menüben ismét az Operation mode  Select interval

pontot választjuk vagy újra F2-t nyomunk. A kijelölt intervallum más színnel

(például fekete helyett most már kékkel) jelenik meg a képernyőn.

4. Miután az érvényességi időt definiáltuk kattintsunk az Assign gombra, hogy ezt az

intervallumot hozzárendeljük a megfelelő műveleti móddal.

5. Ismételjük meg az előző lépéseket és kapcsoljuk érvényességi időszakot a többi

működési módhoz is.

6. Miután végeztünk mentsük a módosításokat.

60
 22. ábra: Érvényességi időszak meghatározása működési módokhoz.

Most már a rendszer időbeosztása aktív, ettől a pillanattól a működési módok

automatikusan váltják egymást. Két működési mód közti váltás azonban nincs hatással az

éppen futó folyamatokra, a váltás csak a folyamat lefutása után történik meg így ezen

okból számolni kell némi csúszásra. A működési módok közti váltást és a futó

folyamatokat megfigyelhetjük az sm50 tranzakcióban. Az sm21 tranzakció lehetővé teszi,

hogy lássuk a log bejegyzést, ami a működési mód váltásakor keletkezik.

A működési módok között manuális váltásra is van lehetőség az rz03 tranzakcióban.

1. A tranzakciós képernyőn látjuk az éppen aktív működési módot, a vonatkozó

instanciát és annak státuszát.

2. Pozícionáljuk a kurzort arra az instanciára, amelyiken működési módot szeretnénk

váltani, majd kattintsunk a change operation mode gombra.

61
 3. Válasszunk ki egy működési módot, majd kattintsunk a choose gombra.

6.2.1 Feladat

- Nézze meg a rendszer profile fájlokat majd adjon választ arra a kérdésre, hogy hány

munkafolyamat engedélyezett az adott instancián.

6.2.2 Feladat

Képzeljünk el egy nemzetközi céget, ahol a dolgozók két különböző (T1, T2) időzónában

dolgoznak ugyanazon a rendszeren. A következő ábra mutatja a felhasználók aktív

időszakait és azt, hogy mely időszakra lehetne háttérfolyamatokat priorizálni.

23. ábra: Aktív rendszer időszak

Definiálja az alábbi három működési módot a következő beállításokkal.

1. Normál mód: A rendszert csak az egyik felhasználó csoport tagjai használják.

Periódus: 09:00-12:00 és 15:00-18:00.

Dialógus folyamatok száma: 6 (50%)

Háttérfolyamatok száma: 6 (50%)

62
 2. Heavy load mód: A rendszert mindkét időzóna dolgozói használják.

Periódus: 12:00-15:00.

Dialógus folyamatok száma: 9

Háttérfolyamatok száma: 3

3. Downtime mód: A felhasználók nem aktívak.

Periódus: 18:00-09:00.

Dialógus folyamatok száma: 2

Dialógus folyamatok száma: 10

6.2.3 Kérdések

1. Milyen work process típusokat ismerünk?

2. Mire használjuk a különböző működési módokat?

7 Háttérfolyamatok

Olyan munkafolyamatokat, amik nem igényelnek felhasználói interakciót, ellenben sok

időbe telik a lefutásuk ütemezhetünk olyan időszakra, amikor a rendszer terheltsége

kisebb, például éjszaka vagy hétvégén. A háttérfolyamatokat nem csak időigényes

processekhez, hanem bizonyos rendszerességgel ütemezett műveletekhez is használhatjuk.

Például adatgyűjtések, riport generálások, clean up feladatok. A legtöbb tranzakció

felkínálja a lehetőséget a felhasználónak a háttérben vagy dialógus módban való futtatás

között. Az előző fejezetben tárgyaltuk, hogy hogyan definiálhatunk különböző működési

módokat annak érdekében, hogy a rendszer erőforrásokat jól szervezett módon használjuk

ki. Ebben a fejezetben bemutatjuk, hogy hogyan készíthetünk háttérfolyamatokat (batch

63
munkafolyamatokat), hogyan definiálhatjuk egy folyamat számára, hogy dialóg vagy háttér

módban fusson.

Egy dialóg módban futtatott tranzakció az aktuálisan bejelentkezett hallgató ID-ja alatt fog

indulni, ezzel ellentétben a háttérfolyamatok esetében annak a felhasználónak az

azonosítóját jegyzi a rendszer, aki a háttérfolyamatot létrehozta. Speciális felhasználókat

hozhatunk létre ilyen célra, ami független a többi (valódi) felhasználótól, ellenben ez több

adminisztratív munkával jár.

Olyan folyamatok háttérben való indítása, amelyek további paramétereket igényelnek

szintén lehetséges. Ebben az esetben úgynevezett variánsokat kell képeznünk, melyek

képesek felhasználói interakció nélkül is futni.

7.1 Háttérfolyamatok készítése

Háttérfolyamatot definiálhatunk az alábbi lépéseken keresztül:

1. Indítsuk el az sm36 tranzakciót.

2. A Define background job képernyőn adjuk meg a folyamat nevét, használjuk a

felhasználó által létrehozott elemekre vonatkozó standard név konvenciókat.

3. Definiáljuk a folyamat prioritását az alábbi mező kitöltésével: Job class. A

folyamat osztály három különböző érték lehet: az “A” érték magasabb prioritást

jelöl, mint a “B”, ami egy közepes prioritási érték vagy a “C”, ami a

legalacsonyabb prioritást jelöli. Habár egy folyamat még akkor sem szakít félbe

egy már futó folyamatot, ha annak a prioritási értéke alacsonyabb.

4. Az Exec. Target mezőben opcionálisan specifikálhatjuk a servert.

64
5. Kattintsunk a step gombra és egy új dialóg ablak jelenik meg, ahol a következő

információkat adjuk meg:

6. A user mezőben a saját ID-nkat látjuk, de ezt átírhatjuk.

7. Ki kell választanunk a program típusát:

 ABAP program.

 External command: egy előredefiniált script, parancs vagy SAP rendszeren

kívüli program.

 External program: bármilyen egyéb operációs rendszer szintű program.

8. Szintén megadható egy érvényességi intervallum a program számára a megfelelő

mezőben.

9. Amennyiben a programnak valamilyen output igénye lenne, használjuk a Print

specification gombot az eszköz beállításához, a másolatok számának megadásához,

stb.

10. Miután elmentettük a módosításokat további lépéseket definiálhatunk hasonló

módon. Majd lépjünk vissza a Define Background Job képernyőre.

11. Kattinsunk a Start condition gombra, ahol a folyamat indulási idejét adhatjuk meg.

 Immediate: A folyamatot azonnal elindítjuk.

 Date/Time: Egy adott időpontban szeretnénk indítani.

 After job: Egy meghatározott folyamatot követően indítjuk.

 After event: Esemény vezérelt ütemezés. A folyamat egy bizonyos esemény

után indul el.

 At operation mode: A folyamat indítását egy adott működési mód

bekapcsolásához kötjük.

12. A Periodic job jelölőnégyzet aktiválásával intervallumértékeket adhatunk meg.

65
 13. Mentsük a változtatásokat, majd navigáljunk vissza a Define Background Job

képernyőre, ahol további háttérfolyamatokat hozhatunk létre.

Háttérfolyamatok a Job Wizard-dal is létrehozhatunk az sm36WIZ tranzakcióban.

7.2 Háttérfolyamatok monitorozása

Természetes igény, ha egy ütemezett feladatról szeretnénk információkat kapni. Kövessük

az alábbi instrukciókat, melyek bemutatják, hogyan monitorozhatjuk a háttér

folyamatainkat:

1. Az sm37 tranzakció ad lehetőséget a folyamat monitorozásra.

2. A Job selection dialóg ablakban kiválaszthatunk egy bizonyos folyamatot, annak

nevének definiálásával, vagy a hozzá kapcsolódó felhasználó ID megadásával.

Lehetőségünk van szűrni ezen folyamatokat, például a státuszuk alapján:

 Scheduled: A lépések már definiáltak, de a start feltételek még nem.

 Released: Teljesen definiált folyamat, de ezen a ponton még változtatható.

 Ready: A folyamat ütemező által a sorban már elhelyezett folyamat.

 Active: Éppen futó folyamatok, nem módosítható és nem eliminálható már (de

manuálisan megszakítható).

 Finished: Sikeresen végrehajtott folyamatok.

 Canceled jobs: Adminisztrátor által vagy hiba következtében megszakított

folyamat.

A Job start condition részben idő intervallumot vagy eseményt állíthatunk be, ami

után futó folyamatokat szeretnék kilistázni.

3. Kattintsunk az Execute gombra.

66
 4. Job Overview képernyő megjelenik, ahol a feltételeknek megfelelő jobok listáját

látjuk, azok státuszával, indítási időpontjával, időtartamával és késési idejével

együtt. (Status, Start time, Duration, Delay).

Részletesebb adatokért kattintsunk duplán az adott folyamatra.

A folyamat log bejegyzéseit megjeleníthetjük a megfelelő sor kiválasztásával, majd

a Job log gombra kattintással.

Az SAP a folyamat ütemezés grafikus megjelenítését is támogatja, amit az rz01

tranzakcióban érhetünk el.

7.3 Ütemezett feladatok

Mint már említettük a háttérfolyamatok létrehozása leggyakrabban az ütemezett feladatok

végrehajtását segíti. Ebben a részben áttekintjük milyen feladatokat érdemes ütemezetten

végrehajtani. Csoportosítjuk a műveleteket végrehajtási gyakoriságuk szerint.

Kritikus feladatok: Azok a műveletek, amiket napi szinten kell lefuttatni. Ezek

rendszerint ellenőrzések, amik a rendszer normál működését hivatottak igazolni.

- Ide tartozik például annak az ellenőrzése hogy egyáltalán fut e a rendszer, be tud e

jelentkezni a felhasználó.

- Szintén napi szinten szükséges ellenőriznünk, hogy a rendszer mentések rendben

zajlanak e mind az adatbázis és mind a nem adatbázis adatok esetén (logok,

transport fájlok, tárolt nyomtatások, stb.). A backup műveletekkel kapcsolatos

problémákat azonnal kezelnünk kell.

Az előzőekben leírt kritikus feladatok elvégzésére szolgáló tranzakciós listát láthatjuk a

következő táblázatban:

67
 2. Táblázat: Kritikus (naponta végzendő) feladatok tranzakciós kódjai

Tranzakciós
Elvégzendő feladat
kód
DB12 / DB13 Az adatbázis mentések ellenőrzése.
SM51 Ellenőrizzük, hogy az összes szerver fut e.
Az aktuálisan bejelentkezett felhasználók ellenőrzése, többszörös
AL08 / SM04
bejelentkezések szűrése.
OS06 Esetleges operációs rendszer vagy hardver problémák felderítése
Ellenőrizhetjük, hogy volt e nem megfelelően futott háttérfolyamat,
SM37 / RZ01
aminek az eredményétől függhetnek más feladatok.
SM12 A zárolt műveleteket tekinthetjük át.
SM13 Report az update-ekről.
SM21 Rendszer log elemzés.
A processzek állapotát tudjuk áttekinteni, a túl hosszan vagy nem
SM50/SM51
megfelelően futott folyamatokat szűrjük.
SP01 Beragadt nyomtatási feladatokat keresünk.
Adatbázis és operációs rendszer paraméterek áttekintése, buffer
ST02
kapacitás ellenőrzése.
ST03 Rendszer teljesítmény ellenőrzés.
ST04 Magas szintű adatbázis monitorozás.
ST22 ABAP dump logok.
STMS Transzport kérések áttekintése.
Forrás: (Schreckenbach, 2014)

Heti teendők: Egy adminisztrátor általában heti rendszerességgel ellenőrzi a nyomtatósort

(SP01), és nyomon követi a rendszer inkonzisztenciáit (SP12).

Az adatbázist illetően a rendelkezésre álló memória és a memória történet ellenőrzése

szükséges. Továbbá áttekintjük a szerver statisztikákat (DB02).

Az operációs rendszer szintjén szintén megnézzük, hogy rendelkezik e a rendszer a

szükséges memóriával (RZ20), ha szükséges igazítjuk (RZ21).

Havi feladatok: A töredezettség mentesítés érdekében egy SAP adminisztrátornak

érdemes havonta egy rendszer újraindítást beütemeznie. Operációs rendszer esetében a

68
memória igények felülvizsgálata szükséges, valamint az esetleges cleanup folyamatok

futtatása.

Negyedévente tanácsos áttekinteni a felhasználó azonosítókat és törölni vagy zárolni a már

nem aktív usereket (SU01). Továbbá a letiltott jelszavakat is érdemes ellenőrizni (SM30).

Az előző hónapokra ütemezett feladatokat átnézzük, hogy erre az időszakra még

relevánsak e vagy sem (SM37 – SAP rendszer szintjén, DB13 – adatbázis szinten).

Évente ajánlott egy nagyobb biztonsági ellenőrzést végrehajtani, amely során átnézzük a

felhasználói profilokat és jogosultságokat. Mind az adatbázist mind a rendszert tekintve

szükséges egy éves mentést elvégezni.

7.4 Kérdések

1. Mikorra érdemes ütemezni a háttérfolyamatokat?

2. Melyik tranzakción keresztül tudunk új háttérfolyamatot definiálni?

3. Hogyan tudjuk nyomon követni a háttérfolyamatainkat?

4. Milyen havonta ismétlődő feladati vannak egy rendszeradminisztrátornak?

8 Backup és restore műveletek

Ebben a fejezetben a backup és restore stratégiák kidolgozásának fontosságáról és

felmerülő kérdéseiről less szó. Tanácsot adunk, hogyan építs fel egy optimális és folytonos

backup és egy gyors és hatékony restore stratégiát.

Egy backup stratégia megfelelő, ha egy teljes hozzáférést biztosít a jelenleg a rendszerben

tárolt adatokhoz és megadja a lehetőséget ezen adatok gyors rendszerbe

69
visszaimportálására egy esetleges nem várt vészhelyzet esetén. A következőket kell

teljesítenie:

1. Teljes: Minden szükséges adatot és log fájt tartalmaznia kell. Egy elvesztett és nem

helyreállítható adatot később már nem tudunk pótolni. A backup tartalmazza mind

az adatbázist a log fájlokkal valamint az operációs rendszer szintű adatokat is. A

szükséges log fájlok nélkül adatbázis helyreállítást nem tudunk végezni.

2. Gyors: Ha egyes adatok csupán egy órán keresztül válnak elérhetetlenné, már az is

jelentős anyagi károkat tud okozni, ezért rendkívül fontos a helyreállítás

gyorsasága.

8.1.1 Adatbázis és tranzakciós log mentés

Az adatbázis mentés a legkritikusabb backup folyamat. A log fájlok párhuzamos

mentése elengedhetetlen, ezek nélkül az információk nélkül nem lehet az adatbázis

megfelelő módon helyreállítani. Nézzünk egy példát: A log fájlok sérültek egy hétfői

napon, de a rendszerünk majd csak szerdán állt le. Annak ellenére, hogy rendelkezünk

az adatbázisunk szerdai (leállás előtti) állapotának másolatával nem tudjuk azt

helyreállítani, tekintve hogy az utolsó hiba mentes log fájlunk hétfői.

Különböző stratégiák közül választhatunk:

Amennyiben a heti mentés mellett döntünk a következő problémák merülnek fel:

Naponta 10 log fájl készül egy SAP rendszerben melyeket minden nap le kell tárolnunk

attól függetlenül, hogy az adatbázisról csupán heti egy másolatot készítünk. Ezek

helyreállítása rendkívül időigényes dolog. Valamint a tranzakciós logok egy

meghatározott könyvtárban kerülnek eltárolásra, ahol elegendő szabad hely hiányában

az adatbázis mentés leáll.

70
Amennyiben napi mentést végzünk a teljes adatbázisról és a logokról egy esetleges

helyreállítás esetén csupán 10 log fájlról kell gondoskodnunk és az adatbázisról, ez

lényegesen kevesebb időt igényel. Ellenben ez csak akkor kivitelezhető a megfelelő

hatékonysággal, ha lehetőségünk van a backup folyamatokat a kevésbé terhelt

időszakokra, például éjjelre ütemezni.

Backup folyamatok operációs rendszer szinten

Operációs rendszer szinten lévő fájlok mentése szintén szükséges úgy, mint a

konfigurációs beállítások, SAP fájlok, profilok, transzport fájlok. Az adatbázis

mentéshez hasonlítva, ilyen fájlok mentése nem igényel akkora erőforrás felhasználást.

Hogyan építsünk fel egy jó backup stratégiát?

Először meg kell határoznunk a vállalat igényeit arra vonatkozólag, hogy mi a még

elfogadható leállási időtartam, milyen anyagi károkat okoz egy esetleges rendszer hiba.

Definiálnunk kell a mentések gyakoriságát és típusát. Ezekre nem lehet általános

ajánlást adni, tekintve hogy minden szervezet más és más követelményeket állít az

említett kérdésekkel kapcsolatban.

A hardver és szoftver infrastruktúrát is definiálnunk kell. Vegyük figyelembe a cég

anyagi helyzetét és ennek megfelelően válasszuk ki a megfelelő eszközöket.

Nagyon fontos hogy az elkészített backup-restore stratégiát teszteljük üzembe helyezés

előtt és utána is bizonyos rendszerességgel. Fontos megbizonyosodnunk arról, hogy

különböző rendszerhibák esetén megfelelő futási idővel és eredménnyel rendelkezünk,

hogy rendelkezésre áll az a teljesítési szint, amit elvárunk.

71
 Nagyon ajánlott egy ellenőrző lista készítése ehhez a folyamathoz is. (Lásd a Tippek

hogyan légy jó SAP adminisztrátor fejezetben.)

3. táblázat: Ellenőrző lista minta backup stratégia kialakításhoz

Feladat, művelet, döntés Elvégezve

Határozzuk meg a gyakoriságot
Határozzuk meg a mentéseink típusát (teljes vagy részleges)
Automatikus backup folyamatot szeretnénk használni vagy sem
A tranzakció logok mentésének gyakoriságát is meg kell határoznunk
Teszteljük, hogy a megfelelő infrastruktúra rendelkezésre áll e
- tárhely
- memória
Adjunk megfelelő jogosultságokat az adminisztrátoroknak, hogy a backup
és restore folyamatokat futtathassák.
Határozzuk meg a mentések idejét
A mentési tárhely méretét definiáljuk
Inicializáljuk a tárhelyet
Tároló típusának meghatározása
Dokumentáljuk a folyamatot
Végezzünk el egy teljes backup – restore folyamatot, hogy teszteljük a
sdg

stratégiánkat
Készítsünk egy vészhelyzeti tervet
Source: (Schreckenbach, 2014)

8.2 Kérdések

1. Mi a különbség egy teljes és egy részleges adatbázis mentés között?

2. A két mentési folyamat közül melyik által érhetünk el gyorsabb restore műveletet?

3. Miket kell tesztelnünk miután meghatároztuk a backup-restore stratégiánkat?

9 Tippek hogyan légy jó SAP adminisztrátor2

1. Rendszer védelem

2
Sebastian Schreckenbach: Practical Guide SAP Administration könyve alapján

72
A legkomolyabb anyagi és technikai veszteségek legtöbbször a rendszerintegritási

hibákból adódnak. Egy adminisztrátor egyik legfontosabb feladata, hogy ezt kezeli.

2. Kérdezz és építs kapcsolatokat

Az SAP egy rendkívül jó támogatói rendszert kínál. Használd az SAP Solution Manager-t

és kérdezz az SAP kommunikációs hálójában (www.scn.sap.com). Ezen kívül érdemes

rendszeresen részt venni SAP rendezvényeket, tréningeken és konferenciákon.

3. KISS (Keep It Short and Simple)

A nagy és összetett problémák jellemzően kisebb részfeladatokra bonthatóak. Ezt vegyük

figyelembe annak érdekében, hogy a munkánkat megkönnyítsük, leegyszerűsítsük.

4. Dokumentálj

Nem csak az SAP adminisztráció terén, de az információ technológia bármely területén

általánosan elvárt és szükséges része a fejlesztésnek a dokumentáció.

Amellett hogy egy jó dokumentáció nagy segítség lehet más alkalmazottak számára

(főként az új dolgozóknak) a munkánk megértésében számunkra is segíthet a komplex ám

ritkán ismétlődő feladatok elvégzése esetén.

5. Tervezz

Annak érdekében, hogy a munkád átlátható és szervezett legyen, használj munkatervet és

check list-eket. Ezzel elkerülhető, hogy fontos lépéseket kihagyjunk egy munkafolyamat

esetén. A rendszer újraindítást vagy leállítást igénylő feladatokat ütemezed olyan

időszakra, amikor a rendszer terheltsége minimális, valamint ne változtassunk a rendszer

beállításain kritikus időszakokban.

73
Egy jó példa erre Az SAP rendszer indítása, leállítása fejezetben leírt rendszer leállítási

folyamat pontos menete. Egy leállási folyamathoz javasolt check-list a következő:

4. Táblázat: Feladatlista minta tervezett rendszerleállításhoz

Feladat Dátum Ellenőrizve

A következő feladatok elvégzése szükséges a megfelelő idővel a rendszer leállítása

előtt:
Egyeztessük a leállást az érintett részlegekkel.
Küldjünk rendszer üzenetet, hogy a felhasználókat tájékoztassuk
a tervezett leállásról. (sm02)
Esetlegesen küldjünk emailben is egy figyelmeztetést a
felhasználók számára.
A leállás idejére ütemezett feladatokat ütemezzük át, vagy
töröljük. (sm37)
A következő feladatok elvégzése szükséges közvetlenül a rendszer leállítása előtt:
Bizonyosodjunk meg róla, hogy nincs aktív felhasználó
bejelentkezve a rendszerbe. (sm04)
Győződjünk meg róla, hogy aktív háttérfolyamatok sem futnak.
(sm37)
Tájékozódjunk arról, hogy aktív, futó processzek sincsenek a
rendszerben. (sm51)
Ellenőrizzük az aktív külső interfészeket. (smgw)
Az SAP rendszer leállítási folyamata:
Állítsuk le az applikációs server instanciáit.
Állítsuk le a centrális instanciát.
Állítsuk le az adatbázis. (opcionális)
Forrás: (Schreckenbach, 2014)

Annak ellenére, hogy az SAP számos konfigurációs lehetőséget kínál, csak azokat a

beállításokat módosítsuk, amik feltétlenül szükségesek. Egy upgrade váratlan

74
eseményekkel járhat ezért fontos a körültekintő tervezés minden rendszer változtatás

esetén.

Minden változtatásnál kövessük az alábbi lépéseket: Test system, Development System,

Quality assurance system, Production system.

10 Hasznos tranzakciók listája

5. Táblázat: Rendszeradminisztrációhoz kapcsolódó hasznos tranzakció kódok

Rendszer adminisztrációs kódok

RZ03 Működési módok, instanciák áttekintése.
RZ04 Működési módok és instanciák karbantartása.
RZ10 Profil adatok karbantartása.
RZ11 Profil paraméterek listája.
SCC4 Kliens adminisztráció.
SCC5 Kliens törlése.
SM02 Rendszer üzenetek.
SM04 Aktív (bejelentkezett) userek listája.
SM12 Zárolások.
SM21 Rendszer log áttekintése.
SM50 Folyamatok listája.
SM51 Szerverek felsorolása.
SM59 RFC kapcsolatok áttekintése.
SM63 Működési módok létrehozása.
SMGW Gateway monitorozás.
ST22 ABAP dump analízis.
RZ20 Memória monitorozás
RZ21 CCMS konfigurációja
Forrás: (Schreckenbach, 2014)

6. Táblázat: Leggyakrabban használt felhasználó adminisztrációs tranzakciók listája

Felhasználó adminisztráció
AL08 Aktív felhasználók listája (több instancián)
SM04 Bejelentkezett felhasznűlók áttekintése
SU01 Felhasználó karbantartás

75
 SU10 Kötegelt felhasználó kezelés
SUGR Felhasználói csoportok konfigurációja
SUIM User adminisztrációs információs rendszer
Forrás: (Schreckenbach, 2014)

7. Táblázat: Hasznos tranzakció kódok a jogosultság kezelés témakörben

Jogosultság kezelés
PFCG Profil generátor jogosultsági szerepkörökhöz
SU02 Authorizációs profilok karbantartása
SU53 Előző jogosultság ellenőrzések eredménye
ST01 Jogosultság monitorozás
Forrás: (Schreckenbach, 2014)

8. Táblázat:

Háttérfolyamatok készítése és karbantartása

RZ01 Ütemezett feladatok nyomon követése
SM36 Háttérfolyamatok készítése
SM36WIZ Háttérfolyamatok készítése varázsló segítségével
SM37 Háttérfolyamatok monitorozása
Forrás: (Schreckenbach, 2014)

11 Irodalomjegyzék

- Schreckenbach, S. (2014). Practical Guide - SAP Administration. Boston: Galileo

Press.

76
- Moxon, P. (2014). The Beginner's Guide to SAP. SAPPROUK.

- Mißbach, M., Sosnitzka, R., Wilhelm, M., Stelzel J., SAP System Operations,

SAPPRESS

- Hernandez, J. A., Koegh, J., Martinez F. F. (2007), SAP R/3 kézikönyv, PANEM

77