SAP Rendszerüzemeltetés

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

3

2.1

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

2.2

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

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

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

3.2

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

3.2.1 3.3

4

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

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

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

5

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

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

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

7

8

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

6.2.1

Feladat ........................................................................................................... 62

6.2.2

Feladat ........................................................................................................... 62

6.2.3

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

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

Backup és restore műveletek ....................................................................................... 69 8.1.1 8.2

9

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

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

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ó szerver

adatbázis Dialóg instancia

Adatbázis: SQL szerver, DB2, Oracle, stb.

15

Applikációs

Applikációs

Centrális

réteg

szerver(ek)

instancia

SAP rendszer

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>//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.

6

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

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__”) 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>__”) 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 kód DB12 / DB13 SM51 AL08 / SM04 OS06 SM37 / RZ01 SM12 SM13 SM21 SM50/SM51 SP01 ST02 ST03 ST04 ST22 STMS

Elvégzendő feladat Az adatbázis mentések ellenőrzése. Ellenőrizzük, hogy az összes szerver fut e. Az aktuálisan bejelentkezett felhasználók ellenőrzése, többszörös bejelentkezések szűrése. 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, aminek az eredményétől függhetnek más feladatok. A zárolt műveleteket tekinthetjük át. Report az update-ekről. Rendszer log elemzés. A processzek állapotát tudjuk áttekinteni, a túl hosszan vagy nem megfelelően futott folyamatokat szűrjük. Beragadt nyomtatási feladatokat keresünk. Adatbázis és operációs rendszer paraméterek áttekintése, buffer kapacitás ellenőrzése. Rendszer teljesítmény ellenőrzés. Magas szintű adatbázis monitorozás. ABAP dump logok. 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 stratégiánkat Készítsünk egy vészhelyzeti tervet Source: (Schreckenbach, 2014) sdg

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 Dátum

Feladat

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