SAP CDS, fundația aplicațiilor SAP moderne
O introducere în Core Data Services fără jargon, pentru oricine lucrează cu SAP: key useri, consultanți, analiști și, mai ales, programatori.
Dacă ai auzit „CDS” într-o ședință și ai dat din cap fără să știi despre ce e vorba, ești exact publicul potrivit. Nu trebuie să știi să programezi. Explicațiile pornesc de la zero, cu analogii, iar cele două-trei secțiuni cu cod sunt marcate clar — le poți sări fără să pierzi firul.
Trei cuvinte de care ai nevoie
Baza de date este depozitul. Acolo stau efectiv toate datele firmei, în tabele — mii de tabele, cu nume ciudate ca VBAK sau MARA.
Serverul de aplicații este bucătăria. Acolo rulează programele care iau datele, le prelucrează și ți le arată pe ecran.
Un „view” este o fereastră. Nu conține date proprii; arată datele din tabele într-o formă mai potrivită pentru tine: doar coloanele care contează, cu nume pe înțeles, deja combinate din mai multe tabele.
CDS este limbajul în care se descriu aceste ferestre. Cam atât. Restul articolului explică de ce un lucru aparent banal schimbă atât de mult.
Povestea celor 12 milioane de rânduri
Un raport simplu: „vreau vânzările pe client, pe anul acesta”. Rezultatul final are 45 de rânduri — câți clienți are firma. Raportul rulează 4 minute. De ce?
Pentru că, în varianta veche, programul face cam așa: cere bazei de date toate pozițiile de comandă din sistem — 12 milioane de rânduri — le aduce, rând cu rând, în memoria serverului de aplicații, apoi le parcurge una câte una și adună. La final, 11.999.955 dintre ele sunt aruncate. Aproape tot timpul s-a dus pe cărat și pe triat, nu pe calculat.
Analogia bucătăriei
Imaginează-ți un depozit uriaș de ingrediente, iar bucătarul e la 200 de metri, în altă clădire. Clientul cere o supă.
Varianta veche: bucătarul cere să i se aducă tot ce ar putea avea nevoie — patruzeci de lăzi de legume, saci de făină, tot. Cărăușii fac zeci de drumuri. Bucătarul sortează, curăță, aruncă 95% și gătește o oală de supă. Timpul s-a dus în transport și triaj.
Varianta CDS: bucătarul trimite o rețetă precisă în depozit. Acolo, oamenii aleg, curăță, taie și fierb pe loc — pentru că acolo sunt ingredientele. Prin curte trece o singură oală, gata făcută.
Acesta e tot principiul: duci calculul la date, nu datele la calcul. În SAP i se spune code pushdown. A devenit posibil la scară mare odată cu SAP HANA — baza de date modernă a SAP, care ține datele în memorie și poate face calcule foarte rapid, pe multe nuclee deodată.
Ce este, de fapt, CDS?
CDS — Core Data Services — este limbajul cu care descrii, în SAP, cum arată datele tale și ce înseamnă ele. Scrii un fișier text, într-o formă apropiată de o frază în engleză, în care spui: „un «Document de vânzare» are aceste câmpuri, luate din aceste tabele, legate așa între ele; câmpul acesta se numește de fapt «Valoare netă» și e o sumă de bani”.
Două lucruri îl deosebesc de o simplă interogare obișnuită.
Primul: conține și înțeles, nu doar structură. Nu scrie doar „coloana NETWR, număr cu două zecimale”, ci „valoarea netă a comenzii, în moneda din câmpul alăturat, care se adună atunci când grupezi, se afișează a doua în listă și e vizibilă doar pentru cine are dreptul”. Toată informația suplimentară asta se scrie prin adnotări și e citită automat de restul sistemului.
Al doilea: se execută în baza de date. Un view CDS nu copiază și nu stochează nimic; e o rețetă. Când cineva îl folosește, rețeta se trimite în baza de date și rezultatul vine gata calculat. De aici vine toată povestea cu performanța.
Ce probleme rezolvă CDS-uri?
De ce merită să înveți despre CDS-uri, oricare ar fi rolul tău în companie?
Circulă o idee greșită: „CDS e treabă de programator”. Nu este. CDS e locul unde se întâlnesc, într-un singur fișier, trei lucruri care înainte stăteau separat: ce date există, ce înseamnă ele în business și cum arată pe ecran. Adică exact granița dintre funcțional și tehnic.
Și mai important: în S/4HANA, CDS nu mai e o opțiune, e infrastructura. Aplicațiile Fiori stau pe CDS. Rapoartele stau pe CDS. Interfețele cu alte sisteme stau pe CDS. Dacă nu știi nimic despre stratul ăsta, o bună parte din sistem rămâne o cutie neagră — și fiecare cerere mică trebuie să treacă prin altcineva.
Dacă ești key user sau end user
Nu vei scrie niciodată un view. Dar vei putea răspunde singur la întrebarea „de unde vine cifra asta?”. Aplicațiile Fiori îți arată, în meniul de informații, numele view-ului din spate; de acolo poți vedea ce conține și cum se calculează un câmp.
Diferența practică: în loc de un tichet cu „raportul arată greșit”, scrii „câmpul X pare să nu includă comenzile blocate — e intenționat?”. Prima variantă produce trei runde de e-mailuri. A doua se rezolvă în aceeași zi.
Ce câștigi: înțelegi de ce unele rapoarte merg instant și altele durează minute, ceri modificări în termeni pe care echipa tehnică îi prinde din prima, și te descurci mult mai bine cu aplicațiile de căutare a datelor pe cont propriu.
Dacă ești consultant funcțional
Aici e cel mai mare salt. O cerință scrisă fără cunoștințe de CDS sună așa: „vreau un raport cu comenzile pe client”. Una scrisă cu cunoștințe de CDS sună așa: „pornim de la view-ul standard de documente de vânzare, adăugăm legătura către client, filtrăm pe tipurile din lista atașată și grupăm pe client și lună”. A doua se face în ore, nu în săptămâni.
În plus, o parte tot mai mare din ceea ce numim „configurare” a devenit, de fapt, modelare. Iar SAP livrează deja mii de view-uri standard — de cele mai multe ori, informația cerută există deja și nu trebuie construită. Consultantul care poate verifica singur asta economisește timp întregii echipe.
Ce câștigi: scrii cerințe care nu se întorc, estimezi realist efortul, vezi singur ce se poate face din standard și devii persoana care traduce între business și tehnic — cel mai greu rol de înlocuit dintr-un proiect.
Dacă ești analist de date, BI sau controlling
CDS e poarta prin care datele SAP ies curat spre restul lumii. Un view pregătit pentru analiză devine sursă directă pentru instrumentele de raportare, fără să mai construiești un lanț de export și import și fără să aștepți extragerea de peste noapte. În multe cazuri, raportarea se poate face direct pe sistemul de lucru, în timp real.
Ce câștigi: date de azi în loc de date de ieri, o legătură stabilă cu sistemul sursă (view-urile standard supraviețuiesc actualizărilor, tabelele brute nu neapărat) și autonomie — construiești singur analize fără să stai la coadă.
Dacă ești programator ABAP
Direct: în S/4HANA, cine scrie în continuare „ia tot și parcurge în buclă” nu scrie cod vechi, scrie cod care va fi rescris. Modelul oficial de dezvoltare — RAP — pornește obligatoriu de la CDS: definești datele în CDS, comportamentul separat, iar ecranele se generează. Fără CDS nu poți construi o aplicație Fiori modernă și nu poți expune un serviciu ca la carte.
Dincolo de „e obligatoriu”, e și partea plăcută: scrii mult mai puțin cod pentru același rezultat, iar logica devine ceva ce se citește, nu o buclă de 300 de linii pe care nimeni nu vrea să o atingă. Iar competența e foarte căutată — proiectele de migrare la S/4HANA cer exact profilul ăsta.
Ce câștigi: rapoarte de zeci de ori mai rapide, acces la tot stack-ul modern, cod mult mai ușor de întreținut și un profil aliniat cu direcția în care merge tot ecosistemul SAP.
Cât se câștigă, în cifre?
O precizare onestă de la început: nu există un „factor CDS”. Câștigul depinde de ce înlocuiești. Dacă înlocuiești o căutare simplă după un singur document, nu câștigi nimic. Dacă înlocuiești povestea cu cele 12 milioane de rânduri, câștigi de zeci de ori. Cifrele de mai jos sunt ilustrative — arată forma fenomenului, nu un test de laborator.
De unde vine, mai exact, câștigul?
- Baza de date citește doar ce trebuie. HANA ține datele pe coloane. Când ceri suma unei singure coloane dintr-un tabel cu 200 de coloane, restul nici nu se atinge.
- Datele ocupă mult mai puțin. Coloanele cu puține valori distincte — statusuri, coduri de țară, tipuri de document — se comprimă foarte bine, deci încap în memorie și se parcurg rapid.
- Calculul se face pe multe nuclee deodată. O însumare peste 50 de milioane de linii se împarte automat. O buclă într-un program rulează pe un singur fir.
- Nu se stochează nimic pe drum. View-ul e o rețetă; la execuție se combină cu tot ce e construit peste el într-un singur plan optimizat.
- Filtrele coboară singure. Dacă raportul cere doar anul curent, filtrul ajunge până la citirea tabelului. Se citește puțin de la bun început.
Trucul care surprinde pe toată lumea
În exemplul de cod ai văzut niște rânduri care încep cu @. Se numesc adnotări și sunt, practic, etichete lipite pe câmpuri. Nu schimbă datele. Schimbă ce știe restul sistemului despre ele.
Pui eticheta „ăsta e un ban, în moneda din câmpul de alături” și, brusc, sistemul formatează corect și convertește singur. Pui eticheta „ăsta se afișează al doilea în listă” și ecranul se generează cu coloana la locul ei, fără să scrie cineva interfața. Pui eticheta „acesta se poate căuta” și apare căutarea. Aici stă cel mai mare câștig de timp din tot CDS-ul — și motivul pentru care o aplicație Fiori funcțională poate apărea fără o linie de cod de interfață.
| Eticheta spune… | …și sistemul face |
|---|---|
| „e o sumă de bani, în moneda X” | Formatează, aliniază, convertește, adună corect la grupare. |
| „se afișează în listă, pe poziția 2” | Generează coloana în aplicația Fiori, în ordinea cerută. |
| „se poate folosi pentru analiză” | Îl face disponibil în instrumentele de raportare și în Excel. |
| „se publică pentru alte sisteme” | Creează automat interfața prin care alt sistem poate citi datele. |
| „se verifică drepturile de acces” | Aplică regulile de autorizare la fiecare citire. |
| „se ține în memorie” | Păstrează datele aproape, pentru informații citite des și schimbate rar. |
Cine are voie să vadă ce?
Un raport rapid care arată date pe care omul nu are voie să le vadă nu e o optimizare, e un incident. De aceea, în CDS, drepturile de acces se scriu separat de datele propriu-zise: într-un fișier alăturat spui, de exemplu, „acest view se poate citi doar pentru organizațiile de vânzări la care utilizatorul are drept”.
Avantajul e că regula stă lipită de model, nu împrăștiată prin zece programe. Dacă cineva construiește un raport nou peste view, restricția merge automat cu el. Trei reguli practice, pentru cine ajunge să scrie: activează verificarea pe orice view cu date sensibile, dezactiveaz-o doar pentru date de bază nesensibile, și niciodată complet în producție.
Avantajele, pe scurt
- Viteză prin construcție. Calculul se face lângă date. Volumul cărat pe rețea scade, de obicei, de sute sau mii de ori.
- O singură sursă de adevăr. „Ce înseamnă venit net” se scrie o dată. Nu mai ai trei rapoarte cu trei cifre pentru aceeași întrebare.
- Ecrane aproape gratis. Etichetele plus generatorul de interfețe produc aplicații complete cu efort minim de programare.
- Raportare în timp real. Același model servește și analiza, fără un export separat spre alt sistem.
- Extinderi curate. Câmpurile proprii se adaugă alături, fără să modifici obiectele standard — deci actualizările SAP nu te calcă.
- Se citește ca un text. Un consultant poate deschide un view și înțelege regula de business, fără să știe să programeze.
- Se transportă și se versionează. Sunt obiecte normale de dezvoltare: trec prin sistemele de test, se compară, se revizuiesc.
- Nu te leagă de o bază de date anume. Scrii la fel indiferent de tehnologia de dedesubt; pe HANA se execută optim.
Când CDS nu e răspunsul
Un view CDS doar citește; nu poate scrie sau modifica date — pentru asta există alte mecanisme. Nu e potrivit nici pentru prelucrări pas cu pas, cu stare intermediară, nici pentru algoritmi cu repetiții și recursivitate, nici pentru dialogul cu sisteme externe. Și dacă tot ce ai nevoie e un singur rând, căutat după numărul documentului, un strat de abstractizare în plus doar complică lucrurile.
Concluzii
CDS nu e „încă o sintaxă de învățat”. E o schimbare de reflex. Reflexul vechi era: adu-mi datele și mă descurc eu cu ele. Reflexul nou este: spun exact ce vreau, cât mai devreme, și las motorul care stă peste date să găsească drumul.
Din reflexul ăsta ies toate celelalte beneficii. Iar ca să începi nu ai nevoie de un proiect mare.
- Nu ai acces tehnic? Caută în sistemul tău aplicațiile Fiori numite View Browser sau Query Browser și tastează un termen din zona ta — „sales order”, „material”, „vendor”. Vei vedea sute de view-uri standard, cu descrieri în limbaj de business. Deschide unul și uită-te ce conține. Atât. E cea mai bine investită oră.
- Ești consultant? Ia ultima cerință pe care ai scris-o și reformuleaz-o pornind de la un view standard existent, nu de la tabele. Arat-o unui dezvoltator și întreabă-l cât ar dura acum.
- Programezi? Ia cel mai lent raport din sistem, vezi unde își petrece timpul și mută partea de adunare într-un view. Diferența se vede de la primul.
Nimeni nu trebuie să devină expert. Dar într-un sistem în care aproape totul stă pe stratul ăsta, a nu ști deloc ce e dedesubt costă — în timp, în tichete și în discuții care se învârt în cerc.
