BW rendszer migrációs projekt tapasztalatai

A BW rendszer migrációs projekt célja, keretek

Előszó

Amelyben megismerjük a főhős legjobb barátját az Ügyfelet…

Az ügyfél a SAP BW rendszerének fejlesztését sok-sok évvel ezelőtt kezdte, és HANA rendszerre való átállásának első fontos lépését, az adatbázis migrációját 2018-ban végezte el. A következő lépés ezen az úton, az objektumok migrációja.

Az ügyfél igénye, illetve a projekt kiírás szerint a meglévő modelleket funkció azonosan kellett újraépíteni Hana kompatibilis objektumokból. Elvárás volt, hogy az új objektumok, modellek éles indulása után a régi és az új modelleknek párhuzamosan kell működnie egy meghatározott ideig, hogy az éles rendszeri működés során, több hónap adattöltési-üzemeltetési és riport futtatási tapasztalata alapján tudjuk kimondani, hogy az új modellek megfelelően működnek. Ezután lehet a régi modellek töltését leállítani, majd egy későbbi fázisban, az adattartalmát törölni.

Tervezés, előkészítés

Első fejezet

Amelyben a főhős megismeri, majd megérti a feladatot, elhűl, elsápad, majd feltűri az ingujját…

A projekt első lépéseként határoztuk meg a pontos terjedelmet. Ez az egyik legfontosabb lépés, mivel egy menet közben felmerülő, nem tervezett objektumtípus, modellrész könnyen adhat annyi plusz feladatot, amivel a rendelkezésre álló idő-, és erőforrás keretek már nem tarthatók.

Az adott projekt terjedelméből kizártuk a fejlesztéssel megvalósított, bonyolultabb modelleket. Ezek felmérése és átalakítása nem fért volna bele a rendelkezésünk álló időkeretbe. A tervezési objektumok migrálását a projekt keretében, de az ügyfél IT szakértő kollégák végezték el, így a teljes modellek migrálása megtörtént. A cél nem teljes átállás volt, hanem egy több fázisban végrehajtható, ellenőrzött, stabil működést biztosító migráció.

A projekt kezdeti szakaszában felmértük az átalakítandó modelleket, és minden modellre megalkottuk az AS-IS ábrákat, valamint a teljes objektumlistát, amely tartalmazta az érintett infoprovidereket, infoforrásokat és adatforrásokat. Következő lépésben, az így kialakult ábrákat és listákat validálták az ügyfél IT szakértői, ezzel pontosítottuk a projekt terjedelmét. A projekt ezen fázisában különösen fontos, hogy az adott rendszert jól ismerő és felkészült szakértők vegyenek részt az ügyfél oldaláról, az ő tudásuk és tapasztalatuk elengedhetetlen a teljes kép kialakításához.

Természetesen, az egyes modellek felméréséhez hozzátartoztak a modellek közötti, illetve a más, a terjedelembe nem tartozó részekkel való kapcsolatok felmérése, meghatározása is.

Külön feladatként, az objektumlistában szereplő minden objektumra vonatkozóan fel kellett térképezni a rendszerben található fejlesztéseket. Itt listázni kellett nem csak a fejlesztett programokat, funkciós elemeket, táblákat, tranzakciókat, de a transzformációk, user-exit kódok, DTP szűrések bármely rutinjában szereplő hivatkozásokat is.

Az elkészült AS-IS ábrák és listák alapján készítettük el a TO-BE ábrákat, amelyek a kívánt modellábrákat, kapcsolatokat és objektumokat tartalmazták. A TO-BE ábrákkal párhuzamosan minden területen, minden modellre vonatkozóan készült egy objektumlista is, amely tartalmazta az eredeti objektum kódját, nevét, típusát, az ez alapján készítendő új objektum nevét, kódját és típusát is. A modellenkénti objektumlisták összevonásával készült egy teljes projektre vonatkozó objektumlista is, ami alapját képezte nemcsak a projekt végén készített statisztikáknak, de fejlesztésekben való hivatkozások keresésének is.

Az elkészült objektumlista alapján elvégezhető volt a jogosultsági szerepek és objektumok módosítása.
A TO-BE ábra és az objektumlista mellett a design dokumentáció részét képezte a másolandó riportok és az átalakítandó munkafüzetek listája is. A felhasználók BEx munkafüzeteket használnak, ezért fontos volt, hogy minden másolandó lekérdezést ki tudjunk cserélni a kapcsolódó munkafüzetekben.
A másolandó riportok meghatározásánál az éles rendszerből vett riport futásidő statisztika riport eredményét vettük alapul. Általában a futtatások darabszáma alapján határoztuk meg, hogy mely riportok kerülnek másolásra, melyek nem, de a területet és a felhasználók szokásait ismerő ügyfél oldali szakértők nagyon nagy segítséget nyújtottak a másolandó riportok kiválasztásában, validálásában is.

Ezen a ponton próbáltuk meghatározni, hogy melyek azok a modellek / modell részek, amelyeknél – a kialakításukból fakadóan – a régi és az új modell nem működtethető párhuzamosan, esetleg az új modell nem állítható elő másolással, csak a meglévő modell módosításával. Ez következhet abból, ha a hozzá kapcsolódó fejlesztés túl sok más objektumot (táblát, tranzakciót) használ, ezért túl nagy feladat lenne a teljes programcsomag másolása.

Másik ilyen problémás eset lehet a hibrid modell használata, amikor egy új composite providerbe egy régi típusú infokocka vagy SPO került beillesztésre.

A composite provider alá bekötött infokocka helyett aDSO-t hoztunk létre, és a composite providerben, replace funkcióval kicseréltük az infokockát az új aDSO-ra. Így a composite providerre épített további objektumok (query, calculation view) módosítására már nem volt szükség.

Azokban az esetekben, ahol a régi és az új modell nem működtethető párhuzamosan, a transzportálás előtt lefuttattunk egy lekérdezést (előtte állapot), majd a transzportálás után újra lefuttattuk ugyanazt a lekérdezést (utána állapot). A tesztelés az előtte és az utána állapotok összehasonlításával történt.

A területek felmérése során külön figyelmet kellett szentelni a még meglévő és üzemelő 3.x-es töltések átalakítására.

BW rendszer migrációs projekt megvalósítása

Második fejezet

Amelyben kő-kövön, infoset-kockán nem marad, csak úgy hullik az infóforrás…

Az SAP ajánlás szerinti migrációs program arra készült, hogy egy felső szintű objektum megadásával, a program feltérképezi a teljes modellt, minden kapcsolatával együtt, és minden érintett (migrálandó) objektumot migrál. Azoban ez a program nem volt alkalmas teljes modell részek migrálására.

Amennyiben 3.x-es töltési ágat vagy SPO-t talált, hibaüzenettel megállt a programfutás. Ezért a legtöbb terület backend objektumainak másolása manuálisan történt. Új DTP-ket hoztunk létre, a DTP szelekciókat manuálisan másoltuk.

A meglévő folyamatláncok alapján alakítottuk ki az új folyamatláncokat, a párhuzamos működés igénye miatt a meglévő láncokba kerültek beillesztésre az új modellágakat töltő új láncok.

Új modellek töltési módszertana

Fontos kérdés, hogy miként tudjuk legegyszerűbben megduplázni adatbázisunk méretét.

A választott megközelítés szerint, az új modellágakat nem az adatforrásokból töltjük meg teljesen, hanem az LSA koncepció szerint felépített modellek működésének megfelelően, a legalsó szintű DSO-ból. A felette lévő objektumokat pedig már az új modellágon belül, alulról töltjük. Ez a megoldás akkor használható, ha az alsó szintű DSO-k tartalmaznak minden szükséges adatot.

Ezt a megközelítést elsősorban az adatforráson keresztüli töltések nagy időigénye, másrészt a LIS-es adatforrások setup műveletének bonyolultsága miatt választottuk. A megoldás előnyeihez sorolnám, hogy így az alsó szintű DSO-k feletti transzformációk, töltések is tesztelésre kerültek.

A tesztelések során a meglévő modellek számos hiányossága, hibája kiderült. Ha a modellen belüli töltés transzformációjában olyan logika szerepelt, ami miatt nem volt lehetséges a felső szintű objektum újratöltése, akkor a felső szinten is kialakítottunk oldalági töltést.

Mit mire másoltunk?

A kérdés feleslegesnek tűnik, mert az SAP-s oktatási anyagok, interneten is elérhető tájékoztatók alapján egyértelműnek tűnik a válasz, mégis vegyük végig néhány szóban, a konkrét tapasztalatok alapján.

Klasszikus DSO

Itt valóban nincs kérdés. Minden DSO-nak létezik advanced DSO párja, megfelelő paraméter beállításokkal.

SPO

SPO lehet infókocka vagy DSO típusú. Felmerülhet a kérdés, hogy ha egy adott objektum partícionálva van, akkor érdemes-e az új objektumot is megbontani valamely jellemző mentén. Az SAP ajánlása szerint, 2 milliárd rekord felett érdemes szemantikai partíciót beállítani egy aDSO-ra. Ez alatt a rendszer automatikusan, adatbázis szinten végez tábla bontást, nem szükséges hozzá külön beállítás.

Az SPO-k esetében az oldalági töltés is felvet néhány kérdést. Az oldal irányú töltések minden esetben HANA kompatibilis töltések, a legritkább esetben alkalmaztunk bármilyen logikát, átalakítást (szöveg-karakter tisztítás). Azonban az SPO-kból való töltés hatalmas memória igénnyel jár, sok esetben meghaladtuk egy memória paramétert (Global Memory Allocation Limit). A memória limit túllépése a rendszer leállásához vezet.

Az SAP ajánlása alapján, partíciónkként kell a töltést kialakítani. Próbáltuk a töltéseket több részletben, évekre bontva elvégezni. A legtöbb problémás esetben ez megoldást jelentett, de néhány adattároló esetében periódus bontásra is szükség volt. Volt, ahol nem Hanas töltést választottunk, így a töltés az applikációs szerveren (és nem memóriában) futott, így jelentős memória felhasználás nélkül, és nagyon hosszú idő alatt, de lefutottak a töltések.

Infókocka

Infókockából is a legtöbb esetben aDSO lett, de nem mindegy, hogy milyen paraméterezéssel. Ha az aDSO-t másolással hozzuk létre, akkor automatikusan infokocka típusú aDSO-t kapunk. A legtöbb esetben ez meg is felelt a célnak.

Az infokocka típusú aDSO-nak azonban van néhány sajátossága. Ha aktiváljuk a töltések kérelmeit, akkor a továbbiakban nem lehetséges a kérelmek törlése, ez gyakorlatilag a korábbi kompresszálás funkciónak felel meg. Ilyen esetekben azt a megoldást választottuk, hogy a folyamatláncokba a „cleanup” elemet tettük, ahol beállítható, hogy mi történjen a régi kérelmekkel. Általában azt állítottuk be, hogy a 30 napnál régebbi kérelmek kerüljenek aktiválásra. Volt olyan objektum, ahol az adatokat változatlan formában meg kell őrizni, tehát nem lehetséges egy esetleges újratöltés, itt gond lehet, ha esetleg egy kérelem véletlenül aktiválásra kerül, és nem törölhető. Itt elgondolkodtunk azon, hogy infokocka típusú aDSO helyett normál aDSO objektumot hozzunk létre, szerencsére az új aDSO lehetséges kulcsainak száma nem korlátozza ezt a beállítást. Ennek eldöntéséhez az adott modell sajátosságait kell megvizsgálni.

Némely modell esetén, ahol a legfelső szintű DSO és az infokocka között nem volt üzleti logika leképezve a transzformációban, az új modellben elhagytuk az infokocka szintet, és a composite providerbe közvetlenül az új aDSO-t tettük.

Multiprovider

A multiproviderek helyett minden esetben composite providert hoztunk létre.

Infoset

Az infosetek másolása sajnos minden esetben problémás volt. A legtöbbször egyszerűbbnek tűnt nulláról újra felépíteni a composite providert, és úgy másolni a riportokat a két objektum között. Néhány esetben úgy döntöttünk, hogy az adott infoset céljaira a későbbiekben calculation view-kal megvalósított virtuális modellt hozunk létre.

A fenti ábra a régi és az új modellekben szereplő infoproviderek számát hasonlítja össze. Fontos megjegyezni, hogy a régi modellekben az SPO-k partíciót külön objektumként számoltuk. Karbantartási – üzemeltetési szempontból ezt indokolt lépésnek gondolom.

Fejlesztések, programok

Egy ilyen méretű és bonyolultságú projekt nem lehet meg legalább egy nagy munkabírású és türelmes fejlesztő segítsége nélkül. Az igazi problémát nem is a transzformációs kódokban elrejtett objektum hivatkozások, olvasások megtalálása és cseréje jelenti, hanem a bonyolult, és túl régen, valamint alapos dokumentáció nélkül használt egyedi fejlesztések feltérképezése és aktualizálása. A tranzakciókód csak a jéghegy csúcsa. Ennek a problémának a megoldására nem létezik általános módszertan, de csak három dolog kell hozzá… ?

Külön kérdésként felmerült, hogy a projekt során lehet-e, érdemes-e a transzformációkban szereplő ABAP-kódokat AMDP-scriptekre cserélni. Általános szabályként azt gondolom, hogy csak ott érdemes megvizsgálni, ahol az aktuális töltési idők ezt indokolják. A kódok átírásával egy újabb hibalehetőséget rejtünk el a modellben, amelynek tesztelése nehézkes, és nagyobb erőforrást igényel.

BW rendszer migrációs projekt tesztelése

Harmadik fejezet

Amelyben a főhős azt hiszi, hogy megpihenhet, de téved…

A fejlesztői tesztek leginkább a párhuzamosan kialakított objektumok adattartalmának ellenőrzéséből álltak. Az alsó szintű objektumok adattartalma 1:1 töltésekkel álltak elő, így itt nem nagyon fordult elő eltérés, a felette lévő objektumok töltése viszont már lehetővé tette az új modellágak működésének ellenőrzését.

Az ügyfél oldali integrációs tesztelés alapvetően az előre kijelölt típus riportok összehasonlításával történt. Egy hihetetlen monotonitástűrő és precíz kolléga lefuttatja a régi, majd az új riportot, azonos szelekciókkal, több szempont szerinti bontással, majd összehasonlítja az eredményeket, és megtalálja a tűt a szénakazalban. Innen indul a sziszifuszi nyomozás, hogy a „tű” hogyan került oda.

A módszertanból következően, a tesztelés egy statikus, pillanatnyi egyezőség ellenőrzését tette lehetővé. Nem volt lehetőség arra, hogy folyamatos adattöltésekkel teszteljük a forrásrendszerből való új töltések helyességét. Ezért külön jelentőséget kapott az éles rendszerben történő párhuzamos működés. Ennek a megoldásnak az volt a hátránya, hogy a párhuzamos működés átmeneti időszakára, az éles rendszerben a felhasznált memória mérete közel a duplájára nőtt.

Éles indulás, kezdeti éles töltések

Negyedik fejezet

Amelyben elkövetkezik a nagy nap…

Az éles indulás előkészítése alapos tervezést, és minden értintett fél bevonását igényli. Nem elég a transzportok előkészítése, ellenőrzése, a kapcsolódó adminisztráció elvégzése, számos egyéb feladatot is végig kell gondolni, elő kell készíteni.

A teszt rendszeri töltések tapasztalatai alapján terveztük meg az éles rendszeri töltések sorrendjét. Az éles rendszerben figyelni kellett, hogy a nagy mennyiség adatok töltésével ne terheljük túl a rendszert, ezért a teljes adattöltést 2 hétre széthúzva terveztük meg. Ez viszont azt jelentette, hogy bár az éles transzportok importja után minden objektum elérhető és működőképes volt az éles rendszerben, amíg a tároló objektumok nincsenek megtöltve, addig az új riportok nem hoznak adatot. Ezért a munkafüzetek transzportját és a felhasználók értesítését az éles rendszeri adattöltések utánra terveztük be.

Az adattöltések után az éles rendszerben be kellett ütemezni az új folyamatláncokat, hogy az új modellágak is napi szinten töltődjenek. Ezután az éles riportokat is ellenőriztük, összehasonlítottuk a régi és az új riportokat.

Egy ilyen szintű átalakítás során nagyon fontos a felhasználókkal való megfelelő kommunikáció. Értesíteni kell őket arról, hogy egy technikai migrációs lépés történt a rendszerben, ami funkcionális változást nem hoz az riportok működésében, de fontos, hogy használják az új riportokat, és azonnal jelezzék, ha valami eltérést vesznek észre.

BW rendszer migrációs projekt vége, követő feladatok

Utószó

Amelyben mindenki megnyugszik és jól megérdemelt pihenését tölti…

Természetesen egy ilyen projektnek még sokáig nem lesz vége. Mindig találunk olyan hibákat, változásokat, apró feladatokat, amelyek még egy-két hónap elteltével is eszünkbe idézik az egyébként sikeres projekt nehézségeit.

Mivel az éles rendszerben párhuzamosan működnek a régi és az új modellágak, ez igen nagy mértékben megnöveli a memória használatot. Szükséges egy olyan követő feladat elvégzése, amely felméri és megtervezi a régi modellágak leállítását és a régi tároló objektumok tartalmának törlését.

Az ügyfél szakértőinek véleménye alapján, az a döntés született, hogy a régi objektumok nem kerülnek törlésre, csak a tartalmukat törlik idővel, az objektumokat pedig archív (infó)területre mozgatják, így a meghatározott üzleti logikák később is elérhetőek – visszakereshetőek lesznek.

Az objektumok tartalmának törlésére egy prioritás sorrendet állítottunk fel. Eszerint, ha egy adott modell esetében az új modellág és riportok megfelelő ideje működnek hiba nélkül, akkor első lépésben a régi modellágban az infokockák tartalma törölhető. Biztonsági okokból az alatta lévő DSO-k tartalmát majd egy következő lépésben szükséges törölni.

A logisztikai adatforrásokra (2LIS_*) épülő modellek esetében a régi adatok megtartásának biztonsági idő intervallumát egy kicsit nagyobb értéken határoztuk meg. Ha újratöltés szükséges, ezen adatforrásokból a múltbeli adatok setup folyamata jóval bonyolultabb és időigényesebb feladat.

Az ügyféltől pozitív visszajelzéseket kaptunk, így a projektet mindenképp sikerként könyveljük el. Rengeteg tapasztalatot szereztünk, mindenféle BW-s objektummal találkoztunk, megismertük a legtöbb alaprendszeri üzleti modellt és azok sajátosságait, foglalkoztunk a modellek történetiségével, és elgondolkodtunk azon, hogy miként lehetett volna, mit tudtunk volna jobban csinálni.

Ami legalább ennyire fontos, sok hónap intenzív, közös munka alatt nagyon jó kapcsolat alakult ki az ügyfél IT csapat szakértőivel, ha magukra ismertek, ezúton is köszönöm nekik a sok segítséget és bizalmat, amit felénk nyújtottak.

Tekintse meg további bejegyzéseinket!