Külső adatbázisok elérése és egyedi raktárkészletek kezelése Magento-ban

A mai világban már nemcsak a webáruház tartja nyilván a cégek forgalmi adatait, külön rendszereket üzemeltetünk a készlet-, a termék-, a felhasználó- és a vállalatkezelésre. Ezen alkalmazások adatbázisokban tárolják a releváns adatokat, melyeknek szinkronban kell lenniük az egyes alkalmazások között. Az FMCG típusú webáruházak esetén kiemelten fontos a gyors, akár azonnali szinkronizáció több alkalmazás esetén. Ezen integrációkra keresünk megoldásokat és adunk ötleteket cikkünkben.

Mi is az az FMCG?

Rövid defíníció:

Fast-moving consumer goods vagy consumer packaged goods (CPG), azaz gyorsan forgó fogyasztási cikkek. Azokat az árucikkeket értjük ez alatt, amelyek viszonylag gyakran, napi, heti vagy havi rendszerességgel újra megvásárlásra kerülnek és viszonylag alacsony árúak. 

Ide tartozik például a borotva, papír zsebkendő vagy kisbabások esetén a nedves törlőkendő és a pelenka, de lehet szó a kötszerekről vagy a ragtapaszról is.

Adatbázisok

Az adatbázisokat két nagy csoportba érdemes bontani, a logikai és a fizikai adatbázisokra. A logikai adatbázisokat felépítésük, működésük és sajátosságaik alapján szokás megkülönböztetni a fizikai adatbázisoktól. Adatmodellekkel reprezentáljuk őket és a korszerű adatbázisoknál a fizikai adatbázist több logikai adatbázison keresztül is elérhetjük, mintha egyfajta burkoló rétegeket képeznének a tárolt adatok elé.

A Magento adatmodelljei (model) és gyűjteményei (collection) pontosan egy ilyen logikai adatbázist képeznek le a fizikai adatbázis elé, hogy megkönnyítsék és érthetőbbé tegyék az adatok feldolgozását.

Fogalmi, logikai és fizikai modell összefüggése

Fogalmi, logikai és fizikai modell összefüggése

Adatbázisok és Magento

A webáruházak és manapság minden alkalmazás egyik legfontosabb része az adatbázis, melyek üzemeltetése, karbantartása és fejlesztése hatalmas összegekbe kerül. Az adatbázisok lehetnek elosztottak is, mivel a Magento webshop logikai adatbázisa beburkolja a kapcsolatot, így csökkenthetjük a költségeinket és a megfelelő adatokat a megfelelő helyeken kezelhetjük.

A Magento emellett képes egyszerre több különböző adatbázist is kezelni, melyekhez a PDO-t használja, így Cubrid, FreeTDS / Microsoft SQL Server / Sybase, Firebird, IBM DB2, IBM Informix Dynamic Server, MySQL 3.x/4.x/5.x, Oracle Call Interface, ODBC v3 (IBM DB2, unixODBC és win32 ODBC), PostgreSQL, SQLite 3 és SQLite 2, Microsoft SQL Server / SQL Azure, 4D alapú kapcsolatokat könnyedén kiépíthetünk benne.

Többszörös adatbázis-kezelés

Ahhoz, hogy egyszerre több adatbázist is kezelni tudjon a Magento webáruházunk, csupán elegendő a modulunk config.xml konfigurációs állományba felvenni az új adatbázis elérhetőségének paramétereit (host, username, password, dbname), valamint a connection > use-ban meghatározni a kapcsolat azonosítóját.

Ezzel a kapcsolatnak már nincs szoftveres akadálya, ha a hálózaton keresztül a host elérhető, akkor a kapcsolat létrejön. A fejlesztőknek ezután már csak a logikai adatbázist (model, collection) kell létrehoznia, hogy az adatok áramlása zökkenőmentes legyen

Adatbázisok: Állomány alapú források

A tapasztalatok azt mutatják, hogy a legtöbb esetben egyszerű (csv) vagy összetett (xml, json) forrás állományok állnak a felhasználók birtokában. Ezek az állományok tartalmazzák a teljes termékkínálatot, a felhasználói adatokat vagy akár a rendeléseket is. A Magento is lehetőséget biztosít ezen adatok exportálására, egészen könnyedén az adminisztrációs felületről.

Külső adatbázis skálázhatóság
Külső adatbázisok skálázhatósága

 

Előnyei

  • Könnyen kezelhetőek
  • Könnyen módosíthatóak
  • Az ember számára viszonylag könnyen olvasható formátum
  • Exportálási lehetőség elérhető, nem indokol fejlesztést

Hátrányai

  • Szerkesztéskor nagy a hibalehetőség, amivel a teljes állomány szerkezete felbomolhat
  • Rekordok szerkesztése nehézkes
  • Az állományok kódlapjának beállítása adattorzulást okozhat
  • Importálásnál a teljes adatmennyiséget feldolgozzuk
  • Nem frissül automatikusan

Adatbázis-kezelő rendszerek

Az állomány alapú forrásokhoz képest itt annyi a különbség, hogy egy adatbázis-kezelő rendszeren keresztül érjük el adatainkat. Az adatbázis-kezelő áthidalja az állományok kezelése okozta hátrányokat, hiszen jól értelmezhető logikai adatmodelleket kínál erre. A fizikai adatfüggetlenség biztosítására az adatbázis-kezelő motortól független állományszervezési rendszereket dolgoztak ki, hogy a háttértár szervezése illetve eszköz függetlensége biztosítva legyen.

Az adatmodellek alapján megkülönböztethetünk relációs, objektumorientált, hálós, deduktív, objektumrelációs, deduktív relációs, deduktív objektumorientált adatbázis-kezelőket.

Háttértár szervezések

  • Optikai
  • Lyukszalagos
  • Mágnesszalagos
  • Merevlemezes
  • Memória-adatbázis

Előnyei

  • Felhasználói felület az adatokhoz
  • SQL általános nyelvből alakultak ki a lekérdező nyelvek
  • Funkcionalitás bővíthető
  • Elosztott rendszerek megvalósíthatóak

Hátrányai

  • Bonyolultak: Logikai, halmazkezelési ismeretek szükségesek
  • Lekérdező nyelvet ismerni kell
  • Nő az adattároláshoz és az adatbázis kezelőhöz szükséges tárterület szükséglet.

 

Adatbázisok: Szolgáltatás alapú források

A szolgáltatás alapú források alá tartoznak azok az adatbázis elérések, melyeket egy interfészen keresztül érhetünk el egy másik szerveren, mely akár a világ másik felén is lehet. Még a mai napig is leginkább SOAP protokollon keresztül vagy a fejlesztéseknek hála, valamilyen REST szolgáltatáson keresztül tudjuk az adatokat elérni és manipulálni.

A SOAP interfészen keresztül történő elérés legnagyobb hátránya, hogy az interfész bonyolult és részletes, szemben a REST interfésszel, mely sokkal egyszerűbb és kényelmesebb. A biztonság szempontjából a SOAP kliens volt korábban a megbízhatóbb, azonban az SSL kapcsolatokkal és egyéb titkosítási algoritmusokkal most már azonos megbízhatósági szintre került a két interfész.

A mobil alkalmazások fejlődési iránya azt mutatja, hogy szolgáltatás alapon érik el a távoli adatbázisokat, leginkább REST kliensként, mivel az adatbázisok méretei miatt ezek készüléken elhelyezése és feldolgozása hardver- és szoftverteljesítmény szempontjából sem lenne ideális.

 

Előnyei

  • Teljesítmény: Kisebb teljesítmény is elegendő az alkalmazás futtatásához
  • A REST alapú szolgáltatások interfésze egyszerű (HTTP kérések), jól érthető és kicsi erőforrásigényű a JSON alapú formátum könnyen kezelhető, akár már frontend szinten is.
  • A SOAP protokoll dokumentáltsága és hibajelzése kiforrottabb
  • Az általános biztonság SSL tanúsítványokkal megvásárolható

 

Hátrányai

  • A SOAP alapú szolgáltatások interfésze összetett, bonyolult, a fejlesztések drágák és az XML formátum miatt nehézkes a feldolgozása
  • A hálózati kommunikáció bizonytalanságai miatt lassú, elérhetetlen lehet
  • A hálózati kommunikáció miatt a biztonság nem 100%-os, további titkosítási algoritmusokra lehet szükség

REST VS SOAP

 

Adatbázisok: Külső alkalmazás források

A vállalatirányítási rendszerek adatbázisai nem különülnek el a külső adatbázisoktól, azonban mégis összetettebbek, nagyobbak (méret) lehetnek, mint más célirányosan összerakott adatbázisok. Mivel ezek az adatbázisok vállalatirányítási feladatokat látnak el, így folyamatosan frissülnek, változnak és bővülnek. Éppen ezért összetett interfészekkel rendelkeznek a külső rendszerek számára, melyek integrációja a közepestől a nagy bonyolultságú feladatig terjedhet.

Szerencsére a legtöbb ERP, CRM és PIM rendszer rendelkezik olyan modullal mely telepítése és minimális konfigurációja révén biztosítja a webáruházunkkal történő összekötést. Nagyon fontos, hogy ezen rendszerek között ajánlott az azonnali, kétirányú kommunikáció kialakítása, hogy a lehető legkevesebb emberi erőforrást kelljen az adminisztrációs munkára fordítani.

 

Előnyei

  • A kommunikáció lehet teljesen automatizált, így az adminisztrációs feladatok jelentősen csökkennek
  • Egy rendszert elegendő megtanulni kezelni és figyelni
  • A legismertebb rendszerekhez történő integráció gyors és zökkenőmentes
  • Fejlett felhasználói interfésszel rendelkeznek
  • Több protokollon vagy interfészen keresztül is képesek kommunikálni

Hátrányai

  • A rendszerek közötti kommunikáció keresztmetszete
  • A rendszerek közötti kommunikáció hiánya esetén adatvesztés
  • Kétirányú kapcsolat és/vagy aszinkronitás nélkül túl nagy emberi erőforrásra van szükség

 

Termék- és készletváltozások

Az FMCG esetén kritikus tényező a termék- és készletváltozások azonnali, legalább naprakész frissítése. Hiszen, ha egy új termék érkezik az áruházba, annak nem biztos, hogy fontos azonnal eladhatónak lennie a webáruházban, de ha elfogy egy termék készlete, akkor azt azonnal jelezni kell a vásárló felé vagy leadni a rendelést a beszállító, raktár vagy gyártó felé.

Ez a szinkronizáció ideális esetben kétirányú, azaz mindkét oldal képes jelezni a másik oldalnak, hogy az adatok megváltoztak és automatikusan az üzleti logikának megfelelően frissíteni az adatbázisokat. Ez még két rendszer esetén is bonyolult fejlesztést igényel mind a webáruház, mind az adatbáziskezelő alkalmazás részén, de vannak olyan esetek is, amikor egy ERP, egy PIM és több webáruház összekötése a feladat.

Mit lehet ilyenkor tenni?

Első és talán legfontosabb kérdés, hogy mekkora adatmennyiségeket szeretnénk mozgatni? A teljes termékkészletet, termékeket, megrendeléseket és vevői információkat frissíteni akarjuk? Elegendő időszakosan, várólistás (queue) megoldással az adott időszakban éppen aktuális változásokat frissíteni? Azonnal frissíteni kell minden változást a rendszerek adatbázisai között?

A fenti kérdések mind-mind kulcsfontosságúak, hogy meghatározzuk, milyen szintű integrációra van szükség. Egy sekély integrációnál lehet, hogy elegendő egy napi csv/xml állomány alapú importálás a külső rendszerből a webáruházba, akár ezt automatizálva futtatni. Közepes szintű bonyolultság a várakozó listás megoldás, ahol egyik vagy másik oldal is egy sor-szervert használ a frissítésre. A mély integrációnál pedig már akár köztes rétegben történik az adatok szinkronizációja.

Az alább felsoroljuk a különbségeket az egyes módszerek között, röviden ismertetve, hogy melyik mivel járhat és mennyire komplex a fejlesztési listában.

1.1. Teljes adatok cseréje

Az adat mennyiségek mozgatása és frissítése szempontjából a teljes adatok cseréje az úgynevezett fapados megoldás. A termékek, megrendelések mennyisége fontos szempont ebben az esetben, mivel több tízezer termék esetén az ilyen frissítés már akár percekig is eltarthat, ami kiesést vagy termék elérhetetlenséget jelenthet a webáruházban. Éppen emiatt csak abban az esetben javasoljuk ezt a megoldást, ha a termékek vagy készlet információk frissítése viszonylag rövid ideig tart vagy jól időzíthetően az áruház forgalmához az esetlegesen elhúzódó frissítés.

 

1.2. Részleges adatok csere

A részlegesadat-kommunikáció akkor jöhet szóba, ha többször az áruház működése alatt is frissíteni kell a termék-, készlet- vagy rendelési információkat. Az időzített megoldások mellett, melyek pontatlansága okozhat problémát az azonnali szinkronizáció is szóba jöhet, mivel a kisebb mennyiségű adatkommunikáció gyorsan végrehajtódik a rendszerben.

A készletkezelés és az FMCG típusú áruházak integrációs megoldásai pontosan ide tartoznak, mivel nem a teljes termék, csupán a darabszámok változnak.

 

2.1. Adatok áttöltésének iránya: egyirányú, kétirányú

Viszonylag egyszerű kérdés, azonban ha jobban átgondoljunk, további kérdéseket vet fel, ráadásul az integrációs költségek növekedése mellett az adatkommunikáció mennyiségét is jelentősen növelheti.

Egyirányú adatkommunikációról akkor beszélünk, ha van egy kiválasztott (master) rendszer – mondjuk egy ERP –, amelybe minden másik külső rendszer, azaz például a webáruházunk is beküldi az adatokat. A fő rendszer (ERP) pedig feldolgozza és tárolja őket, az ERP-t használó adminisztrátorok pedig a kapott adatok alapján irányítják a vállalati folyamatokat.

Kétirányú kommunikáció esetén mindkét rendszer kommunikál a másikkal és egymástól függően vagy függetlenül megadott interfészeken keresztül küldik el az adatokat. Itt már nincs alá- és fölérendelt szerep, csupán a prioritásokat kell megfelelően meghatározni vagy sorszerverekkel vezényelni a változások kezelését.

 

3.1. Adatok közvetett áttöltése

Az adatok áttöltését lehet közvetetten (manuális vagy ütemezett módon) vagy közvetlen (API interfészeken keresztül) frissítéssel megoldani. Az időszakos áttöltésnél szóba jöhet az emberi beavatkozás, aki az egyik rendszerből átemeli az adatokat a másik rendszerbe.

Ez történhet egyszerű export-import folyamatként, ahol az adatok egy állományba kerülnek mentésre (export), majd ezt az állományt a másik rendszer erre kialakított interfészén keresztül betölti az adatbázisba (import). Ez a folyamat természetesen automatizálható, ha az adott alkalmazás által kimentett adatokat a másik rendszer meghatározott időközönként (pl. cronjob) automatikusan betölti az adatbázisába.

Láthatjuk, hogy ez a módszer még az emberi tényező kivonása mellett is lassú, pontatlan és emiatt nem eredményes az FMCG szempontjából, azonban más esetekben, ahogy tapasztaltuk, elegendő lehet.

 

3.2. Közvetlen információcsere

Az adatok közvetett áttöltése nem éppen a legjobb megoldás a raktárkészletek kezelésére, hiszen a termékek darabszámának változását érdemes minél pontosabban szinkronizálni, így a közvetlen információcsere lehet a kézenfekvő megoldás. Ahhoz, hogy ez megvalósuljon, sokféle technológia áll a rendelkezésünkre, a Magento beépített XmlConnect, API (SOAP vagy REST) megoldásai mellett a legtöbb külső alkalmazáshoz már kész modulokat vásárolhatunk a Magento Connect-ből.

Kétségkívül az egyik legjobb megoldás, hiszen az adatok szinkronizálása azonnal, a változások bekövetkezésekor megindul, azonban, ha speciális külső alkalmazásunk van, melyhez még nincs konnektor (Magento modul), akkor az integrációs költségek jelentősen megugranak. Ne feledjük el, hogy az automatikus, azonnali megoldásokhoz az esetek nagyobb hányadában mélyintegrációra van szükség, mely a korábban leírtak szerint mind időben, mind fejlesztési költségekben nagy.

 

3.3. Automatikus vagy kézi szinkronizáció

Az előzőekben már szóba került, hogy emberi erőforrásokkal is megoldható az adatok szinkronizálása az alkalmazásaink között és ennek automatizálása is megoldható, azonban ezek az időszakos adatkommunikációk meglehetősen megnehezítik a készletek szinkronizációját. Automatikus szinkronizáció alatt itt azt az időzített feladatot értjük (pl.: cronjob), amikor a folyamatot a rendszer indítja, de helyette akár egy ember is meg tudja oldani. Ezek a jelentősen olcsóbb megoldások.

 

3.4. Aszinkron, azonnali megoldások

Az aszinkron megoldásokkal jelentősen gördülékenyebbé tehetjük a készlet- és adatszinkronizációt az alkalmazásaink között. A végtelenségig azonban még így sem lehet egyszerűsíteni a folyamatokat, hiszen az üzleti igények kötött függőségei miatt az aszinkronitás csak bizonyos feladatok vagy részfolyamatok esetén vezethet hasznos eredményre. Az azonnali adatkommunikáció pedig pontosan ugyanezen függőségek miatt nem valósítható meg 100%-osan.

A legjobb, legtisztább és egyben a legbonyolultabb megoldások közé tartozik, jelentős fejlesztési idővel és költségekkel, így ezt csak akkor érdemes választanunk, ha valóban indokolt a webáruházaink esetén.

Köztes réteg: Middleware, MOM

A köztes réteg (middleware), mint megoldás a készlet- és adatkommunikáció szinkronizációja az egyik leginkább fejlődő és jelenleg a legmodernebb technológiai megoldás, mind hardver, mind szoftver téren. Egy olyan megoldásról (szoftver és hardver) beszélünk, mely az alkalmazásaink közé ékelődve külső beavatkozás nélkül, az előre meghatározott üzleti logika alapján megvalósítja az adatkommunikációt.

Middleware

 

Tulajdonképpen egy félig intelligens rendszer, melyen keresztül az adatok áramlanak és eljutnak egyik alkalmazásunkból a másikba, attól függően, hogy éppen mely üzleti folyamat, mely részén tartanak.

Tekinthetünk úgy rá, mint egy hatalmas labirintusra, melynek egyes ki- és bejáratainál az alkalmazásaink találhatóak és az adatok a labirintuson keresztül jutnak el a másik alkalmazás kapujához, hogy közben a falakon lévő szabályokat követik. Az áthaladás közben az adatok átalakulnak a kívánt formátumba és a fogadó félnek megfelelő adatstruktúrát veszik fel, így nincs szükség alkalmazásainkban az adatok transzformálására.

Ezek a köztes szoftverek külön szerverekből állnak, olyan kiegészítő technológiákkal, mint az Üzenetorientált köztesréteg (Message Oriented Middleware), Redis memória alapú gyorsítótár és egyéb szoftveres és hardveres megoldások a köztes réteg támogatására. A köztes rétegek ma már a felhőben helyezkednek el, memória-alapú szervereken, melyek API interfészei a legtöbb webáruházhoz illeszkednek. A piacon már elérhetőek kész megoldások, melyekkel könnyedén integrálhatjuk rendszereinket és összehangolhatjuk a folyamatainkat az egyes rendszerekben.

Ezek a megoldások az általános üzleti folyamatokra épülnek, és többé-kevésbé személyre szabhatóak, azaz jól illeszkednek az általános, nem speciális üzleti igényeket kiszolgáló webáruházakhoz. Vegyük azonban figyelembe, hogy ha az üzleti folyamataink speciálisak és eltérnek az adott alkalmazás általános üzleti folyamataitól, akkor az integráció is egyedileg, személyre szabottan fog ideálisan működni.

 

KONKLÚZIÓ

Az FMCG kezelésére rengeteg megoldás létezik és ezekből a számunkra megfelelő megoldásokat kiválasztva egy olyan optimális rendszert építhetünk fel, mely kiszolgálja Magento webáruházunkat. A döntés szempontjából fontos kritériumokat a fentiek alapján meg tudjuk határozni, így ki tudjuk választani a kézenfekvő megoldást.

Ne feledjük el azonban, hogy a hosszú távú célok és az adott piaci szegmens ismerete nélkül, ha a legegyszerűbb és (nem biztos, hogy) a legolcsóbb megoldás választjuk, könnyen megeshet, hogy az integrációs költségeket többször is meg kell majd fizetnünk.

Forrás

Az eredeti cikkem az Aionhill oldalán jelent meg 2016-ban, forrás: 
https://aionhill.com/kulso-adatbazisok-raktarkeszletek-magento-ban