Migrarea de date este procesul de mutare a datelor dintr-un sistem-sursă într-un sistem-țintă. Aceasta este cea mai simplă și clară definiție care poate fi dată procesului în sine. În acest articol urmează să vedem ce, de ce, când, de unde/unde și cum migrăm aceste date din și în sisteme SAP. Considerând interesul și necesitatea din ultimii ani de a trece de la sistemele SAP R/3 la cele S/4 HANA, informațiile prezentate în continuare vin din experiențe avute în proiecte de acest tip. Pentru mai multe detalii despre sistemele SAP S/4 HANA, vă recomand articolul lui Bogdan Bucur, SAP HANA ca bază de date.
Da, într-adevăr acest subiect al migrărilor de date este unul de nișă, deși a fost dintotdeauna unul provocator din punct de vedere atât al sistemelor cât și al aplicațiilor SAP, cel puțin. Acum, vă invit să conturăm împreună viziunea asupra migrărilor de date în SAP.
Figura 1: Procesul migrării de date
Prima metodă de a migra date a fost cea manuală. Dar odată cu trecerea timpului și volumul datelor creștea, demonstrându-se că acest fel de a copia date dintr-o parte în alta nu mai era potrivit. Printre dezavantajele acestui fel de a manipula date doresc să menționez timpul crescut de lucru și posibilitatea foarte mare de a apărea erori umane în procesul de copiere. Din acest motiv, s-a urmărit dezvoltarea aplicațiilor care să vină în ajutorul situațiilor de acest fel.
SAP eCATT (extended Computer Aided Test Tool) a fost prima aplicație SAP creată cu scopul de a migra date, fiind disponibilă începând cu release-ul 3.0 din 1998. Aceasta se află în sistemul-țintă și se bazează pe înregistrarea efectivă a pașilor făcuți într-o anumită tranzacție SAP (recording). Până să ajungă la acest ultim pas de încărcare efectivă a datelor în sistem, datele sunt citite dintr-un fișier text, apoi sunt trecute prin înregistrarea definită anterior, aceasta încărcând datele în sistem.
Această primă aplicație a fost urmată de SAP LSMW (Legacy System Migration Workbench), fiind disponibilă începând cu release-ul 4.0, tot din 1998. La fel și aceasta se află în sistemul-țintă, însă prezintă mai multe modalități de încărcare a datelor: înregistrarea tranzacțiilor, Batch-Input, Direct-Input, BAPI (Business Application Programming Interface). După cum îi spune și numele, această aplicație este o aplicație destinată migrărilor de date dintr-un sistem vechi într-unul nou.
Revenind la trecerea timpului și la creșterea volumului de date, odată cu release-ul 6.0 din 2008 apare SAP BODS (BusinessObjects Data Services), aplicație ETL (Extract, Transform, Load) de sine stătătoare care se conectează atât la sistemul-sursă, cât și la cel țintă prin intermediul RFC (Remote Function Call). După ce conexiunile au fost stabilite, BODS trage datele din sursă în propriile Staging Tables, urmând ca tot în BODS să fie implementate toate regulile de migrare, ca datele-sursă să fie transformate, apoi încărcate în sistemul-țintă. Noutatea acestei aplicații o reprezintă aceste Staging Tables care au în spate un server SQL, fiind potrivită unui volum foarte mare de date.
Ultima noutate la nivel de migrare de date SAP o reprezintă aplicația Migration Cockpit, aceasta fiind disponibilă doar în sisteme S/4 HANA. Este tot o aplicație de tip ETL, însă oferă mai multe feluri de a încărca datele sursă: prin încărcarea unui fișier local, prin Staging Tables sau prin transfer direct din sistemul-sursă SAP. Migration Cockpit este disponibilă din 2017 odată cu release-ul S/4 1709.
Scopul unei aplicații centrate pe migrări de date este de a popula un sistem nou SAP cu datele necesare, prin urmare vorbim despre o încărcare inițială a datelor. Aceste aplicații nu sincronizează cele două sisteme, nici nu trimit actualizări.
Când vine vorba de implementarea unui sistem SAP, dorim să ne familiarizăm și cu cele trei strategii posibile pentru un asemenea proiect: Greenfield, Brownfield sau Bluefield.
Strategia Greenfield presupune o implementare complet nouă, un alt început care aderă la standardele și bunele practici SAP. În derularea unei asemenea implementări, toate procesele și sistemele sunt reinstalate și reconfigurate. Totul va fi revizuit și, unde este necesar, înlocuiri vor avea loc pe parcursul acestui proces.
Strategia Brownfield implică conversia unui sistem existent într-unul superior, cum ar fi conversia unui sistem SAP R/3 într-unul S/4 HANA. Totul va fi mutat în noul sistem printr-un upgrade.
Strategia Bluefield este una hibridă: se extrage configurația prezentă în sistem fără date și se transferă în noul sistem, urmând apoi selectarea și migrarea datelor relevante. Această abordare permite organizarea unei astfel de implementări în mai multe faze pentru diferite organizații și optimizarea timpilor de nefuncționare.
Figura 2: Comparație între strategiile de migrare
Menționat anterior, LSMW este unul din cele mai puternice aplicații disponibile într-un sistem SAP, capabil să încarce un număr mare de date. LSMW este comparabil cu ECATT sau SCAT, acestea fiind două tranzacții SAP cu multiple utilizări. Însă, avantajul LSMW este reprezentat de numărul de date procesate într-o singură soluție.
Prin intermediul LSMW putem crea, modifica sau chiar șterge date. Aplicația este foarte utilă pentru schimbări în masă care nu sunt suportate de tranzacții standard SAP. Datele pot fi transferate spre sistemul-țintă folosind următoarele metode:
Batch-Input - metodă care presupune reprocesarea datelor, implementarea este ușor-modificabilă și toate atributele sunt vizibile.
Direct-Input - similară cu Batch-Input oferă o viteză mare la încărcarea datelor.
Înregistrare a tranzacției - metodă care oferă o interfață funcțională utilizatorilor.
Realizarea obiectelor de migrare se face prin implementarea unor reguli de migrare, iar pentru aceasta recomandăm cunoștințe cel puțin minime de ABAP, fiind necesar să scriem regulile de migrare sub formă de cod.
Pentru proiectele de migrare de date către sisteme S/4 HANA, SAP nu mai oferă suport pentru LSMW, însă aplicația este în continuare perfect funcțională, singurele provocări întâlnite până acum fiind la crearea înregistrărilor pe tranzacția BP (Business Partners).
Figura 3: Privire asupra LSMW
SAP BODS este o aplicație de integrare și transformare de date. Aceasta ne permite să dezvoltăm și să executăm fluxuri de lucru care prelucrează date din surse predefinite (aplicații, servicii web, baze de date etc.). Apoi ne permite să transformăm și să rafinăm acele date.
Întreaga suită BODS are o arhitectură pe trei niveluri care presupune interfețe cu utilizatorul precum Data Services Designer, o consolă de management, nivelul de aplicație care este reprezentat de serverul cu sarcini (Jobs), iar la final avem repository-ul local și pe cel central, unde toate obiectele sistemului sunt stocate.
Această aplicație oferă funcționalități pentru analiza textului, profilarea și auditul datelor și operații de calitate a datelor, cum ar fi potrivirea, geocodarea și standardizarea adreselor. Aplicația suportă atât procesarea loturilor, care este abordarea tradițională a transformării datelor, cât și serviciile în timp real care permit aplicațiilor să interogheze serviciile de date și să obțină un răspuns imediat bazat pe un flux de lucru predefinit.
Implementarea regulilor de migrare în BODS se face cu ajutorul SQL.
Figura 4: Privire asupra BODS
Această aplicație este disponibilă în toate sistemele SAP S/4 HANA, după cum am menționat anterior, însă pentru deblocarea funcționalității de ,,transfer direct" trebuie să instalăm add-on-ul DMIS în sistemul-sursă. Interfața principală este SAP Fiori, însă partea de modelare a obiectelor o facem în clasicul SAP GUI .
Încărcarea datelor o putem realiza în trei feluri: prin fișiere locale, Staging Tables sau prin transfer direct printr-o RFC. Spre deosebire de LSMW, această aplicație vine împreună cu serviciile de suport din partea SAP, iar spre deosebire de BODS, nu include costuri adiționale pentru varianta on-premise.
Migration Cockpit vine cu peste 170 de obiecte predefinite care acoperă toate entitățile de bune practici pentru datele master și cele tranzacționale. Obiectele acestea implică reguli de migrare predefinite între sursă și țintă. Dar atât regulile de migrare cât și obiectele pot fi modificate, extinse sau chiar create de la zero. Cunoștințele de ABAP ne sunt de ajutor din nou, iar în cazul modificărilor în special cele de ABAP OOP.
După citirea datelor din surse, această aplicație ne oferă posibilitatea de a le simula înainte de a le migra. Datele sunt apoi migrate prin diferite funcții, rapoarte standard SAP (API), acestea putând fi ulterior auditate.
Recomandăm evitarea upgrade-urilor către release-uri noi în timpul unui proiect de migrare, deoarece dorim eliminarea pierderii implementărilor realizate pentru livrarea proiectului.
Figura 5: Privire asupra Migration Cockpit
Scopul principal al acestui articol este de a reliefa importanța SAP Data Migration, dar și de a evidenția conturarea generală a toolurilor utilizate în asemenea proiecte, considerând în special cererea actuală de tranziție de la sistemele SAP R/3 către cele S/4 HANA.
Alegerea strategiei de migrare și a toolurilor folosite rămâne la latitudinea echipei de management al proiectului, în funcție de complexitatea, dependințele tehnice și pe cele operaționale, costurile și timpul necesar pentru diferitele faze.
Oricare ar fi motivul pentru migrarea datelor, obiectivul final este îmbunătățirea performanței corporative și furnizarea de avantaje competitive. Pentru a avea o transformare reușită, proiectele de migrări de date trebuie să beneficieze de atenția pe care o merită.
de Ovidiu Mățan
de Ovidiu Mățan
de Alexa Boga
de Ovidiu Mățan
