În timp ce reputaţia SAP a fost construită pe baza soluţiilor de business pe care compania e capabilă să le ofere clienţilor săi enterprise, platforma tehnică din spatele acestor soluţii nu a fost neapărat în centrul atenţiei. Iniţiativele SAP din ultima perioadă dau însă de înţeles că doreşte să schimbe acest lucru. Printre aceste iniţiative se numără şi decizia de a porta mediul clasic de dezvoltare ABAP de pe interfaţa obişnuită SAP GUI pe o platformă modernă cum este Eclipse.
Însă, dacă un programator nefamiliarizat cu mediul SAP va presupune că Eclipse nu e decât "un alt IDE", un dezvoltator ABAP va recunoaşte imediat că tranziţia către acest nou IDE nu este una care să poată fi făcută cu una, cu două. Motivul constă în faptul că întreg procesul de dezvoltare ABAP se desfăşoară după un alt tipar decât cel întâlnit în mod obişnuit la proiectele dezvoltate utilizând platforma Eclipse. În rândurile ce urmează vom analiza aceste procese, diferenţele dintre ele şi modul în care a fost proiectată integrarea ABAP în Eclipse pentru a le soluţiona.
Pentru început vom arunca o privire asupra modului în care se desfăşoară un proces tipic de dezvoltare software atunci când se utilizează un IDE precum Eclipse. Analiza se realizează în special din perspectiva integrării continue şi a modului în care "afectează" aceasta procesul de dezvoltare.
În mod obişnuit în aceste situaţii proiectul se află stocat într-un repository central, însă dezvoltarea propriu-zisă se desfășoară local. Fiecare developer va avea o copie locală a proiectului, iar dezvoltarea are loc cu ajutoril IDE-ului de pe propriul calculator, care pune la dispoziţie o serie de tool-uri şi funcţionalităţi în acest scop. O dată ce dezvoltarea a fost finalizată, modificările pot fi transferate înapoi în repository. Prin acest proces se realizează implicit o versionare a modificărilor, se rezolvă problema accesului concurent la obiecte, iar consistenţa proiectului este asigurată prin build-urile realizate periodic pe baza codului din repository.
Pentru a evidenţia difenţele dintre dezvoltarea software ABAP şi modul de lucru prezentat anterior, vom prezenta câteva dintre aspectele care ţin de specificul SAP. O dată ce aceste aspecte au fost analizate putem face o evaluare mai precisă a consecinţelor pe care le aduce cu sine trecerea pe ABAP în Eclipse.
În cazul unui proiect SAP tipic, avem de-a face cu un "landscape" de sisteme , fiecare sistem având un rol bine definit, cum ar fi dezvoltare, QA, integrare, producţie.
Dezvoltarea se face doar pe sistemul de development, iar atunci când un programator ABAP efectuează o modificare pe acest sistem, ea este salvată în registrul intern de versionare al sistemului şi asignată unui "transport request".
Acest request este practic un container al cărui rol este(printre altele) să grupeze mai multe astfel de modificări efectuate pe sistem. O dată ce implementarea s-a încheiat, request-ul e folosit pentru a transporta modificările respective de pe sistemul de development pe celelalte sisteme din landscape, urmărind anumite căi de transport predefinite.
În cazul proiectelor SAP, dezvoltarea propriu-zisă nu are loc prin editarea locală a obiectelor, ci live pe application server-ul ABAP. Acest lucru aduce cu sine o serie de alte probleme care trebuie rezolvate, precum:
Pentru a facilita dezvoltarea server-side şi editarea obiectelor din R/3 Repository , application server-ul ABAP pune la dispoziţie un mediu de dezvoltare integrat: ABAP Workbench. Acesta este format din tool-uri diverse, menite să suporte întregul ciclu de dezvoltare software.
Dezvoltarea software în mediul SAP nu ar fi posibilă fără aceste tool-uri. În consecinţă orice mediu de dezvoltare care se vrea un înlocuitor pentru workbench-ul ABAP trebuie să pună la dispoziţie aceste funcţionalităţi.
Primele încercări de a porta workbench-ul ABAP în Eclipse au avut loc acum aproape un deceniu, iar de atunci şi până acum diverse companii au creat plugin-uri care să permită dezvoltarea ABAP în Eclipse, plugin-uri care între timp au ajuns la un nivel foarte bun de maturitate.
Cu toate acestea, în cadrul acestui articol ne vom îndrepta atenţia către soluţia care, deşi a fost lansată de mai puţin de un an, probabil se va impune în scurt timp în faţa celorlalte alternative, şi asta pentru faptul că este soluţia oficială lansată chiar de SAP.
"ABAP Development Tools"(ADT) este numele oficial sub care este promovat pachetul care face posibilă dezvoltarea ABAP în Eclipse. Conform SAP, scopul ADT este creşterea productivităţii programatorilor ABAP prin punerea la dispoziţie a unui mediu de lucru care integrează capabilităţile workbench-ului ABAP într-o interfaţă puternică şi modernă bazată pe platforma Eclipse.
Pentru a obţine un mediu de dezvoltare ABAP puternic, e nevoie ca tool-urile care formează Workbench-ul ABAP să fie făcute disponibile şi pentru platforma Eclipse. Întrebarea la care ne-am propus să găsim răspuns este: Cum se realizează integrarea dintre Eclipse şi ABAP pentru a face acest lucru posibil?
Răspunsul scurt: Expunerea de servicii REST3 în application server-ul ABAP, şi consumarea acestor servicii din Eclipse.
Pentru a elabora răspunsul - pachetul ADT este format din două componente:
Practic, prin analogie, putem comparara Eclipse cu un browser web, dar care permite navigarea nu pe pagini web, ci prin repository-ul de obiecte R/3 . În acest fel modul de dezvoltare rămâne în continuare server-based: obiectele nu sunt stocate local ci editate direct pe server prin intermediul serviciilor REST.
Operaţiile tipice pentru dezvoltarea ABAP("where-used list", verificarea &activarea de obiecte, managementul transporturilor etc.) se realizează de asemenea prin apelarea unor servicii în back-end şi prezentarea lor în mod corespunzator pe interfaţa Eclipse.
Având în vedere arhitectura orientată pe servicii a ADT, care aduce cu sine un potenţial ridicat de extindere şi reutilizare, SAP a hotărât să pună la dispoziţia programatorilor şi un Software Development Kit(SDK) pentru ADT. SDK-ul permite oricui să creeze tool-uri terţe care pot îmbunătăţi/uşura procesul de dezvoltare ABAP.
Ţinând cont de dimensiunea comunităţii Eclipse, e de aşteptat ca şi aceasta să contribuie în mod decisiv la dezvoltarea şi maturizarea rapidă a platformei ADT. Un proiect pilot bazat pe ADT SDK a fost pornit deja şi are ca scop integrarea SAPLink 5în Eclipse.
Dacă din punct de vedere tehnic am constat că au fost găsite o serie de soluţii ingenioase pentru a face integrarea ABAP în Eclipse posibilă, în continuare vom analiza ABAP Development Tools şi din perspectiva funcţionalităţilor oferite la momentul de faţă.
Realizarea conexiunii către un anumit application server ABAP se realizează prin intermediul proiectelor Eclipse. Fiecare proiect ABAP în Eclipse se mapează pe un singur sistem şi conţine datele de conectare pentru acesta. În acest fel devine posibilă conectarea din Eclipse simultan către mai multe sisteme SAP.
Dacă în cadrul workbench-ului ABAP editarea codului e posibilă atât în mod "source-code based" cât şi "form-based", în Eclipse abordarea form-based nu va mai fi suportată. SAP argumentează că studiile efectuate în acest sens au demonstrat că dezvoltarea "source-code based" utilizând un editor puternic este mai eficientă decât editarea codului sursă "fragmentat" în form-uri multiple.
Dincolo de acest aspect, puterea şi flexibilitatea editorului din Eclipse pot aduce pe termen lung multe beneficii programatorilor ABAP.
Verificarea şi activarea obiectelor se numără printre funcţiile care au fost integrate complet în Eclipse încă din prima versiune ADT şi funcţionează la fel de bine în Eclipse ca şi în SAP GUI.
De asemenea, prin utilizarea Eclipse, utilizatorul va avea parte de doua sisteme de versionare ale modificărilor independente: atât cel de pe application server-ul ABAP cât şi cel local din Eclipse.
În categoria tool-urilor portate complet pe Eclipse intră cel pentru managementul transporturilor: ADT oferă întreaga paletă de funcţii necesare pentru gestiunea request-urilor direct din interfaţa Eclipse.
Cu toate acestea, din păcate nu se poate spune acelaşi lucru şi despre celelalte tool-uri considerate esenţiale pentru dezvoltarea ABAP. Utilitarele folosite pentru editarea obiectelor de Data Dictionary, a screen-urilor şi a altor obiecte nu au fost încă portate în interfaţa Eclipse. Ca o măsură provizorie în încercarea de a compensa pentru acest neajuns, atunci când se doreşte editarea unui astfel de obiect, utilizatorul va avea surpriza de a vedea că tool-ul respectiv, rulând în interfaţa obişnuită SAP GUI, va fi pornit şi afişat în cadrul unui tab Eclipse.
Conform SAP, o parte din aceste tool-uri vor fi integrate în release-urile ADT viitoare, în timp ce pentru altele actualmente sunt evaluate noi soluţii, care pe termen lung se mulează mai bine pe strategia de termen lung gândită de SAP.
Unul dintre feature-urile esenţiale care au lipsit din prima versiune ADT a fost posibilitatea de a utiliza debugger-ul Eclipse pentru depanarea aplicaţiilor ABAP.
Sfârşitul anului 2012 a adus însă şi o noua versiune de ADT (2.0), iar printre îmbunătăţirile acestei versiuni se numără şi integrarea framework-ului pentru testare şi debugging ABAP cu debugger-ul nativ Eclipse.
Deşi s-ar putea ca momentan mulți dintre dezvoltatorii ABAP să fie încă reticienţi în ceea ce priveşte "migrarea" de la workbench-ul ABAP către ABAP în Eclipse(şi asta pe bună dreptate având în vedere lacunele pe care cel din urmă le prezintă în momentul de faţă), este de aşteptat ca pe viitor, odată cu maturizarea acestuia, balanţa să se încline către ADT.
SAP şi-a făcut publică intenţia de a nu mai investi în dezvoltarea workbench-ului ABAP classic, şi chiar mai mult - de a încuraja trecerea către Eclipse prin oferirea anumitor funcționalităţi în exclusivitate prin ADT. Un exemplu reprezentativ în această direcţie este SAP HANA Studio, colecţia de tool-uri pentru gestiunea bazei de date in-memory SAP HANA, disponibilă doar în Eclipse. Luând în considerare aceşti factori, trecerea dezvoltatorilor ABAP către Eclipse nu mai pare atât o incertitudine, cât mai degrabă o chestiune de timp.
1 Lock-ul este obtinut înainte de a edita un obiect. Consecinta este ca orice obiect aflat deja în editare de catre un alt utilizator nu mai poate fi accesat decât în mod read-only.
2 Granularitatea acestor lock-uri depinde de tipul de obiect care este editat(de ex. în cazul functiilor întreaga functia va fi blocata, în timp ce în cazul unei clase lock-ul este creat la nivel de metoda a clasei)
3 Definitia conceptului de servicii REST: en.wikipedia.org/wiki/Representational_State_Transfer
4 Acest enhancement este disponibil în backend-ul ABAP doar începând cu Netweaver 7.31 SP04(lansat în iunie 2012)
5 SAPLink este un tool care uşurează distribuirea aplicaţiilor ABAP, permiţând crearea de pachete de obiecte("nuggets"), şi exportarea/importarea acestora în sistemele SAP
de Ioan Bercea
de Alex Luca
