English
Romana
O agenție care construiește magazine de piese auto pentru mai mulți clienți, sau un grup care operează mai multe branduri de retail auto, ajunge repede la aceeași întrebare: are sens sÄ‚ plătim o licență TecDoc separată pentru fiecare magazin, sau putem gestiona toate cataloagele dintr-o singură integrare, partajată tehnic? Răspunsul scurt: o arhitectură multi-tenant peste TecDoc este posibilă tehnic, dar impune reguli stricte de izolare a datelor între magazine și, la fel de important, trebuie confirmată explicit la nivel contractual cu furnizorul licenței.
Diferența față de un magazin TecDoc obișnuit nu este în catalogul tehnic în sine — vehiculele, piesele și compatibilitățile rămân aceleași pentru toți clienții — ci în stratul de aplicație care decide cine vede ce, cu ce preț și sub ce brand. Articolul explică arhitectura recomandată, unde apar cele mai frecvente greșeli de izolare și ce trebuie clarificat cu TecAlliance înainte de a lansa mai multe magazine pe aceeași licență.
Ce înseamnă „multi-tenant" pentru un catalog TecDoc
Multi-tenant este un model de arhitectură în care o singură instalare de software deservește mai mulți clienți (tenanți), fiecare cu datele lui separate logic, deși infrastructura tehnică este comună. Aplicat la TecDoc, asta înseamnă:
- Un singur acces API/WSDL către catalogul TecDoc, folosit de toate magazinele găzduite.
- Mai multe magazine (tenanți) — fiecare cu domeniu propriu, brand propriu și, de regulă, catalog de prețuri și stocuri propriu.
- Date tehnice comune — vehicule, KTYPE, coduri articol și compatibilități sunt identice pentru toți tenanții, pentru că vin din același catalog TecDoc.
- Date comerciale separate — preț, stoc, furnizori activi și marjă diferă de la un magazin la altul, chiar dacă piesa TecDoc identificată este aceeași.
Practic, TecDoc rămâne un singur „creier tehnic" partajat, în timp ce fiecare magazin își păstrează propriul strat de business deasupra lui — exact ca la o platformă B2B, unde catalogul tehnic e comun, dar prețul și stocul diferă pe cont.
Cui i se potrivește un model multi-tenant peste TecDoc
Acest model nu este pentru orice magazin de piese auto — are sens în situații specifice:
- Agenții software care construiesc și găzduiesc magazine TecDoc pentru mai mulți clienți distribuitori, fiecare cu propriul brand.
- Grupuri cu mai multe branduri de retail care operează magazine separate pentru segmente diferite de piață (ex: piese premium vs. piese economice), dar cu aceeași infrastructură tehnică în spate.
- Distribuitori cu mai multe piețe/țări care rulează magazine localizate separat, dar interoghează același catalog TecDoc pentru datele tehnice.
Nu are sens pentru un singur magazin cu un singur client final — acolo o integrare TecDoc standard, mai simplă, este suficientă și mai ușor de întreținut.
Arhitectura recomandată: separarea clară între catalog tehnic și date comerciale
Structura care funcționează bine în practică se bazează pe două straturi distincte, cu o graniță tehnică clară între ele:
- Stratul tehnic partajat — un singur serviciu intern (sau modul) care vorbește cu API-ul TecDoc, cache-uiește rezultatele frecvente și le expune uniform către toate magazinele găzduite.
- Stratul de tenant — fiecare magazin are propria bază de date (sau propriul set de tabele, cu `tenant_id` pe fiecare rând) pentru preț, stoc, furnizori, comenzi și conturi de clienți.
- Strat de identificare a tenantului — la fiecare request, platforma determină din domeniu sau subdomeniu care magazin face cererea, înainte de a interoga stratul comercial.
- Combinarea rezultatului — răspunsul final unește datele tehnice din TecDoc cu prețul și stocul specifice tenantului identificat, exact ca la integrarea B2B descrisă separat pentru service-uri auto.
Această separare este ceea ce face diferența dintre o arhitectură multi-tenant solidă și una improvizată, unde codul de preț sau catalogul de furnizori al unui magazin ajunge, din greșeală, amestecat cu al altuia.
Baza de date: un singur schema partajat sau baze separate pe tenant?
Alegerea depinde de numărul de magazine găzduite și de cât de strictă trebuie să fie izolarea:
| Model | Cum funcționează | Când se recomandă |
|---|---|---|
| Schema unic, cu `tenant_id` | Toate magazinele partajează aceleași tabele; fiecare rând are o coloană `tenant_id` obligatorie, filtrată automat la fiecare query | Multe magazine mici-medii, unde simplitatea operațională contează mai mult decât izolarea fizică |
| Baze de date separate pe tenant | Fiecare magazin are propria bază de date; aplicația schimbă conexiunea în funcție de tenantul identificat | Puține magazine mari, cu cerințe stricte de izolare (ex: contracte separate, conformitate, backup independent) |
| Model hibrid | Catalog tehnic TecDoc și cache-ul lui în schema comună; date comerciale sensibile (preț, comenzi, clienți) în baze separate pe tenant | Grupuri cu mai multe branduri, unde datele tehnice pot fi partajate, dar cele comerciale trebuie separate strict |
Modelul cu `tenant_id` pe schema unic este cel mai des folosit pentru agenții care găzduiesc mai multe magazine mici, pentru că simplifică actualizările de cod și mentenanța. Riscul lui principal este uman: un query care omite filtrul `tenant_id` expune date între magazine — de aceea acest filtru trebuie aplicat la nivel de strat de acces la date (query scope global), nu manual în fiecare controller.
Cache-ul catalogului tehnic: partajat între tenanți, dar cu atenție la localizare
Deoarece datele tehnice TecDoc (vehicule, compatibilități, coduri articol) sunt identice pentru toți tenanții, cache-ul acestor date poate și ar trebui să fie partajat — interogarea repetată a aceluiași API pentru fiecare magazin, pentru aceleași date, irosește cote de request și încetinește platforma. Câteva reguli practice:
- Cache-uiește răspunsurile tehnice TecDoc (identificare vehicul, listă articole compatibile) la nivel global, nu per tenant.
- Ține separat, per tenant, doar ce diferă real: limba de afișare, moneda, prețul și disponibilitatea.
- Dacă tenanții operează în piețe/limbi diferite, verifică dacă denumirile TecDoc necesită localizare suplimentară per magazin, peste cache-ul tehnic comun.
- Invalidează cache-ul tehnic la actualizările de catalog TecDoc, nu la fiecare deploy al unui magazin individual — cele două cicluri sunt independente.
Riscuri frecvente la un catalog TecDoc multi-tenant și cum le eviți
Cele mai costisitoare probleme la arhitecturile multi-tenant nu sunt de performanță, ci de izolare a datelor:
- Scurgere de date comerciale între magazine — un preț sau un stoc calculat pentru tenantul greșit, din cauza unui filtru `tenant_id` omis. Mitigare: aplică filtrarea pe tenant la nivel de strat central de acces la date, nu ad-hoc în fiecare loc din cod.
- Configurare TecDoc partajată incorect — dacă un magazin are acces la mărci sau categorii pe care nu ar trebui să le vândă (ex: acord de exclusivitate cu un furnizor), restricția trebuie aplicată explicit în stratul comercial, nu presupusă implicit din catalog.
- Suprasolicitarea licenței/cotei API — mai multe magazine active simultan pot genera mult mai multe interogări decât un singur magazin, apropiindu-se de limitele contractuale ale licenței. Mitigare: cache agresiv pe datele tehnice comune, conform secțiunii anterioare.
- Confuzie de brand în datele afișate — dacă template-urile sau denumirile interne rămân hardcodate pentru un singur magazin, un tenant nou poate afișa accidental elemente vizuale sau texte ale altui brand.
- Facturare și raportare amestecate — fără o separare clară a comenzilor și veniturilor pe tenant, reconcilierea financiară pentru fiecare magazin devine greoaie. Mitigare: `tenant_id` obligatoriu și pe toate tabelele de comenzi și facturare, nu doar pe catalog.
Ce trebuie clarificat cu TecAlliance înainte de a lansa mai multe magazine pe o licență
Partea contractuală contează la fel de mult ca partea tehnică. Termenii de licențiere TecDoc pot varia în funcție de numărul de magazine, de volumul de utilizatori finali și de tipul de expunere a datelor (public vs. autentificat), conform informațiilor publice de pe site-ul TecAlliance. Câteva puncte de verificat explicit, orientativ, înainte de a lansa un model multi-tenant:
- Dacă licența acoperă expunerea catalogului către mai multe magazine/branduri distincte, sau este gândită pentru un singur punct de vânzare.
- Dacă există limite de volum de interogări API care ar putea fi atinse mai rapid cu mai multe magazine active simultan.
- Dacă este permis modelul „white label" — găzduirea catalogului TecDoc pentru clienți terți sub branduri diferite de al integratorului.
- Dacă raportarea de utilizare trebuie făcută agregat sau separat pe fiecare magazin găzduit.
Aceste aspecte țin de termenii contractuali specifici fiecărei licențe și nu pot fi presupuse — se verifică direct cu TecAlliance sau cu reprezentantul licenței înainte de a lansa al doilea magazin pe aceeași integrare.
Plan practic: pașii pentru a construi un catalog TecDoc multi-tenant
Ordinea recomandată pentru o agenție sau un grup care pornește de la o singură integrare TecDoc și vrea să o extindă la mai multe magazine:
- Confirmă termenii licenței pentru găzduirea mai multor magazine, conform secțiunii anterioare.
- Separă explicit stratul tehnic de stratul comercial în codul existent, dacă integrarea actuală le are amestecate.
- Alege modelul de bază de date (schema unic cu `tenant_id`, baze separate sau hibrid), în funcție de numărul și dimensiunea magazinelor planificate.
- Implementează identificarea automată a tenantului din domeniu/subdomeniu, la începutul fiecărui request.
- Aplică filtrarea pe tenant la nivel central (query scope global), nu manual în fiecare controller sau funcție.
- Configurează cache-ul tehnic TecDoc partajat, separat de datele comerciale pe tenant.
- Testează izolarea datelor cu minimum două magazine de test, verificând explicit că prețul, stocul și comenzile unuia nu apar niciodată la celălalt.
- Lansează un al doilea magazin real abia după ce testele de izolare trec constant, nu doar în cazurile fericite.
Multi-tenant vs. integrări separate pentru fiecare magazin: când merită fiecare variantă
Nu orice grup de magazine trebuie forțat într-o arhitectură multi-tenant. O comparație directă ajută la decizie:
| Criteriu | Multi-tenant (o singură integrare) | Integrări separate per magazin |
|---|---|---|
| Cost de mentenanță | Mai mic — un singur cod de bază, actualizat o dată pentru toate magazinele | Mai mare — fiecare integrare se actualizează și se testează separat |
| Izolare a datelor | Necesită disciplină tehnică strictă (filtrare pe tenant peste tot) | Izolare naturală, fiecare magazin are propriul mediu complet separat |
| Viteză de lansare a unui magazin nou | Rapidă, odată ce arhitectura e pusă la punct | Mai lentă — fiecare magazin nou repetă integrarea de la zero |
| Potrivire | Agenții, grupuri cu multe branduri similare tehnic | Clienți cu cerințe foarte diferite de business logic sau conformitate |
Întrebări frecvente despre TecDoc multi-tenant
O singură licență TecDoc poate deservi tehnic mai multe magazine simultan?
Tehnic, da — API-ul TecDoc poate fi interogat dintr-o singură integrare și rezultatele redistribuite către mai multe magazine. Dacă acest lucru este și permis contractual depinde de termenii licenței specifice, care trebuie confirmați direct cu TecAlliance sau cu furnizorul licenței.
Este nevoie de baze de date separate pentru fiecare magazin?
Nu obligatoriu. Un schema unic cu coloană `tenant_id` pe fiecare tabel relevant funcționează bine pentru multe magazine mici-medii, atât timp cât filtrarea pe tenant este aplicată consecvent la nivel central. Baze de date complet separate se justifică pentru magazine mari sau cu cerințe stricte de izolare.
Cum eviți ca prețul unui magazin să apară din greșeală la altul?
Prin aplicarea filtrului de tenant la nivel de strat central de acces la date (ex: query scope global în framework), nu manual, în fiecare loc din cod unde se citește sau se scrie preț. Testele de izolare, cu conturi din tenanți diferiți, trebuie rulate explicit înainte de fiecare lansare majoră.
Se poate face model „white label" cu TecDoc, pentru clienți terți?
Depinde de termenii licenței TecDoc deținute. Găzduirea catalogului sub branduri diferite de al integratorului principal (white label) nu este implicit permisă de orice tip de licență — se verifică explicit acest scenariu cu TecAlliance înainte de a-l oferi ca serviciu clienților.
Ce se întâmplă cu volumul de interogări API când adaugi magazine noi?
Volumul crește proporțional cu numărul de magazine active, dacă fiecare interoghează separat catalogul tehnic. Un cache tehnic partajat între tenanți (vezi secțiunea dedicată) reduce semnificativ acest volum, pentru că datele de vehicule și compatibilități sunt identice pentru toți tenanții și nu trebuie cerute de mai multe ori.
Concluzie
Un catalog TecDoc multi-tenant este o soluție eficientă pentru agenții și grupuri care operează mai multe magazine auto, dar depinde de o separare disciplinată între stratul tehnic partajat (catalogul TecDoc în sine) și stratul comercial izolat pe fiecare magazin (preț, stoc, comenzi, clienți). Reușita nu vine din alegerea unei tehnologii anume, ci din testarea riguroasă a izolării datelor între tenanți și din confirmarea explicită, la TecAlliance, că licența deținută acoperă acest model de utilizare.
Construiești sau extinzi o platformă care găzduiește mai multe magazine de piese auto pe aceeași integrare TecDoc? Contactează-ne pentru o consultație despre arhitectura multi-tenant potrivită situației tale.
Write a comment