Magento 2 modul fejlesztés lépésről lépésre – 1. rész

A Magento jelenleg a világ egyik vezető webáruház motorja, melyet világszerte rengeteg kis- és középvállalkozás mellett megannyi nagy cég is elégedetten használ. Ennek oka a rendkívül gazdag funkcionalitás, mely a gyári funkciók mellett az egyedi, fejlesztői megoldásoknak is köszönhető.

A Magento ugyanis nyílt forráskóddal rendelkező szoftver, ami azt jelenti, hogy szabadon használható, másolható, terjeszthető, tanulmányozható és módosítható. Community edition verziója ráadásul ingyenesen elérhető. Így nem csak bárki szabadon használhatja, de aktív fejlesztői közösség is épül köré. Ilyen módon a rendszerrel kapcsolatos kérdésekre, problémákra bármikor könnyen választ kaphatunk.

Sőt, a jó tanácsok mellett Magento alapú rendszerünk rengeteg különleges modullal, hasznos funkcióval is bővíthető, melyek könnyebbé teszik a munkát és javítják a felhasználói élményt. Ezek a kiegészítők igen széles skálán mozognak és elérhetők a Magento Marketplace piactérről

De annak érdekében, hogy oldalunk tökéletesen működjünk, mi magunk is fejleszthetünk felhasználói modulokat. Ehhez természetesen azonban programozói előképzettség mellett szükségünk lesz bizonyos ismeretekre, melyeket egy többrészes cikksorozatban fogunk részletesen bemutatni.

Ebben a cikkben a következő témákat fogjuk feldolgozni:

  1. Követelmények, dokumentumok és Magento 2.0 installálás
  2. Célszerű IDE beállítások a fejlesztés megkezdése előtt
  3. Alap modul felépítése és elkészítése
  4. Modul admin konfiguráció és jogosultság kezelés
  5. Alap frontend controller, block, layout és template
  6. Modulhoz tartozó adatbázis tábla elkészítése
  7. Modulhoz tartozó adatbázis tábla elkészítése
  8. Modulhoz tartozó modellek és collection létrehozása
  9. Tábla feltöltése adatokkal, script segítségével
  10. Tábla update script és verzió növelés
  11. Adatok megjelenítése frontend-en

1) Követelmények, dokumentumok és Magento 2.0 installálás

A Magento telepítése már önmagában véve olyan feladat, mely igényel némi hozzáértést. Figyelnünk kell arra, hogy minden rendben menjen, különben a munka nagy eséllyel leet hiányos vagy sikertelen. Arra az esetre, ha valami nem a terv szerint történne, érdemes minden fontos adatról biztonsági mentést készítenünk, mielőtt belefognánk a munkába.

Ahhoz, hogy a Magento 2.0 rendszert telepíteni tudjuk, először is kell végeznünk a fejlesztői környezetünk minimális beállításait, mellyel kapcsolatban részletes információt ezzel kapcsolatban ezen a linken olvashatunk: http://devdocs.magento.com/guides/v2.0/install-gde/bk-install-guide.html

Itt az alapvető követelmények jól láthatók, a telepítéshez a következőkre mindenképp szükségünk lesz:

  • PHP 7.1 és ennél nagyobb verziók
  • MySQL 5.6.x és ennél nagyobb verziók
  • Ajánlott legalább 2 GB fizikai memória

Amennyiben nem rendelkezünk ezekkel, a telepítés megkezdése előtt frissíteni kell lokális fejlesztői környezetünket.

A Magento 2.0 rendszer telepítésével kapcsolatban a legfőbb fájlok az alábbi két linken érhetők el: http://devdocs.magento.com/
https://github.com/magento/magento2

Az installálás során három módszert is tudunk alkalmazni.

  1. Az első esetben egyszerűen letöltjük a Magento hivatalos oldalról a két elérhető verziót. Az egyik csak az alap rendszert tartalmazza, míg a másik példa adatokkal is ellátja az installálás során a rendszert (Sample Data). A két csomag itt érhető el: https://www.magentocommerce.com/download
  2. Második telepítési lehetőség, amikor a Github-ról klónozzuk a Magento rendszert. Ennek előnye, hogy folyamatosan frissíteni tudjuk a Git segítségével a fejlesztőkörnyezetünkben. Fontos itt megjegyezni, hogy a Git klónozás során a develop branch-et kapjuk meg, így ahogy a klónozás befejeződött, célszerű átváltani (git checkout) a 2.0 vagy a merchant_beta branch-ekre. A Magento 2.0 Github elérés: https://github.com/magento/magento2
  3. A harmadik lehetőség a Metapackage installáció. Ebben az esetben a letöltött package után a composer segítségével kell installálnunk a Magento 2.0 rendszert, vagyis az alap Magento modulokat a hivatalos Magento Repo-ból kapjuk, az egyéb összetevőket más repo-ból. Metapackage installálási útmutató: magento integrator install

Ha sikerült telepítenünk a keretrendszert, akad néhány beállítás, melyet nem csak érdemes, de szükségszerű is lehet elvégezni. Ezután láthatunk majd neki az első alapmodulunk felépítésének.

2) Célszerű IDE beállítások a fejlesztés megkezdése előtt

Az IDE nem más, mint az integrált fejlesztői környezet (Integrated Development Environment), melynek alapvető szerepe van a gyors alkalmazásfejlesztésben. Az IDE-k általában egy, a a program forráskódjának szerkesztésére alkalmas szövegszerkesztőt, egy fordítóprogramot vagy értelmezőt, fordításautomatizálási eszközöket, valamint nyomkövetési, grafikusfelület-szerkesztési és verziókezelési lehetőségeket is tartalmaznak.

Miután sikeresen installáltuk a Magento 2.0 rendszert fejlesztőkörnyezetünkbe és az megfelelőn működik, célszerű beállítani a fejlesztéshez használt IDE-t, ami e cikk esetében a Jetbrains PhpStorm-ra vonatkozik.

A Magento 2.0 működése és fejlesztése során az alábbi technológiaákat alkalmazza: devdocs magento tech stack.

Első lépésben a projekt megnyitása után a PhpStorm-ban célszerű lefuttatni a Detect PSR-0 Namspace Roots parancsot, ami a menüből elérhető, de egyébként az IDE ezt automatikusan fel fogja ajánlani.

Következő lépés a megfelelő PHP CodeSniffer beállítása. Alapból az IDE a PSR-1 és PSR-2 coding standard-ot támogatja, így itt célszerű a PSR-2-őt választani, de ajánlottabb a PSR-4 alkalmazása (azonban ez alapból nincs a PhpStorm-ban). Az IDE-ben ezen beállítások elvégzésére a cikk nem tér ki. Amennyiben megnyitunk a vendor/magento könyvtárban lévő bármely modulhoz tartozó etc/module.xml fájlt (vagy egyéb itt található xml fájlt), láthatjuk, hogy az URN feloldás jelenleg sikertelen. A Magento 2.0 számos fejlesztői parancsot tartogat számunkra, ami a fejlesztés során segítségünkre lehet. Ezen parancsok listáját így tekintethetjük meg:

  • belépünk a bin könyvtárba a terminálunkban
  • kiadjuk a „php magento” parancsot
  • ennek eredményeképpen kilistázódik az összes lehetséges parancs, amit a fejlesztés során használhatunk és igen hasznos

Visszatérve az URN feloldási problémára, ezt az alábbi paranccsal tudjunk megoldani: php bin/magento dev:urn-catalog:generate .idea/misc.xml (látható, hogy ezt nem a bin könyvtárból futtatjuk, hanem root könyvtárból) A fejlesztés megkezdése előtt kikapcsoljuk a teljes cache-t (admin felületről, vagy fent említett php magento parancsok segítségével). Amennyiben Apache szerver alatt fejlesztünk, a root könyvtárban található .htaccess fájlban beállítjuk a developer módot: SetEnv MAGE_MODE developer Célszerű a fejlesztői környezetünkben az xdebug-ot kikapcsolni (php.ini beállítás), mert ez jelentősen lassítja a rendszert.

3) Alap modul felépítése és elkészítése

Amint installáltuk a Magento 2.0-át (és nem Github-ról klónoztuk), szembesülünk azzal, hogy a jól megszokott app/code könyvtár hiányzik és minden alap Magento modul a vendor/magento könyvtárban van elhelyezve. Ettől nem kell megijedni, a fejlesztés első lépése, hogy létrehozzuk az app/code könyvtárat. Miután ez elkészült, létrehozzuk a modulunk alap könyvtárát (Vendor/Module). Ez a mi esetünkben az Aion/Test könyvtár lesz. Következő lépésben két könyvtárat hozunk létre:

  • app/code/Aion/Test/etc
  • app/code/Aion/Test/Helper

A modul alap definíciós fájlja az app/code/Aion/Test/etc könyvtárba kerül elhelyezésre, melynek neve module.xml.

<?xml version="1.0"?>
<!--
/**
 * Copyright © 2015 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
-->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
    <module name="Aion_Test" setup_version="2.0.0">
        <sequence>
            <module name="Magento_Store"/>
        </sequence>
    </module>
</config>

A fájlban definiáljuk a modul nevét (Vendor_Module -> Aion_Test), a verzió számát, ami jelen esetben 2.0.0 és a függőségeket, ami jelenleg csak az alap Magento_Store modul. A következő lépésben létrehozzuk a Helper fájlt. Az alap helper fájl az app/code/Aion/Test/Helper/Data.php lesz. Nézzük a tartalmát:

<?php
/**
 * Copyright © 2015 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
namespace Aion\Test\Helper;

/**
 * Aion Test helper
 */
class Data extends \Magento\Framework\App\Helper\AbstractHelper
{
    /**
     * Path to store config if extension is enabled
     *
     * @var string
     */
    const XML_PATH_ENABLED = 'aion/basic/enabled';

    /**
     * Check if extension enabled
     *
     * @return string|null
     */
    public function isEnabled()
    {
        return $this->scopeConfig->isSetFlag(
            self::XML_PATH_ENABLED,
            \Magento\Store\Model\ScopeInterface::SCOPE_STORE
        );
    }
}

A helper fájlt elég üresen is létrehozni, de mi már egy alap függvényt implementáltunk (public function is Enabled()) és egy konstanst. A konstansban meghatározott string (útvonal) később a modulhoz tartozó admin konfigurációs fájlban fog értelmet kapni (system.xml). Következő lépésben elhelyezzük a modul könyvtárba (app/code/Aion/Test) a registration.php fájlt, ami a modul felismerését hivatott elvégezni a Magento 2.0 rendszerben. Nézzük ennek tartalmát:

<?php
/**
 * Copyright © 2015 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */

\Magento\Framework\Component\ComponentRegistrar::register(
    \Magento\Framework\Component\ComponentRegistrar::MODULE,
    'Aion_Test',
    __DIR__
); 

A file tartalmát bármelyik alap Magento 2.0 modulból átmásolhatjuk, a lényeg, hogy a második paraméternél a saját modulunk szerepeljen (Vendor_Modul -> Aion_Test). Mivel az alap Magento 2.0 modulok is composer-t használnak a frissítésre, mi is elkészítjük saját composer.json fájlunkat. Ennek tartalma így néz ki:

{
    "name": "aion/module-test",
    "description": "N/A",
    "require": {
        "php": "~5.5.0|~5.6.0|~7.0.0",
        "magento/module-config": "100.0.*",
        "magento/module-store": "100.0.*",
        "magento/module-backend": "100.0.*",
        "magento/framework": "100.0.*"
    },
    "type": "magento2-module",
    "version": "100.0.2",
    "license": [
        "OSL-3.0",
        "AFL-3.0"
    ],
    "autoload": {
        "files": [
            "registration.php"
        ],
        "psr-4": {
            "Aion\Test\": ""
        }
    }
}

A composer.json tartalmazza modulunk alap információt, függőségeket, licenc, verzió stb. adatokat. Már szinte el is készültünk, de még két fájl hiányzik egy szépen felépített modulhoz.

Ez a két fájl, mely szintén a modulunk könyvtárában (app/code/Aion/Test) kap helyet: README.md és COPYING.txt. Az előbbi a Git leírás, míg az utóbbi a licenc információkat tartalmazza, ami jelen esetben OSL 3.0. Tehát így néz ki a modulunk felépítése: app/code Aion/ Test/ etc/module.xml Helper/Data.php composer.json COPYING.txt README.md registration.php

A következő lépésben aktiválni kell a modult, és megvizsgálni, hogy a Magento 2.0 rendszer felismerte-e megfelelően. A Magento 1.x rendszerben ez a frontend vagy admin oldal frissítéssel történt meg, azonban a 2.0-ban a korábban már említett parancsokat kell alkalmaznunk.

A terminálban belépünk a /bin könyvtárba, majd kiadjuk a php magento module:status parancsot. Ha mindent jól végeztünk el, akkor listázásra kerül az engedélyezett (Enabled) modulok listája és még nem aktív vagy nem engedélyezett (Disabled) modulok listája. Utóbbi helyen jelenik meg a saját modulunk is: Aion_Test. Amennyiben nem jelenik meg, a modulunk felépítése során valamit elrontottunk.

Ezután kiadjuk a terminálban /bin könyvtárban a php magento module:enable Aion_Test parancsot. Ekkor megjelenik, hogy a modult a rendszer felismerte és engedélyezte. Ez valójában azt jelenti, hogy az app/etc/config.php fájlban lévő tömbbe bekerült az ’Aion_Test’ => 1 bejegyzés. Ezután értesítést kapunk, hogy a modult adatbázis szinten is „regisztráljuk” be. Kiadjuk a terminálban a php magento setup:upgrade parancsot.

A parancs végrehajtása során a Magento 2.0 végigfut az összes alap modulon és egyedi modulon és update-eli a rendszert, vagyis lefuttatja a séma és adat scripteket, amennyiben nagyobb verzió számot talál, mint a jelenlegi. Mindez a mi modulunk esetében az jelenti, hogy korábban leírt 2.0.0 verzió szám beírásra kerül a setup_module táblába.

Ha ezután belépünk az admin felületre és kiválasztjuk Store / Configuration menüpontot, majd ezt követően az Advanced / Advanced aloldalt, akkor megjelenik a modulunk a listában enabled állapotban. Ezzel el is készültünk az alap modulunkkal.

4) Modul admin konfiguráció és jogosultság kezelés

Miután az alap modulunk elkészült, felépítjük a hozzá tartozó admin konfigurációt és jogosultság kezelést. Első lépésben a konfigurációhoz szükséges fájlt hozzuk létre, ami az app/code/Aion/Test/etc/adminhtml könyvtárban lesz elhelyezve és a neve system.xml.

<?xml version="1.0"?>
<!--
/**
 * Copyright © 2015 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
-->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Config:etc/system_file.xsd">
    <system>
        <tab id="aion_tab" translate="label" sortOrder="500">
            <label>Aion Extensions</label>
        </tab>
        <section id="aion" translate="label" type="text" sortOrder="100" showInDefault="1" showInWebsite="1" showInStore="1">
            <label>Test Extension</label>
            <tab>aion_tab</tab>
            <resource>Aion_Test::test</resource>
            <group id="basic" translate="label" type="text" sortOrder="10" showInDefault="1" showInWebsite="1" showInStore="1">
                <label>Basic</label>
                <field id="enabled" translate="label" type="select" sortOrder="10" showInDefault="1" showInWebsite="1" showInStore="1">
                    <label>Enable Extension</label>
                    <source_model>Magento\Config\Model\Config\Source\Yesno</source_model>
                </field>
            </group>
            <group id="more" translate="label" type="text" sortOrder="20" showInDefault="1" showInWebsite="1" showInStore="1">
                <label>More</label>
                <field id="variable" translate="label" type="text" sortOrder="10" showInDefault="1" showInWebsite="1" showInStore="1">
                    <label>Some Variable</label>
                </field>
            </group>
        </section>
    </system>
</config>

A fájlban definiálunk egy <tab> tag-et is, így a modulunk saját menüpontban (Aion Extensions -> Test Extension) fog megjelenni az admin Stores / Configuration aloldalán. Ezen belül implementálunk két tab-ot (basic és more id-kkal). Az elsőbe helyezzük el az alap No / Yes select típusú konfigurációs változót, amit a modul engedélyezésére és tiltására használunk. Lekérdezését már korábban implementáltuk a Data.php file-ban(Helper/Data.php). A példa kedvéért létrehozunk egy text típusú konfigurációs változót is Variable névvel későbbi használatra.

A fájlban még fontos rész a <resource> tag is, aminek a jogosultság kezelés implementálásakor lesz szerepe. Ez a mi esetünkben Aion_Test::test.   A következő lépésben létrehozzuk a jogosultság kezeléshez szükséges fájlt is, ami az app/code/Aion/Test/etc könyvtárba kerül acl.xml néven. Ennek tartalma:

<?xml version="1.0"?>
<!--
/**
 * Copyright © 2015 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
-->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Acl/etc/acl.xsd">
    <acl>
        <resources>
            <resource id="Magento_Backend::admin">
                <resource id="Magento_Backend::stores">
                    <resource id="Magento_Backend::stores_settings">
                        <resource id="Magento_Config::config">
                            <resource id="Aion_Test::test" title="Aion Test Extension Section" />
                        </resource>
                    </resource>
                </resource>
            </resource>
        </resources>
    </acl>
</config>

Amint ezzel készen vagyunk, leellenőrizzük, hogy megfelelően létrejött-e a modulhoz tartozó jogosultság beállítás a Role Resource (Admin felhasználó szerepek) részben. Az admin felületen megnyitjuk a System / User Roles menüpontot, majd itt bármelyik adminisztrátori csoportot (alapból egy van) megnyitva a Role Resouces almenüt kiválasztva, majd a Resource Access-nél a Custom lehetőség alatt megvizsgáljuk, hogy a fában megjelenik-e a saját modulunk.

Ezt követően leellenőrizzük a korábban kialakított konfigurációs menüpont, és hogy tartalma is megjelenik-e. Az adminban a Stores / Configuration-t választva a bal menüben megnézzük, hogy megjelent-e a saját menüpontunk (Aion Extensions) és annak taralma (Test Extension). Az alap konfigurációs értékeket az app/code/Aion/Test/etc könyvtárban lévő config.xml fájlban határozzuk meg:

<?xml version="1.0"?>
<!--
/**
 * Copyright © 2015 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
-->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Store:etc/config.xsd">
    <default>
        <aion>
            <basic>
                <enabled>1</enabled> 
            </basic>
        </aion>
    </default>
</config>

Jól látható, hogy a file-ban látható tag-ek megfelelnek a system.xml-ben lévő saját id-kkal.

5) Alap frontend controller, block, layout és template

A következőkben létrehozunk egy saját frontend controller-t, a hozzátartozó layout és router konfigurációt. Majd ezt követően egy template fájlt és a hozzá tartozó block-ot is implementáljuk. Elsőként elkészítjük a controller fájlt, ami valójában egy Action-t jelent. Ezt az app/code/Aion/Test/Controller/Index/ könyvtárban lévő Index.php-val implementáljuk. A fájl tartalma:

<?php
/**
 * Copyright © 2015 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
namespace Aion\Test\Controller\Index;

use Magento\Framework\App\Action\Context;
use Magento\Framework\View\Result\PageFactory;
use Magento\Framework\Controller\Result\ForwardFactory;
use Magento\Framework\Exception\NotFoundException;
use Magento\Framework\App\RequestInterface;

/**
 * Contact index controller
 */
class Index extends \Magento\Framework\App\Action\Action
{
    /**
     * @var PageFactory
     */
    protected $resultPageFactory;

    /**
     * @var ForwardFactory
     */
    protected $resultForwardFactory;

    /**
     * @var \Aion\Test\Helper\Data
     */
    protected $helper;

    /**
     * Index constructor.
     *
     * @param \Magento\Framework\App\Action\Context $context
     * @param \Magento\Framework\View\Result\PageFactory $resultPageFactory
     * @param \Magento\Framework\Controller\Result\ForwardFactory $resultForwardFactory
     * @param \Aion\Test\Helper\Data $helper
     */
    public function __construct(
        Context $context,
        PageFactory $resultPageFactory,
        ForwardFactory $resultForwardFactory,
        \Aion\Test\Helper\Data $helper
    ) {
        $this->resultPageFactory = $resultPageFactory;
        $this->resultForwardFactory = $resultForwardFactory;
        $this->helper = $helper;
        parent::__construct($context);
    }

    /**
     * Dispatch request
     *
     * @param RequestInterface $request
     * @return \Magento\Framework\App\ResponseInterface
     * @throws \Magento\Framework\Exception\NotFoundException
     */
    public function dispatch(RequestInterface $request)
    {
        if (!$this->helper->isEnabled()) {
            throw new NotFoundException(__('Page not found.'));
        }
        return parent::dispatch($request);
    }

    /**
     * Aion Test Page
     *
     * @return \Magento\Framework\View\Result\Page
     */
    public function execute()
    {
        /** @var \Magento\Framework\View\Result\Page $resultPage */
        $resultPage = $this->resultPageFactory->create();
        $resultPage->getConfig()->getTitle()->set(__('Aion Test Page'));
        if (!$resultPage) {
            $resultForward = $this->resultForwardFactory->create();
            return $resultForward->forward('noroute');
        }
        return $resultPage;
    }
} 

A fájlban három fontos függvény található, mindhárom a szülőosztályban van definiálva. A __construct függvényt használjuk arra, hogy az általunk használni kívánt egyéb osztályokat injektáljuk (pl. helper osztály, dependency injection).  A dispatch függvény automatikusan le fog futni a __construct után. Itt vizsgáljuk meg, hogy a modulunk engedélyezve van-e, vagy sem és megfelelően lekezeljük. Végül pedig az execute függvény jelenti magát az action-t, ami a jelenlegi esetben az Index action-nek felel meg.

A működése során a $resultPageFactory objektumot létrehozzuk (ami a későbbi layout konfiguráció alapján felépíti az oldalt). Az objektum setConfig függvényével beállítunk egy oldal title-t. Ezután megvizsgáljuk, hogy az objektum létrejött-e, vagy sem. Amennyiben nincs hiba, visszatérünk a $resultPage objektummal, ellenkező esetben noroute (vagyis 404-es) oldalra irányítjuk az action-t.   Létrehozzuk az app/code/Aion/Test/etc/frontend könyvtárban a routes.xml fájlt, amiben meghatározzuk, hogy milyen url alatt szeretnénk meghívni a modulunkhoz controller-eket. A fájl tartalma:

<?php
/**
 * Copyright © 2015 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
namespace Aion\Test\Controller\Index;

use Magento\Framework\App\Action\Context;
use Magento\Framework\View\Result\PageFactory;
use Magento\Framework\Controller\Result\ForwardFactory;
use Magento\Framework\Exception\NotFoundException;
use Magento\Framework\App\RequestInterface;

/**
 * Contact index controller
 */
class Index extends \Magento\Framework\App\Action\Action
{
    /**
     * @var PageFactory
     */
    protected $resultPageFactory;

    /**
     * @var ForwardFactory
     */
    protected $resultForwardFactory;

    /**
     * @var \Aion\Test\Helper\Data
     */
    protected $helper;

    /**
     * Index constructor.
     *
     * @param \Magento\Framework\App\Action\Context $context
     * @param \Magento\Framework\View\Result\PageFactory $resultPageFactory
     * @param \Magento\Framework\Controller\Result\ForwardFactory $resultForwardFactory
     * @param \Aion\Test\Helper\Data $helper
     */
    public function __construct(
        Context $context,
        PageFactory $resultPageFactory,
        ForwardFactory $resultForwardFactory,
        \Aion\Test\Helper\Data $helper
    ) {
        $this->resultPageFactory = $resultPageFactory;
        $this->resultForwardFactory = $resultForwardFactory;
        $this->helper = $helper;
        parent::__construct($context);
    }

    /**
     * Dispatch request
     *
     * @param RequestInterface $request
     * @return \Magento\Framework\App\ResponseInterface
     * @throws \Magento\Framework\Exception\NotFoundException
     */
    public function dispatch(RequestInterface $request)
    {
        if (!$this->helper->isEnabled()) {
            throw new NotFoundException(__('Page not found.'));
        }
        return parent::dispatch($request);
    }

    /**
     * Aion Test Page
     *
     * @return \Magento\Framework\View\Result\Page
     */
    public function execute()
    {
        /** @var \Magento\Framework\View\Result\Page $resultPage */
        $resultPage = $this->resultPageFactory->create();
        $resultPage->getConfig()->getTitle()->set(__('Aion Test Page'));
        if (!$resultPage) {
            $resultForward = $this->resultForwardFactory->create();
            return $resultForward->forward('noroute');
        }
        return $resultPage;
    }
} 

A router konfigurációban látható, hogy a modulunkhoz a „test” url-t rendeltük, vagyis ez esetben a {{base_url}}test/index/index fogja meghívni a fent részletezett controller-t és azon belül az execute függvényt (Index action). Természetesen index controllert és action-t nem kell megadni mindig az url-ben, a {{base_url}}test/ is ugyanerre a helyre fog minket irányítani.   Következőkben létrehozzuk a layout fájlt ami az app/code/Aion/Test/view/frontend/layout könyvtárban kap helyet test_index_index.xml néven. Jól látható, hogy a fájl neve követi a router -> controller -> action neveket. A fájl tartalma:

<?xml version="1.0"?>
<!--
/**
 * Copyright © 2015 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
-->
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" layout="1column" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
    <head>
        <title>Aion Test Page</title>
    </head>
    <body>
        <referenceContainer name="content">
            <block class="Aion\Test\Block\Test" name="testPage" template="Aion_Test::test.phtml" />
        </referenceContainer>
    </body>
</page>

A layout file <head> részében beállítjuk az oldal alap címét, a tartalmi részben (content) egy block-ot és a hozzá tartozó template fájlt is definiáljuk. A block-ot az app/code/Aion/Test/Block könyvtárban lévő Test.php-ban valósítjuk meg. A fájl tartalma:

<?php
/**
 * Copyright © 2015 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
namespace Aion\Test\Block;

use Magento\Framework\View\Element\Template;

/**
 * Aion Test Page block
 */
class Test extends Template
{
    /**
     * @param Template\Context $context
     * @param array $data
     */
    public function __construct(Template\Context $context, array $data = [])
    {
        parent::__construct($context, $data);
    }

    /**
     * Test function
     *
     * @return string
     */
    public function getTest()
    {
        return 'This is a test function for some logic...';
    }
}  

Észrevehetjük, hogy a példában használt __construct függvényben nem deklaráltunk semmit, így ez lényegében el is hagyható. Azonban célszerű már az elején megvalósítani, ha például később egy storeManager vagy Helper-t vagy bármi mást is szeretnénk implementálni. A template file az app/code/Aion/Test/view/frontend/templates könyvtárban kap helyet test.phtml néven. A fájl tartalma:

<?php
/**
 * Copyright © 2015 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
?>

<?php
/**
 * @var $block \Aion\Test\Block\Test
 */
?>

<p><?php echo $block->getTest(); ?></p>
<p><?php echo __('This is a text.') ?></p>

A template file a példa kedvéért meghívja a Block-ban definiált teszt függvényt, és emellett egy egyszerű string-et is kiír, ami egy translate függvénybe van ágyazva. Ha mindennel elkészültünk, a modulunk így néz ki: app/code Aion/ Test/ Block/Test.php Controller/Index/Index.php etc/adminhtml/system.xml /frontend/routes.xml acl.xml config.xml module.xml Helper/Data.php view/frontend /layout/test_index_index.xml /templates/test.phtml composer.json COPYING.txt README.md registration.php

Az előzőekben megismerkedtünk egy alap Magento 2.0 modul elkészítésével és felépítésével. Most folytatjuk, és megismerkedünk azzal, hogyan készíthetünk saját adatbázis táblát, tölthetjük fel alapadatokkal a modulunkhoz, és a táblaadatok kezeléséhez szükséges modellekkel, ill. collection-nel. Emellett a frontend-en megnézzük, hogy érhetőek el tábla adatok és milyen módon jeleníthetjük meg őket.

6) Modulhoz tartozó adatbázis tábla elkészítése – 1

A modulhoz tartozó adatbázis táblát egy a Magento 1.x-ből már ismert installer script segítségével készíthetjük el, azonban a file neve és felépítése kicsit eltérő.   Az adatbázis táblát az app/code/Aion/Test/Setup könyvtárban lévő InstallSchema.php-ban valósítjuk meg. A fájl tartalma:

<?php
/**
 * Copyright © 2016 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */

namespace Aion\Test\Setup;

use Magento\Framework\Setup\InstallSchemaInterface;
use Magento\Framework\Setup\ModuleContextInterface;
use Magento\Framework\Setup\SchemaSetupInterface;
use Magento\Framework\DB\Adapter\AdapterInterface;

/**
 * @codeCoverageIgnore
 */
class InstallSchema implements InstallSchemaInterface
{
    /**
     * Install table
     *
     * @param \Magento\Framework\Setup\SchemaSetupInterface $setup
     * @param \Magento\Framework\Setup\ModuleContextInterface $context
     * @throws \Zend_Db_Exception
     */
    public function install(SchemaSetupInterface $setup, ModuleContextInterface $context)
    {
        $installer = $setup;

        $installer->startSetup();
        /**
         * Create table 'aion_test'
         */
        $table = $installer->getConnection()->newTable(
            $installer->getTable('aion_test')
        )->addColumn(
            'test_id',
            \Magento\Framework\DB\Ddl\Table::TYPE_SMALLINT,
            null,
            ['identity' => true, 'nullable' => false, 'primary' => true],
            'Test ID'
        )->addColumn(
            'name',
            \Magento\Framework\DB\Ddl\Table::TYPE_TEXT,
            255,
            ['nullable' => false],
            'Test Name'
        )->addColumn(
            'email',
            \Magento\Framework\DB\Ddl\Table::TYPE_TEXT,
            255,
            ['nullable' => false],
            'Test Email'
        )->addColumn(
            'creation_time',
            \Magento\Framework\DB\Ddl\Table::TYPE_TIMESTAMP,
            null,
            ['nullable' => false, 'default' => \Magento\Framework\DB\Ddl\Table::TIMESTAMP_INIT],
            'Test Creation Time'
        )->addColumn(
            'update_time',
            \Magento\Framework\DB\Ddl\Table::TYPE_TIMESTAMP,
            null,
            ['nullable' => false, 'default' => \Magento\Framework\DB\Ddl\Table::TIMESTAMP_INIT_UPDATE],
            'Test Modification Time'
        )->addColumn(
            'is_active',
            \Magento\Framework\DB\Ddl\Table::TYPE_SMALLINT,
            null,
            ['nullable' => false, 'default' => '1'],
            'Is Test Active'
        )->addIndex(
            $setup->getIdxName(
                $installer->getTable('aion_test'),
                ['name', 'email'],
                AdapterInterface::INDEX_TYPE_FULLTEXT
            ),
            ['name', 'email'],
            ['type' => AdapterInterface::INDEX_TYPE_FULLTEXT]
        )->setComment(
            'Aion Test Table'
        );
        $installer->getConnection()->createTable($table);

        $installer->endSetup();
    }
}

A script létrehozza a modulhoz tartozó példa táblát, aminek neve „aion_test” lesz. Ezután létrehozza az alábbi mezőket is:

  • test_id – primary key, smallint (6)
  • name – varchar (255)
  • email – varchar (255)
  • creation_time – timestamp
  • update_time – timestamp
  • is_active – smallint (6)

Ezt követően a scriptben célszerű és erősen ajánlott index-szel (addIndex) ellátni azon text (text és varchar és egyéb, ha szükséges) típusú oszlopokat, melyekben keresni fogunk a későbbiekben vagy a leendő collection-t szűrni fogjuk. A példa esetében ez a két mező a name és az email.

7) Modulhoz tartozó adatbázis tábla elkészítése – 2

Korábban már adtunk verziószámot a modulunkhoz az app/code/Aion/Test/etc könyvtárban lévő module.xml segítségével ‒ amiben meghatároztuk az alap verziót, majd a modul engedélyezése (terminál parancsok) segítségével ez a verziószám bekerült a „setup_module” Magento 2.0 táblába. Arra, hogy fent elkészített script lefusson, két lehetőségünk van: növeljük a verziószámot a modulunkban, vagy töröljük a modulunkhoz tartozó korábbi verziószám bejegyzést.

Mivel még csak a modul fejlesztésének elején tartunk, így célszerű törölni „setup_module” Magento 2.0 táblából a modulunkhoz tartozó bejegyzést. Miután ezt megtettük, ismét futtassuk le a setup:upgrade magento parancsot a terminálból. Ha mindent jól csináltunk, a modulhoz tartozó táblánk létrejön az adatbázisban.

8) Modulhoz tartozó modellek és collection létrehozása

Ahhoz, hogy adatokkal tudjuk feltölteni az elkészült táblát vagy adatokat tudjunk lekérdezni, el kell készítenünk a modul model, resource és collection file-okat. Az alap model file az app/code/Aion/Test/Model könyvtárban lévő Test.php-ban valósítjuk meg. A fájl tartalma:

<?php
/**
 * Copyright © 2016 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
namespace Aion\Test\Model;

/**
 * Aion Test model
 *
 * @method \Aion\Test\Model\ResourceModel\Test _getResource()
 * @method \Aion\Test\Model\ResourceModel\Test getResource()
 * @method string getId()
 * @method string getName()
 * @method string getEmail()
 * @method setSortOrder()
 * @method int getSortOrder()
 */
class Test extends \Magento\Framework\Model\AbstractModel
{
    /**
     * Statuses
     */
    const STATUS_ENABLED = 1;
    const STATUS_DISABLED = 0;

    /**
     * Aion Test cache tag
     */
    const CACHE_TAG = 'aion_test';

    /**
     * @var string
     */
    protected $_cacheTag = 'aion_test';

    /**
     * Prefix of model events names
     *
     * @var string
     */
    protected $_eventPrefix = 'aion_test';

    /**
     * @return void
     */
    protected function _construct()
    {
        $this->_init('Aion\Test\Model\ResourceModel\Test');
    }

    /**
     * Get identities
     *
     * @return array
     */
    public function getIdentities()
    {
        return [self::CACHE_TAG . '_' . $this->getId(), self::CACHE_TAG . '_' . $this->getId()];
    }

    /**
     * Prepare item's statuses
     *
     * @return array
     */
    public function getAvailableStatuses()
    {
        return [self::STATUS_ENABLED => __('Enabled'), self::STATUS_DISABLED => __('Disabled')];
    }

}

A model file-ban definiáljuk a Magento 2.0 cache működéshez szükséges két cache tag-et. Fontos még event prefix-et is definiálni, hogy később observer-ek használata esetén tudjuk használni, mint event name. A legfontosabb a _construct() függvény, melyben meghatározzuk a modellhez tartozó resource modellt. A getAvailableStatuses() függvényt és két STATUS_* konstansokat későbbi használatra célszerű létrehozni. A getIdentities() függvény implementálása nem kötelező, de a cache kezelés megfelelő működéséhez célszerű.

Miután elkészült az alap modell fájlunk, hozzuk létre a hozzá tartozó resource modellt is. Az alap resource modell fájlt az app/code/Aion/Test/Model/ResourceModel könyvtárban lévő Test.php-ban valósítjuk meg. A fájl tartalma:

<?php
/**
 * Copyright © 2016 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
namespace Aion\Test\Model;

/**
 * Aion Test model
 *
 * @method \Aion\Test\Model\ResourceModel\Test _getResource()
 * @method \Aion\Test\Model\ResourceModel\Test getResource()
 * @method string getId()
 * @method string getName()
 * @method string getEmail()
 * @method setSortOrder()
 * @method int getSortOrder()
 */
class Test extends \Magento\Framework\Model\AbstractModel
{
    /**
     * Statuses
     */
    const STATUS_ENABLED = 1;
    const STATUS_DISABLED = 0;

    /**
     * Aion Test cache tag
     */
    const CACHE_TAG = 'aion_test';

    /**
     * @var string
     */
    protected $_cacheTag = 'aion_test';

    /**
     * Prefix of model events names
     *
     * @var string
     */
    protected $_eventPrefix = 'aion_test';

    /**
     * @return void
     */
    protected function _construct()
    {
        $this->_init('Aion\Test\Model\ResourceModel\Test');
    }

    /**
     * Get identities
     *
     * @return array
     */
    public function getIdentities()
    {
        return [self::CACHE_TAG . '_' . $this->getId(), self::CACHE_TAG . '_' . $this->getId()];
    }

    /**
     * Prepare item's statuses
     *
     * @return array
     */
    public function getAvailableStatuses()
    {
        return [self::STATUS_ENABLED => __('Enabled'), self::STATUS_DISABLED => __('Disabled')];
    }

}

A legfontosabb, amit implementálnunk kell, a protected _construct() függvény, amiben meghatározzuk, hogy a korábban létrehozott táblához melyik mező a primary key. Miután elkészültünk a resource modellel, készítsük el a collection-t is. Az alap collection osztály fájlt az app/code/Aion/Test/Model/ResourceModel/Test könyvtárban lévő Collection.php-ban valósítjuk meg. A fájl tartalma:

<?php
/**
 * Copyright © 2016 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
namespace Aion\Test\Model\ResourceModel\Test;

/**
 * Aion Test collection
 */
class Collection extends \Magento\Framework\Model\ResourceModel\Db\Collection\AbstractCollection
{
    /**
     * @var string
     */
    protected $_idFieldName = 'test_id';

    /**
     * Store manager
     *
     * @var \Magento\Store\Model\StoreManagerInterface
     */
    protected $storeManager;

    /**
     * @param \Magento\Framework\Data\Collection\EntityFactoryInterface $entityFactory
     * @param \Psr\Log\LoggerInterface $logger
     * @param \Magento\Framework\Data\Collection\Db\FetchStrategyInterface $fetchStrategy
     * @param \Magento\Framework\Event\ManagerInterface $eventManager
     * @param \Magento\Store\Model\StoreManagerInterface $storeManager
     * @param \Magento\Framework\DB\Adapter\AdapterInterface|null $connection
     * @param \Magento\Framework\Model\ResourceModel\Db\AbstractDb|null $resource
     */
    public function __construct(
        \Magento\Framework\Data\Collection\EntityFactoryInterface $entityFactory,
        \Psr\Log\LoggerInterface $logger,
        \Magento\Framework\Data\Collection\Db\FetchStrategyInterface $fetchStrategy,
        \Magento\Framework\Event\ManagerInterface $eventManager,
        \Magento\Store\Model\StoreManagerInterface $storeManager,
        \Magento\Framework\DB\Adapter\AdapterInterface $connection = null,
        \Magento\Framework\Model\ResourceModel\Db\AbstractDb $resource = null
    ) {
        parent::__construct($entityFactory, $logger, $fetchStrategy, $eventManager, $connection, $resource);
        $this->storeManager = $storeManager;
    }

    /**
     * Define resource model
     *
     * @return void
     */
    protected function _construct()
    {
        $this->_init('Aion\Test\Model\Test', 'Aion\Test\Model\ResourceModel\Test');
    }
}

A collection osztályban a _construct() függvényt implementáljuk, ahol valójában meghatározzuk, hogy a korábban elkészített modell osztályhoz melyik resource modell osztály tartozik. Lényegében ez elég is lenne collection-nek, azonban előretekintve helyezzük be (injektáljuk) már most a store manager osztályt is a public __construct() függvénybe későbbi felhasználás végett, hiszen minden modulnál követelmény a multistore támogatás. Amennyiben a három fájllal elkészültünk, akkor már létre is hoztuk azon osztályokat, melyekkel adatokat tudunk írni, ill. olvasni korábban létrehozott adatbázis táblánkból.

9) Tábla feltöltése adatokkal, script segítségével

A modell struktúra elkészítése szükséges volt ahhoz, hogy script-tel is tudjunk adatokat hozzáadni a modul alap táblájához. Az adat script-et az app/code/Aion/Test/Setup könyvtárban lévő InstallData.php-ban valósítjuk meg. A fájl tartalma:

<?php
/**
 * Copyright © 2016 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
namespace Aion\Test\Setup;

use Aion\Test\Model\Test;
use Aion\Test\Model\TestFactory;
use Magento\Framework\Setup\InstallDataInterface;
use Magento\Framework\Setup\ModuleContextInterface;
use Magento\Framework\Setup\ModuleDataSetupInterface;

/**
 * @codeCoverageIgnore
 */
class InstallData implements InstallDataInterface
{
    /**
     * Test factory
     *
     * @var TestFactory
     */
    private $testFactory;

    /**
     * Init
     *
     * @param TestFactory $testFactory
     */
    public function __construct(TestFactory $testFactory)
    {
        $this->testFactory = $testFactory;
    }

    /**
     * {@inheritdoc}
     * @SuppressWarnings(PHPMD.ExcessiveMethodLength)
     */
    public function install(ModuleDataSetupInterface $setup, ModuleContextInterface $context)
    {
        $testItems = [
            [
                'name' => 'John Doe',
                'email' => '[email protected]',
                'is_active' => 1,
            ],
            [
                'name' => 'Jane Doe',
                'email' => '[email protected]',
                'is_active' => 0,
            ],

            [
                'name' => 'Steve Test',
                'email' => '[email protected]',
                'is_active' => 1,
            ],
        ];

        /**
         * Insert default items
         */
        foreach ($testItems as $data) {
            $this->createTest()->setData($data)->save();
        }

        $setup->endSetup();
    }

    /**
     * Create Test item
     *
     * @return Test
     */
    public function createTest()
    {
        return $this->testFactory->create();
    }
}

Az InstallData osztályban implementáljuk az install(…) függvényt, melyben létrehozzuk a teszt adatokat egy többdimenziós tömbben. Majd ezen végig iterálva meghívjuk a createTest() függvényt, melynek az új Test modell létrehozása a feladata, és a tömbök, mint adatok hozzáadása után mentjük a modellt.

Itt fontos megemlíteni az osztályban létrehozott és __construct() függvényben injektált TestFactory osztályt is. Ezt az osztályt a Magento 2.0 hozza létre automatikusan a /var/generation/Aion/Test/Model könyvtárba az első futása során ($this->testFactory-> create()). Mivel még mindig a modulunk fejlesztése elején tartunk, dobjuk el manuálisan a korábban létrehozott „aion_test” táblát az adatbázisból, és töröljük a „setup_module” Magento 2.0 táblából a modulunkhoz tartozó bejegyzést. Miután ezt megtettük, ismét futtassuk le a setup:upgrade magento parancsot terminálból.

Ha mindent jól csináltunk, a modulhoz tartozó táblánk ismét létrejön az adatbázisban immár adatokkal feltöltve. Természetesen ehelyett verziószám módosítással (emeléssel) is tudjuk az adatfeltöltést futtatni parancssorból, így ekkor nem kell manuálisan eldobni a korábban létrehozott táblánkat és „setup_module” táblába sem kell belenyúlni.

10) Tábla update script és verzió növelés

Ahogy fejlesztjük a modulunkat, sokszor lesz szükségünk az alap adatbázis tábla módosítására, esetleg új adatbázis tábla létrehozására. A Magento 1.x-ben ezt upgrade script-ekkel tehettük meg, mint adatbázis, mint pedig data oldalon. A Magento 2.0 modulunk sincs másképp, csak szerencsére az adatbázis script-eket egy fájlban kell ezúton kezelni, több különálló fájl helyett.

Az adatbázis update script-et az app/code/Aion/Test/Setup könyvtárban lévő UpgradeSchema.php-ban valósítjuk meg. A fájl tartalma:

<?php
/**
 * Copyright © 2016 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
namespace Aion\Test\Setup;

use Aion\Test\Model\Test;
use Aion\Test\Model\TestFactory;
use Magento\Framework\Setup\InstallDataInterface;
use Magento\Framework\Setup\ModuleContextInterface;
use Magento\Framework\Setup\ModuleDataSetupInterface;

/**
 * @codeCoverageIgnore
 */
class InstallData implements InstallDataInterface
{
    /**
     * Test factory
     *
     * @var TestFactory
     */
    private $testFactory;

    /**
     * Init
     *
     * @param TestFactory $testFactory
     */
    public function __construct(TestFactory $testFactory)
    {
        $this->testFactory = $testFactory;
    }

    /**
     * {@inheritdoc}
     * @SuppressWarnings(PHPMD.ExcessiveMethodLength)
     */
    public function install(ModuleDataSetupInterface $setup, ModuleContextInterface $context)
    {
        $testItems = [
            [
                'name' => 'John Doe',
                'email' => '[email protected]',
                'is_active' => 1,
            ],
            [
                'name' => 'Jane Doe',
                'email' => '[email protected]',
                'is_active' => 0,
            ],

            [
                'name' => 'Steve Test',
                'email' => '[email protected]',
                'is_active' => 1,
            ],
        ];

        /**
         * Insert default items
         */
        foreach ($testItems as $data) {
            $this->createTest()->setData($data)->save();
        }

        $setup->endSetup();
    }

    /**
     * Create Test item
     *
     * @return Test
     */
    public function createTest()
    {
        return $this->testFactory->create();
    }
}

A példában egy új mezőt (sort_order) adunk az alap adatbázis táblához („aion_test”) upgrade script segítségével. Az upgrade függvényben implementált módosítás csak akkor fog lefutni, ha a modul verziószáma eléri a példában látható 2.0.1 értéket.

11) Adatok megjelenítése frontend-en

Ahhoz, hogy frontend-en a létrehozott adatokat meg tudjuk jeleníteni, módosítani kell a frontend template-et és a hozzá tartozó block osztályt is. Az block osztályt már korábban elkészítettük, most kiegészítjük. A block osztály az  app/code/Aion/Block/ könyvtárban lévő Test.php-ban valósítjuk meg. A fájl tartalma:

<?php
/**
 * Copyright © 2016 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
namespace Aion\Test\Setup;

use Aion\Test\Model\Test;
use Aion\Test\Model\TestFactory;
use Magento\Framework\Setup\InstallDataInterface;
use Magento\Framework\Setup\ModuleContextInterface;
use Magento\Framework\Setup\ModuleDataSetupInterface;

/**
 * @codeCoverageIgnore
 */
class InstallData implements InstallDataInterface
{
    /**
     * Test factory
     *
     * @var TestFactory
     */
    private $testFactory;

    /**
     * Init
     *
     * @param TestFactory $testFactory
     */
    public function __construct(TestFactory $testFactory)
    {
        $this->testFactory = $testFactory;
    }

    /**
     * {@inheritdoc}
     * @SuppressWarnings(PHPMD.ExcessiveMethodLength)
     */
    public function install(ModuleDataSetupInterface $setup, ModuleContextInterface $context)
    {
        $testItems = [
            [
                'name' => 'John Doe',
                'email' => '[email protected]',
                'is_active' => 1,
            ],
            [
                'name' => 'Jane Doe',
                'email' => '[email protected]',
                'is_active' => 0,
            ],

            [
                'name' => 'Steve Test',
                'email' => '[email protected]',
                'is_active' => 1,
            ],
        ];

        /**
         * Insert default items
         */
        foreach ($testItems as $data) {
            $this->createTest()->setData($data)->save();
        }

        $setup->endSetup();
    }

    /**
     * Create Test item
     *
     * @return Test
     */
    public function createTest()
    {
        return $this->testFactory->create();
    }
}

A block osztály konstruktorába implementáljuk a korábban létrehozott Test modelt és a hozzá tartozó testFactory-t és ezek mellett a collectionFactory-t (itemCollectionFactory) is. A collectionFactory osztály nagyon hasonló a testFactory-hoz, szintén a Magento 2.0 hozza létre a var/generation/Aion/Test/Model/ResourceModel/Test/ könyvtárban az első meghívása után. A getTestModel() függvény egy modellt példányosít, és a betöltésért felelős, míg a getItems() függvény egy teljes collection-t hoz létre.

A block-hoz tartozó template file-ban kiírathatjuk az adatokat tesztelésképp. A fájl tartalma:

<?php
/**
 * Copyright © 2016 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
?>

<?php
/**
 * @var $block \Aion\Test\Block\Test
 */
?>
<div class="aion-test">
    <h2><?php echo __('This is a test extension!') ?></h2>
    <!-- See a sample model -->
    <?php \Zend_Debug::dump($block->getTestModel()->getData()); ?>
    <!-- See a sample collection -->
    <?php \Zend_Debug::dump($block->getItems()->getData()); ?>

    <!-- See a sample collection iteration -->
    <?php $items = $block->getItems(); ?>
    <?php if ($items->getSize()) : ?>
        <?php foreach ($items as $item) : ?>
            <h3><?php echo $block->stripTags($item->getName()) ?></h3>
            <p>
                <span><?php echo __('Email:'); ?></span>&nbsp;
                <span><?php echo $item->getEmail() ?></span>
            </p>
        <?php endforeach; ?>
    <?php endif; ?>
</div>

Ebben a cikkben részletesen átvettünk jó néhány témakört az alap Magento 2.0 modulunk fejlesztéséhez: hozzáadtunk egy saját adatbázis táblát, és teszt adatokkal feltöltöttük. Az ehhez szükséges modellt, resource-t és collection-t is létrehoztuk, ill. a teszt adatokat megjelenítettük a frontend-en is.

VÉGE AZ 1. RÉSZNEK, DE HAMAROSAN FOLYTATJUK!   A 2. részben  a modulhoz tartozó admin táblázat (grid) elkészítésével, illetve a szükséges controllerek-kel is megismerkedünk majd.

 

Magento vs. WooCommerce – Melyik az okosabb választás?

A piacon rengeteg különféle e-kereskedelmi rendszer közül választhatunk, a domináns azonban a címben szereplő két versenyző, és nem is véletlenül. Mindkét rendszer rengeteg előnnyel rendelkezik, melyek vetélytársaik fölé emelik őket – de összehasonlítva hogyan teljesítenek? Honnan tudhatod, hogy jól választasz?

Mielőtt belevágnál a kiválasztás folyamatába, ajánlatos lehetőségeidet, terveidet és igényeidet számba venni.

  • Ki a célcsoportod, mekkora a célpiacod?
  • Hány termékkel számolsz és milyen terheléssel?
  • Hogyan képzeled el az oldalad?
  • Képes vagy infrastruktúrával megtámogatni, pl. ERP-rendszerrel?
  • Keveset vagy többet szeretnél költeni a testreszabásra megjelenésében, funkcionalitásában? 
  • Szükséged van egy fejlesztőcsapat nyújtotta biztonságos háttérre, vagy megfelel egy előre meghatározott alap funkcionalitás, amit korlátozottan ugyan, de egymagad tudsz beállítani?

Számos dolgot kell számba venned még azelőtt, hogy letennéd a voksod bármelyik megoldás mellett. Ugyan kipróbálni bármelyiket nem kerül semmibe, a nem megfelelő döntéssel azonban értékes időt vesztegetsz. És persze az átállás is problémás lehet, ha egyszer már beleszoktál a használatba, de rájössz, hogy mégsem a tökéleteset választottad.

Most tehát részletesen végigvesszük az egyes szempontokat, amelyek alapján bölcs döntést hozhatsz, és hatékonyan értékesítheted online portékádat.

Miben hasonlít egymásra a Magento és a WooCommerce?

Az egyik legfontosabb hasonlóság a két rendszer közt, hogy a Magento és a WooCommerce egyaránt nyílt forráskódúak, vagyis bárki hozzájárulhat fejlesztésükhöz. Ez mindkét esetben azt jelenti, hogy profi fejlesztők foglalkoznak velük, mégpedig jóval többen, mint egyébként céges kereteken belül maradva lehetséges volna.

A nyílt forráskód előnye a rugalmasság: ha valamire szükségünk van, de a rendszer alapból nem tartalmazza, jó eséllyel valaki már lefejlesztett hozzá egy kiegészítőt – ha pedig mégsem, egyszerűen keresnünk kell valakit, aki megteszi ezt nekünk. Mindkét platform mögött erőteljes közösségek állnak. A WooCommerce-t a WordPress felhasználók tábora támogatja, míg a Magento dedikált közösséggel rendelkezik, akik folyamatosan fejlesztik, ellenőrzik a kódot és segítik egymást a keretrendszer újabb és újabb lehetőségeinek meglelésében, a létezőek kiterjesztésében vagy újak létrehozásában.

Hasznos ez azért is, mert egy egyszerű supportnál sokkal komolyabb segítséget kaphatunk. Ahelyett, hogy egy kézikönyvet lapozgató call centeres kollégával kellene beszélgetni, felhasználók ezreit tömörítő fórumokon kérdezhetünk, ahol egészen biztosan hasznos, első kézből származó, tapasztalatokra és szaktudásra épülő segítséget kaphatunk.

Ami még fontosabb, a termékek és a kommunikáció terén is bír közös jellemvonásokkal a két rendszer. Mind a két estben lehetőségünk van arra, hogy korlátlan számú terméket töltsünk fel és kezeljünk egy helyen, hogy blogot indítsunk az oldalon, ami tartalommarketinges szempontból igen előnyös és a SEO-t is segíti. A Magento-ban ehhez egy bővítmény telepítésére van szükség, míg WooCommerce-nek a WP miatt alapból része. (Bevett gyakori megoldás egyébként, hogy egy WooCommerce-plugin nélküli WordPress céges oldalba webáruház menüpontot illesztenek, ami például a webshop.encegem.hu domainre irányít – ami pedig egy Magento a céges oldalhoz illeszkedő dizájnnal.)

Látható, hogy a hasonlóságok elsősorban nagy vonalakban mutatkoznak meg, a lehetőségek terén – most azonban lássuk, miben különbözik egymástól a két rendszer.

 

Miben különbözik egymástól a Magento és a WooCommerce?

Használhatóság

Ha már eleve WordPress alapú oldalt használsz, és ugyanazon az oldalon akarod kialakítani a webboltodat, logikus, hogy a WooCommerce mellett tedd le a voksodat – a kezelése igen egyszerű, ha már hozzászoktál a WP-hez, és tisztességes mennyiségű oktatóvideó is rendelkezésre áll.

Ugyanakkor a Magento alapjai szintén könnyen kiismerhetőek. Temérdek oktatóvideó, alapos dokumentációs anyag és dedikált wiki oldal segít, hogy az első lépéseket megtedd, és még kezdő felhasználóként sem ütközöl majd komolyabb akadályokba, az adminisztrációs felület ugyanis rendkívül felhasználóbarát. A helyzet csak akkor kezd igazán bonyolódni, amikor kiegészítéseket kezdesz az oldalhoz adni, amelyek bővíthetik a rendszeren belüli lehetőségeid körét.

Költségek

Végül mindennek meg kell fizetni az árát, és ha egy olyan rendszert keresel, amelyet komoly üzleti használatra szánsz, és a bevételeidet alapozod rá, ez különösen igaz. Alapvetően mind a két rendszer ingyenes (a Magento esetében a Community Edition), költenünk akkor kell rájuk, ha bővíteni akarjuk a funkcionalitást. Mindkét esetben lehetőségünk van arra, hogy ingyenes és fizetős kiegészítőket telepítsünk, ebben nagy különbség nincs.

Ha külön fejlesztőt akarunk fogadni, a WooCommerce esetében talán könnyebben találunk ilyet, mivel WP alapú rendszerről van szó. A Magento fejlesztése biztosan drágább, de mivel robusztusabb rendszer, ezért egyedi fejlesztések telepítésekor sok helyen „eltörhet”. Ezért olyan céget kell választanod, ahol komoly minőségbiztosítással dolgoznak, többszörös teszteléssel. Komoly, összetett funkcionalitást a gyakran szűk határidők miatt érdemes akár több fejlesztővel készíttetni párhuzamosan, ehhez viszont komolyabb fejlesztői infrastruktúra kell, koordinált munka és dedikált, az ügyfelet képviselő projektmenedzser a fejlesztőcégen belül.

Bonyolultnak hangzik? Az is. Megéri? Minden bizonnyal.

A hosting tekintetében a Magentonak nagyobbak az igényei. A WooCommerce szimpla WP hostinggal is beéri (bár a több ezres termékszám egyidejűleg sok látogatóval azért bőven képes megakasztani), a Magento esetében viszont saját szerveren kell futtatnunk, de még inkább megéri, ha valamilyen felhőalapú rendszerre fizetünk be (amennyiben nemzetközi, vagy nagy terhelés várható, ezt ajánljuk) vagy dedikált szervert bérlünk. Ez azonban azt is jelenti, hogy nagyobb teljesítményt kapunk.

A Magento skálázhatósága révén óriási üzlethálózatokat is képes kezelni, egyszerre több webáruházat, ehhez pedig mindenképpen szükség van külön hosting szolgáltatásra – ez az ára annak, hogy minőségi szolgáltatást és magas színvonalú felhasználói élményt nyújthass.

Az, hogy egy e-kereskedelmi platform képes legyen (legalábbis elméletben) korlátlan számú terméket kezelni, virtuális bevásárlókosarat biztosítani, alapvető – ezt természetesen mind a két rendszer tudja. Fontos azonban az is, hogy mennyire tudod testre szabni a termékeket, az egész folyamatot – és ezen a ponton a Magento egyértelmű győztesként kerül ki az összehasonlításból.

A Magento rendszerében lehetőségünk van az upsell és cross-sell lehetőségeket bőségesen kiaknázni, az egyes termékek között összehasonlításokat végezhetünk és nagyon pontosan szűrhetünk arra, amire szükségünk van – a Magento egyik legcsábítóbb feature-je a szűkítő keresési feltételek megadásának lehetősége.

A WooCommerce-ben elsősorban az akciókra és kuponokra koncentráltak a fejlesztők, bár a szűkített keresés mára ebben a rendszerben is megjelent, a Magento azonban ennél sokkal komplexebb és sokoldalúbb lehetőségeket kínál.   És akkor még csak a felhasználói oldalról beszéltünk.

A „túloldalon”, vagyis az adminisztrációs felületen azok, akik szeretik a lehető legalaposabban testre szabni termékeiket, azok jellemzőit, a felhasználói tevékenység alapján az oldalon zajló történéseket – és ez nagyjából a kicsit is tapasztalt webáruház-üzemeltetők 100 százalékát jelenti – magukon kívül lesznek a gyönyörtől. Az adminisztrációs felületen ugyanis elképesztő mennyiségű beállításra nyílik lehetőségünk, többek között arra, hogy tökéletesen szabadon határozzuk meg az egyes kategóriákhoz, termékekhez tartozó attribútumokat.

A Magento-ban jellemzőcsoportokat határozhatsz meg (attribute sets),így például megadhatod, hogy az „autógumi” jellemzőcsoportnak van „átmérő” és „évszak” jellemzője, az évszak jellemző értékei közül pedig a felhasználó a szűkítő keresésben kiválaszthatja a téli, nyári, átmeneti opciókat. Erről bővebben itt olvashatsz.

A Magento e téren rendkívül rugalmas rendszer, ami óriási előnyére válik, hiszen mindegy, hogy porcelántányérokat, processzorokat vagy paprikát akarunk árulni: a rendszer könnyedén hozzáidomítható a termékhez.

Néhány szó az analitikáról

Ahhoz, hogy hatékony webáruházat üzemeltessünk, mindenképpen szükségünk lesz részletes statisztikai adatbázisokra. Mindkét rendszerben lehetőség van a Google Analytics integrációra (illetve a Magento esetében ennek kiterjesztésére is az Enhanced Ecommerce alkalmazással), így e tekintetben nem maradnak adósok, ez pedig önmagában bőséges adatmennyiséggel lát el minket ahhoz, hogy ennek megfelelően optimalizálhassuk oldalunkat.

A Magento ezen kívül saját maga is készít statisztikákat a legnézettebb, legkeresettebb, legtöbbet vásárolt termékekről. Többféle sales jelentés készíttethető vele gyárilag, amelyek .CSV formátumban exportálhatóak. A Magento esetében a funkciók szinte korlátlanul bővíthetőek, tekintve a keretrendszer rugalmasságát, és a Magento Connect adatbázisban több ezer kész kiegészítőt is találunk hozzá (rengeteget ingyenesen letölthetünk), telepítésükhöz azonban nem árt, ha a rendszer kezelésében tapasztalt szakember segítségét vesszük igénybe.

Ezzel együtt e kategóriában a Magento gyakorlatilag kiütéssel győz. A WooCommerce egyszerű WordPress pluginként kínál kiegészítéseket, amelyeket egyszerűbb kezelni, lehetőségeink azonban korlátozottabbak is. Nyilvánvaló, hogy egy az alapoktól e-kereskedelemre kihegyezett rendszer más súlycsoportot képvisel e téren, mint egy eredetileg általános célokra (blog, corporate oldal, hírportál stb.) fejlesztett motor, melyet később egészítettek ki egy e-commerce pluginnel. Utóbbi előnye viszont épp ezért a profi blogrendszer a Magentoval szemben – erről mindjárt bővebben olvashatsz.

Tény, hogy amennyiben kicsit is profibb webáruházat akarunk építeni, bőven megéri időt, energiát és pénzt is fektetni a Magento fejlesztésébe – nem véletlenül használják a keretrendszert olyan világmárkák is, mint a Nike, a Gant vagy a Samsung.

Dizájn

Reszponzivitás: Egy webáruháznak ma mindenekelőtt reszponzívnak kell lennie. Ha nem jelenik meg tökéletesen és könnyen használhatóan minden platformon a mobiloktól az asztali PC-kig, akkor a potenciális vásárlók jelentős hányadáról önként mondunk le.

A WooCommerce egyszerűen integrálható a WordPress-szel, így a reszponzivitás jellemzően nem jelent problémát. Számos különféle theme, vagyis előre elkészített téma érhető el hozzá. Ezek legtöbbje pénzbe kerül, az esetek többségében azonban ezek a profi sablonok még mindig olcsóbbak, mintha vázterveket, minden oldalra egyedi dizájnt, front end és back end fejlesztéseket készíttetnél a Magento-hoz. Ha még csak most indulsz az online piacon, befektetés szempontjából WooCommerce-szel jobban jársz – ha pedig már széttépnek a vásárlók, mert annyira nagy az igény, akkor lépj tovább Magentora.

Ekkor viszont már a kikristályosodott kereskedelmi modell és egy már bevezetett ügyviteli/számlázó/raktárkezelő rendszer létfontosságú, ezekkel kell majd összekötnöd Magento áruházadat. A Magento 2014 óta (v1.9) teljesen reszponzívnak tekinthető, és hatalmas mennyiségű ingyenes megjelenést tölthetünk le, ezen belül pedig szabadon alakíthatjuk az oldal megjelenését.

Tartalomkezelés

A Magento kifejezetten egy e-kereskedelmi célokra fejlesztett rendszer, így komplex igények esetén sokkal jobban teljesít, mint a WooCommerce, hiszen a WordPress a tartalomszolgáltatásra, portfolió-bemutatásra, corporate oldalak létrehozására és hírszolgáltatásra van kihegyezve. Alapvető funkciókra a Magento rendszerén belül is találhatunk, blogot indíthatunk az oldalon, a tartalommenedzsment azonban valamivel nehézkesebb.

Persze olyasmit nem nagyon találunk, amit bármelyik rendszer ne volna képes valamilyen módon elvégezni – minden azon múlik, milyen beállításokat alkalmazunk, hogyan alakítjuk ki saját rendszerünket, milyen kiegészítőket telepítünk. Ha hírlevelet küldenénk, akkor sem a Magento a jó választás. Annak idején a fejlesztők úgy döntöttek, integrálnak egy alapvető funkciókat ellátni képes megoldást, ezen túl azonban nem sokra megyünk vele.

Léteznek szegmentálásra képes bővítmények, de még mindig érdemesebb valamelyik komolyabb hírlevélküldő szolgáltatást választani e célra, mint például a MailChimp vagy a Getresponse, hazánkban pedig a Mailmaster vagy a Webgalamb.

Biztonság

Egy közelmúltban végzett tanulmány szerint a világhálón 39 másodpercenként történik egy hackertámadás, ami azt jelenti, hogy napi szinten több mint, 30 000 webhelyet próbálnak meg illetéktelenek feltörni. Ennek tükrében egy webáruház biztonságának megőrzése minden áruháztulajdonos számára komoly kihívást jelentő és létfontosságú feladat. Mivel egy e-kereskedelmi webhely sok ügyfél-információt és fizetési részleteket tartalmaz, az optimális biztonságnak minden esetben prioritást kell élveznie.

A WooCommerce kiváló lehetőséget nyújt egy kezdő szintű áruház számára, és különböző pluginek formájában több, az online biztonság szempontjából fontos funkciót is tartalmaz. A WooCommerce-hez képest azonban a Magento erősebb biztonságot nyújt, ami főként a gyakran megjelenő biztonsági javításoknak és frissítéseknek köszönhető.

A Magento olyan kiegészítőket tartalmaz, melyek önmagukban is tökéletes segítséget nyújtanak a webhely monitorozásában, a rosszindulatú programok által okozott károk megfékezésében és javításában, valamint a jogosulatlan hozzáférések megakadályozásában. Sőt, a legjobb, hogy könnyedén adhatunk hozzá olyan biztonsági bővítményeket, melyek hozzájárulnak az online áruházunk maximális védelméhez.

Ez az oka annak, hogy a biztonsági szempontból Magento egyértelműen győzedelmeskedik a WooCommerce felett.

Melyiket „szokás” választani?

A Magentot gyakrabban választják nagyvállalatok és olyan cégek, amelyek ügyfeleik webáruházait kezelik, ezeket pedig ügyviteli rendszerhez csatolják a számlázás, készletfrissítés menedzselése végett. Ideális megoldás ugyanis azok számára, akik nagyban gondolkodnak, nagyot álmodnak, de azoknak is, akik már rendelkeznek egy jó menő webáruházzal, csak éppen többre vágynak, mint amit a rendszer nyújtani képes.

A WooCommerce inkább a kisvállalkozások körében népszerű, akik már hozzászoktak a WordPresshez. Igen fontos szempont, hogy a Magento kifejezetten e-kereskedelmi célokra készült. Nem csak a WordPress kiegészítése, hanem egy komplett keretrendszer, amelyen belül alig túlozva bármit megoldhatunk, amire csak szükségünk van.

Nézzük a számokat!

A 2020 elején publikált hivatalos statisztikák szerint a Magento felhasználóinak száma nem kevesebb, mint háromszoros növekedést mutatott, ami azt jelenti, hogy jelenleg a teljes internet 1,2 %-át Magento alapú webáruházak teszik ki. Ez valamivel több, mint 250.000 oldalt jelent, és az összes feltérképezett webshop 12%-át teszi ki.

Érdemes megnézni azt is, hogy az Alexa korábbi adatai szerinti legnagyobb látogatottsági statisztikákkal bíró egymillió oldal között hogyan oszlanak meg a két rendszer felhasználói.

Az adatok azt mutatják, hogy a Magento felhasználóinak oroszlánrésze a 100-300 ezredik helyek közötti oldalak szegmensében található, míg a WooCommerce használói inkább a 900 ezres helyezések birtokosai. Ebből túlságosan messzemenő következtetéseket levonni botorság volna, annyi azonban biztos, hogy a Magentot használó oldalak általánosságban népszerűbbek.

A legérdekesebb talán a termékkategóriák szerinti megoszlás. Míg a WooCommerce-t leggyakrabban szoftverek és információs anyagok, illetve konzultációs szolgáltatások, valamint élelmiszerek értékesítésére használják, a Magento esetében a felhasználók legnagyobb arányban ruhák és kiegészítők, bútorok, illetve ékszerek és ajándéktárgyak értékesítésével foglalkoznak. A WooCommerce webboltokban általában nem anyagi javakat, hanem szellemi termékeket értékesítenek, a kézzelfogható termékek eladására a Magento népszerűbb platformnak számít.

Szóval, melyik a jobb? A Magento vagy a WooCommerce?

Ezt egyértelműen nem jelenthetjük ki, mind a két rendszer más célcsoport számára lehet ideális. Annak azonban, aki egy komolyabb webáruházat akar felépíteni, egyértelmű a választás.

Mit tud a Magento?

Évek óta a piac egyik legerősebb, egyik legnépszerűbb self-hosted szereplője, melyet kifejezetten e-kereskedelmi keretrendszernek fejlesztettek. Funkciókban és lehetőségekben gazdag, megfelelő infrastruktúrával megtámogatva gyors, akár egyszerre több webáruházat futtatva is (mert erre is képes), jól keresőoptimalizálható.

Könnyen honosítható, a pénznemek állíthatóak, így nemzetközi értékesítésre is kiváló. Viszont komplex megoldás, kezelésének elsajátítása, hogy teljes potenciálját kiaknázhassuk, hosszabb időbe telhet.

Mit tud a WooCommerce?

Létező WordPress oldalakba remekül integrálható kiegészítő lehetőség, könnyen kezelhető. Funkciók terén szűkösebben áll, egy kisebb, kevésbé komplex üzleti folyamatokat megvalósító webshop számára azonban megfelelő megoldás.

Ez utóbbi megoldás inkább a kezdők számára megfelelő, akik csak néhány terméket akarnak egy kisebb célközönségnek eladni. Aki viszont növekedésre, fejlődésre számít, aki egyszerre több boltot üzemeltetne, több száz vagy akár több ezer termékkel, és teljesen szabadon akarja alakítani webáruházát, annak a Magento garantálja a sikert.

Bármilyen kérdésed merül fel a cikkel vagy a fent említett keretrendszerekkel kapcsolatban, írd meg kommentben és válaszolunk!

 

Magento ERP integráció: így készítsd elő hibák nélkül a folyamatot

A rendszer-integráció bonyolult és összetett folyamat, melynek kulcsfontosságú, kritikus részei a következők:

  • A) az ERP szoftver
  • B) az e-kereskedelmi platform
  • C) a közöttük felépülő adatáramlási séma
  • D) az adatkapcsolat implementációja

Cikkünkben a rendszer-integráció szempontjából a Magento e-kereskedelmi rendszert fogjuk megvizsgálni, amely véleményünk szerint a kis- és középvállalkozások számára az egyik legmegfelelőbb e-kereskedelmi megoldást jelenti. Ezt az alábbiakban számos érvvel igyekszünk majd alátámasztani.

Ami az ERP (Enterprise Resource Planning – Vállalatirányítási információs rendszer) oldalát illeti, itt a megítélés szempontjából az e-kereskedelmi rendszerhez való integrálhatóság csak egy szempont a sok közül. De alapvető elvárásnak tekinthető egy aktívan fejlesztett, moduláris, bővíthető ERP rendszer, amely igazodik a vállalkozás igényeihez és anyagi lehetőségihez, és amely támogatja a más rendszerekkel, különösen az e-kereskedelemmel való integrációt.

Külön előny, ha az ERP szoftver megfelelően dokumentált, bővíthető API-val rendelkezik.

Az alábbiakban alapvetően a következő kérdést igyekszünk körüljárni: Milyen folyamatokat, hogyan lehet és érdemes szinkronizálni a Magento és egy ERP rendszer között?

A következő témákat fogjuk érinteni:

  • Üzleti szempont – az e-kereskedelem szerepe a vállalkozásban
  1. Integráció – Miért érdemes?
  2. Központi vezérlés
  3. Méretbeli szempontok
  4. A növekedés hatásai – egyre inkább középpontban az ERP
  • A webáruház-dilemma – miért a Magento?
  1. Számtalan funkció és beállítási lehetőség
  2. API (Application Programming Interface)
  3. Kulcsra kész integrációs megoldások
  4. Magento 2 és ERP
  • Az ERP-oldal
  1. ERP – mit takar a rejtélyes három betű?
  2. ERP: belső folyamatok összehangolása
  3. A rugalmasság ára
  4. Felhő vagy saját szerver? – Hogyan válasszunk vállalatirányítási rendszert?
  5. API és ERP
  • Az Integráció
  1. Elmélet: Adatfolyam-modell
  2. Gyakorlat: Megvalósítási lehetőségek
  3. Hogyan válasszunk?
  • Mit kérdezzünk egy rendszerintegrátortól?
  1. Megbízhatóság: Hogyan garantált az integráció megbízhatósága?

Üzleti szempont – az e-kereskedelem szerepe a vállalkozásban

Integráció – Miért érdemes?

Mérettől függetlenül minden vállalkozásnál, akár egy mellékállásban üzemeltetett webshopnál is, előbb-utóbb felmerül az igény arra, hogy optimalizáljuk és automatizáljuk a monoton, ismétlődő munkafolyamatokat. Ezzel időt és pénzt takarítunk meg, csökkentjük a hibázás lehetőségét, megsokszorozzuk a képességeinket és sok fejfájástól kímélhetjük meg magunkat és kollegáinkat egyaránt.

Amikor a napi feladatok egyre több időt vesznek igénybe, eljött az ideje annak, hogy egyszerűsítsük őket. Az automatizálásra a legjobb megoldást pedig az ERP rendszerek jelentik. Ez az egyik ok, amiért célszerű az általunk használt megoldásokat és munkafolyamatokat integrálni.

A különböző rendszerek különféle feladatokra vannak optimalizálva, erőforrás-kezelési célokra valók az ERP-k, kapcsolatkezelésre a CRM-ek, e-mail küldésre az e-mail marketing szoftverek. Ha mindenből a legjobbat szeretnénk használni, nincs más választásunk, mint integrálni.

Az integráció óriási előnye, hogy csak egyszer, egy helyen kell egy feladatot elvégezni, és munkánk eredménye a többi kapcsolt rendszerbe automatikusan átkerül.

Az integrációval szemben persze alapvető követelmény, hogy minden zökkenőmentesen és automatikusan működjön. Talán említenünk sem kell, hogy kevéssé hasznos az integráció abban az esetben, ha több problémával jár, mintha az integrálandó feladatokat külön-külön végeznénk el.

Központi vezérlés

A leghatékonyabb megoldás tehát dedikált rendszereket alkalmazni úgy, hogy csak egyetlen központi helyen kelljen egy-egy feladatot elvégezni vagy adatokat kezelni. Bárhol is keletkezzenek például a rendelések, online vagy offline, legjobb, ha mindig az ERP-ben kezeljük őket.

Ugyanígy, ha a termékeket már egyszer importáltuk, beáraztuk, konfiguráltuk az ERP rendszerünkben, bizonyára nem szeretnénk ugyanezt még egyszer megtenni a webáruházunkban.

Mindig lehet persze kompromisszumokat kötni, például a termékeket kötegelve importálni az ERP-be majd hasonlóképpen a webáruházba, és utána csak a raktárkészletet szinkronizálni az ERP-ből.

De ahhoz, hogy megfelelő következtetésekre jussunk, elméletben és gyakorlatban is koncentráljunk most csak az ideális működésre, és tekintsünk el az esetleges implementációs nehézségektől, várható költségektől és technikai problémáktól.

Méretbeli szempontok

 

Könnyű belátni, hogy minél nagyobb egy cég e-kereskedelmen kívüli része, annál több dolgot célszerű elvégezni az ERP rendszerben és az így keletkezett adatokat szinkronizálni a Webáruházban. Ugyanakkor minél kisebb egy vállalkozás nem e-kereskedelemmel foglalkozó része, annál kevesebb dolgot érdemes a Magenton kívül kezelni.

A Magento ugyanis már eleve rendelkezik alapvető ERP funkciókkal: készletkezeléssel, bizonyos országokban hivatalosan is elfogadott számlázási megoldással, és szállításkezeléssel.

Ha például egy, csupán néhány terméket árusító kezdő vállalkozás először praktikusan csak a számlázási rendszerét szeretné integrálni, elég a megrendeléseket leszinkronizálni a webshopból és minden mást továbbra is kényelmesen lehet a Magenton belül intézni.

Egy több raktárral és áruházzal rendelkező üzletlánc vagy egy globálisan szállító nagykereskedő viszont adott esetben gyorsan változó raktárkészletét, árazási, számlázási és szállítási adatokat és üzleti folyamatait eleve a maga ERP rendszerben kezeli. Így elengedhetetlen, hogy az e-kereskedelmi megoldása teljes körűen integrálódjon ahhoz.

Fontos tehát, hogy adott esetben még arra se legyen szükség, hogy be kelljen lépni az integrált webáruház admin felületére, kivéve esetleg, ha a webshop felhasználói felületet, online ajánlórendszer beállításait kell módosítani.

Az ERP szempontjából ugyanez vonatkozik a webshop mellett minden más integrált rendszerre: CRM, BI, e-kereskedelmi marketing, 3PL stb. Minél szerteágazóbb egy kereskedő tevékenysége, annál kevésbé praktikus ezeket a rendszereket — tulajdonképpen áttételesen — az e-kereskedelmi platformmal összekötni, és annál ésszerűbb őket szinkronizálási szempontból az ERP köré építeni, ahol az adatokat tulajdonképpen kezeljük.

A növekedés hatásai – egyre inkább középpontban az ERP

Az e-kereskedelmi integráció, illetve az integráció aranyszabálya az arra való törekvés, hogy egy műveletet a legalkalmasabb, központi helyen végezzünk el, és a változásokat ebből a forrásból terjesszük el a többi kapcsolódó rendszerbe. Éppen ezért az ERP rendszerek egyre inkább középpontba kerülnek az üzleti életben, és egyre több vállalkozás dönt úgy, hogy szerteágazó munkafolyamatait egyetlen rendszerben integrálja.

A webáruház-dilemma – miért a Magento?

Számtalan funkció és beállítási lehetőség

A Magento-t a kezdetektől fogva arra tervezték, hogy a maximumot nyújtsa, mint dedikált e-kereskedelmi platform. A nyílt forráskód, a számtalan termékbeállítási lehetőség, vásárlói csoportok, árszabályok, a szűkítő keresés, fizetési és szállítási integrációk, importálási és exportálási lehetőségek egyedivé teszik a piacon.

A Magento ERP integrációja egyaránt lehetőséget biztosít az adminisztratív és működési költségek csökkentésére, valamint az üzleti produktivitás javítására.

API (Application Programming Interface)

Az API, azaz alkalmazásprogramozási felület nem más, mint egy program vagy rendszerprogram azon eljárásainak és az eljárások használatának dokumentációja, amelyet más programok felhasználhatnak. Egy nyilvános API segítségével lehetséges egy programrendszer szolgáltatásait anélkül használni, hogy annak belső működését ismernünk kellene.

A Magento talán legkiemelkedőbb előnye, hogy fejlett API-kat tartalmaz, melyek a legtöbb beépített funkcióhoz hozzáférést nyújtanak.

Technikai szempontból a Magento a következő API-kkal rendelkezik: SOAP API v1, v2, XML-RPC, REST és XMLConnect mobil alkalmazásokhoz. A Magento API-k jól dokumentáltak, amellett az integráció szempontjából óriási előnyük, hogy bővíthető, moduláris felépítésűek.

Az egyszerű integráció megvalósításához kevés PHP ismeret is elegendő, szükséges azonban tisztában lennünk az API-k működésével.

Kulcsra kész integrációs megoldások

Végül, de nem utolsó sorban, a Magento számtalan rendszerhez már eleve integrálva van. A piacon több tucatnyi kulcsra kész integráció közül választhatunk, köztük az olyan vállalati szintű rendszerekkel, mint a SAP, Microsoft NAV, Sage, NetSuite stb.

A Magento számlázó programokkal, ERP szoftverekkel, CRM rendszerekkel, vagy épp banki szoftverekkel is hatékonyan összeköthető. Segítségével minden fontos adat, a készletinformáció egyszerűen kezelhető. Infrastruktúrájának követelményei azonban igen magasak, hiszen egy egyszerű webshophoz képest sokkal többre képes.

Magento 2 és ERP

Többen érdeklődtek már afelől, hogy a Magento 1.x verziók támogatásának megszűnésével továbbra is megoldható lesz-e a Magento integrálása ERP rendszerekkel. A válasz természetesen az, hogy igen.

A Magento 2, csakúgy, ahogyan a korábbi verziók, problémamentesen integrálhatók a különböző ERP megoldásokkal, ehhez pedig nincs szükség másra, mint a megfelelő Magento integrációs kiegészítő, vagy köztes rendszer használatára.

Az ERP-oldal

ERP – mit takar a rejtélyes három betű?

Ha már valaki idáig eljutott az olvasásban, feltételezhetően van némi fogalma az ERP rendszerek működéséről. Röviden szeretnénk azonban összefoglalni, mit is takar egészen pontosan ez a három, rejtélyes betű.

Az ERP (ERP system) egy angol betűszó, ami az Enterprise Resource Planning kifejezés rövidítése. A magyar nyelvben a tükörfordítástól eltérően, vállalatirányítási rendszerként használjuk.

Az ERP tulajdonképpen nem más, mint egy integrált üzleti folyamatokat kezelő szoftver, avagy sokkal inkább egy teljes módszertan. Olyan szoftveres megoldás, ami optimális esetben lehetővé teszi a rögzített szervezeti adatok valós idejű kezelését.

Az ERP szoftverek funkciói jellemzően több szervezeti egység tevékenységére is kiterjednek. Az ERP rendszerek lényege, hogy az egyes területeken keletkező adatok gyűjtését, tárolását, kezelését, valamint feldolgozását összvállalati, vagy vállalatcsoporti szinten is lehetővé tegyék.

Az ERP rendszer használata tehát egységesíti számítógépes rendszerünket, ezzel pedig segít abban, hogy minden esetben aktuális képet kapjunk cégünk azon folyamatairól, amelyeket közös adatbázisban tárolunk.

ERP, a belső folyamatok összehangolása

Az ERP rendszereket alapvetően olyan üzleti folyamatok összekapcsolására és egységes kezelésére fejlesztették ki, mint a pénzügyek, fizetési műveletek, számvitel, számlázás, gyártás, emberi erőforrások, munkafolyamat-kezelés, minőség-ellenőrzés, beszerzés, ellátási lánc irányítás, raktározás, raktárkészlet-kezelés, ügyfélkapcsolat-kezelés stb..

Az ERP rendszerek, azáltal, hogy felszámolják a sziget-szerű számítógépes rendszereket, összekötik az adatokat és a folyamatokat, javítják a munka minőségét, hatékonyságát, megkönnyítik a kollaborációt, a monitorozást és döntéshozást a vállalaton belül.

Az ERP rendszerek használatának legfőbb előnyei:

  • hatékonyabban nyomon követhető folyamatok
  • egyszerűbben összehangolható, belső döntések
  • komplex folyamatok egyszerűsödése
  • gyorsabb reakció a változásokra
  • működési költség csökkenése
  • produktivitás látható növekedése
  • nagyobb biztonság

A rugalmasság ára

Fontos, hogy nem létezik olyan megoldás, mely egységesen, bármilyen szervezet működéséhez alkalmazható lenne. Az ERP rendszereket mindig az adott cég igényeire kell szabni, illetve konfigurálni, így a rugalmasság minden igazi ERP génjeibe van kódolva.

Minél rugalmasabb és minél inkább testre szabott azonban egy ERP, annál nehezebb egy másik rendszerrel összekötni.

Különösen igaz ez akkor, ha a másik rendszer is olyan összetett, mint amilyen a Magento, és a rendszerek összekötésénél a belső folyamatok sajátságaira is tekintettel kell lenni.

Összességében elmondható tehát, hogy egy ERP rendszer bevezetése és integrálása hosszú folyamat, azonban a befektetett idő hosszabb távon mindenképp megtérül.

Felhő vagy saját szerver? – Hogyan válasszunk vállalatirányítási rendszert?

A megfelelő ERP rendszer kiválasztása nem egyszerű feladat. Jóval többről van ugyanis szó, mint egy egyszerű, informatikai befektetésről. Mint ahogyan azt korábban is említettük, az ERP egy stratégiai eszköz, mely vállalatunk teljes működését befolyásolhatja. Éppen ezért fontos, hogy megfelelő körültekintéssel válasszuk meg a számunkra megfelelő rendszert.

Napjainkban fénykorukat élik a különféle felhőalapú szolgáltatások, és nincs ez másként az ERP-k világában sem. A felhő alapú szolgáltatások számos nyilvánvaló előnnyel rendelkeznek, melyek közül a legfontosabbak a gyors telepíthetőség, alacsonyabb működtetési összköltség, megbízhatóság, nyílt, átlátható frissítések és fejlett API-interfész. És fontos természetesen az is, hogy felhőben tárolt adatainkat bármikor, bárhonnan elérhetjük és kezelehetjük.

Mindez a felhőalapú ERP rendszereket igen versenyképessé teszik a középvállalatok körében.

A felhőalapú szolgáltatók különös figyelmet fordítanak arra, hogy rugalmas API-felületet biztosítsanak ügyfeleiknek; funkcionális API nélkül nehéz egy felhőalapú szolgáltatást elképzelni, ami remek alapja lehet az e-kereskedelmi integrációnak is.

A saját szerverre telepített ERP-k, közép- és nagyvállalatok számára viszont igen nagy szabadságot, jobb irányítási lehetőséget, adatbiztonságot kínálnak, valamint az egyedi igények átfogóbb kiszolgálását nyújtják a kereskedőnek. A saját szerveren a cégek általában nagyobb biztonságban érzik az adataikat, ám ennek alapvetően a magasabb üzemeltetési költség és a kezelésre fordított munkaórák magasabb száma jelenti az árát.

Létezik azonban egy harmadik, úgynevezett hibrid megoldás is, amely egyesíti a felhő és a helyszíni ERP tulajdonságait. Ez azt jelenti, hogy néhány ERP-alkalmazást a felhőben, míg másokat helyben futtathatunk.

Egy kisebb vállalkozásnak tökéletesen megfelelő lehet egy kompakt ERP rendszer is, hozzá tartozó támogatással akár az irodai számítógépeken, akár közeli adatközpontban üzemeltetve. Az e-kereskedelmi integrációhoz ilyen esetben azonban valószínűleg erősen egyénre szabott megoldásra van szükség.

API és ERP

Az ERP rendszerek egyik történelmi hiányossága, hogy mivel kifejlesztésükkor az elsődleges szempont a belső modulok integrációja volt, a külső rendszerekkel való szabványos kapcsolódás kérdése gyakran csak a második fázisban került elő.

Ez a trend gyorsan változik, és a napjainkban széles körben alkalmazott felhőalapú szolgáltatások világában a fejlesztő cégek egyre inkább felismerik a teljes körű összekapcsolhatóság értékét.

A teljes körű integrálhatóság jól dokumentált, robosztus, teljesítmény-optimalizált API-t jelent, mely a rendszer funkciónak egészét lefedi. Az API-k két fő működést valósítanak meg:

  • üzleti logika, amely az ellenőrzött adatcserén keresztül lehetővé teszi a belső folyamatok elérését,
  • standard és dokumentált interfész, amely az üzleti logikára épül.

Mindkettő igen lényeges. A régebbi  ERP rendszerek közül sok csupán adatbázis vagy fájl/dokumentum alapú elérést tesz lehetővé, így ha ilyen rendszereket kell integrálni, maga az adatkapcsolat megvalósítása is nagy kihívást jelenthet.

Néhány ERP saját, integrált webshop modult is tartalmaz. Amennyiben az integrációt valamilyen jól dokumentált API felület segítségével alakították ki, akár az ERP, akár az e-kereskedelmi oldalán, lehetőség nyílhat a beépített webshopot az eredeti API felület megtartása mellett jobbra cserélni.

Az Integráció

Amint megtaláltuk céljainknak megfelelő ERP rendszert és e-kereskedelmi platformot, nincs más hátra, mint összekötni őket.

Itt szeretnénk azért megjegyezni, hogy amikor akár technológiaváltás vagy új üzletág bevezetése miatt új ERP-t (vagy webshopot) keresünk, érdemes előre meggyőződni arról, hogy a rendszerek megfelelően összekapcsolhatók egy hozzáértő partner és alkalmas technológia segítségével.

Elmélet: Adatfolyam-modell

Az ERP-webáruház integrációról, illetve általában a rendszerintegrációról szólva érdemes áttekinteni néhány tervezési szempontot.

  • Adatáramlás – forrás és cél

Ez az adatfolyam-modellezés legkönnyebben megérthető, legáltalánosabb szintje. Az egyik rendszerben keletkezett vagy frissített adatot át akarjuk vinni egy másik rendszerbe. Ezen a szinten mellékes, hogyan végezzük ezt el, van-e különbség az adatformátumban, mellékesek az adatátviteli csatornák, csak annyit tudunk, hogy szükségünk van a műveletre. Ilyen például, hogy ha egy termékjellemző frissül az ERP-ben, akkor ezt a változást át akarjuk vinni a webshopba is.

  • Időzítés – mekkora késés elfogadható?

Miután megterveztük az adatáramlási sémát, vagyis hogy mikor milyen adatokat akarunk A-ból B-be, ill. B-ből A-ba szinkronizálni, fontos felmérni, hol van szükség azonnali – vagy inkább minimális késéssel megvalósított – frissítésre és hol tolerálhatók nagyobb késések.

Néhány rendszerben például a termékkészlet nagyon sűrűn változik; ilyenkor gyakran elvárás, hogy a készletadatok a webshopban is minél frissebbek legyenek. A legoptimálisabb megoldás ilyenkor, ha az a rendszer kezdeményezi közvetlenül a frissítést, ahol a változtatás történik, de bizonyos esetekben az is elfogadható alternatíva, ha a céloldali rendszer gyakori státuszellenőrzéseket végez.

  • Szinkron vagy aszinkron

Az időzítés egy másik szempontja a szinkronicitás. Egy rendszeren belül két művelet szinkron folyamat, ha a rendszernek várnia kell egy hívás – akár helyi, akár pedig távoli hívás, pl. adatátvitel – eredményére vagy befejezésére ahhoz, hogy a következő műveletet elvégezhesse.

Az aszinkron I/O esetében a rendszer tétlen várakozás helyett valami más, hasznos dolgot végezhet, és csak akkor tér vissza az eredeti művelethez, mikor a hívás befejeződött. A blokkoló jellegű függőség bizonyos hívások közt olykor elkerülhetetlen, de az adatáramlási sémában, amikor csak lehetséges, érdemes kiiktatni ezeket a szekvenciális függőségeket, és az adatáramlást alapvetően aszinkronná tenni.

Megfelelően alkalmazva az aszinkron folyamatok sokkal hatékonyabban működnek, és kevésbé hajlamosak szűk keresztmetszeteket, „adatforgalmi dugókat” előidézni. A hibatűrés fokozása és a robosztusság érdekében azonban még az aszinkron folyamatok esetén is ajánlatos a hívások sikeréről visszajelzéseket gyűjteni és azokat monitorozni.

  • Tranzakciós adatok

Bizonyos esetekben az a cél, hogy egy sor művelet két vagy több rendszerben egyaránt végbemenjen, vagy épp ellenkezőleg, ne menjen végbe egyik rendszerben sem. Az egyik legtriviálisabb példa erre az átutálási tranzakció.

Az átutalandó összeget az egyik helyen a számláról le kell vonni, közben a másik helyen a számla összegéhez hozzá kell adni. Ha ezt bármi megakadályozza, akár a folyamat közepén is, az eredeti állapot vissza kell állítani mindkét helyen.

Egy másik, az e-kereskedelemre jellemző példa a rendeléslétrehozás. Gondoljunk egy webshopra, mely engedményes árú termékeket árul nagyon alacsony készlettel egy olyan raktárból, amely offline rendeléseket is kiszolgál.

Ebben az esetben jogos elvárás lehet, hogy a webshopon kezdeményezett rendelés, ha a raktár aktuális készletadatai lehetővé teszik, egyszerre jöjjön létre az ERP rendszerben és a webshopban, vagy ellenkező esetben ne jöjjön létre egyik rendszerben sem, miközben hibaüzenet tájékoztatja a vevőt a webshopban arról, hogy az adott termék a kívánt mennyiségben már nem áll rendelkezésre.

Gyakorlat: Megvalósítási lehetőségek

Az eddigiekben átvettük az integráció magas szintű struktúráját, megértettük, mi az adatforrás célja, az időzítés lényege, mit takar a szinkronizálás és aszinkronizálás folyamata és mit kell tudni a tranzakciókról. Eljött az ideje, hogy megnézzük, hogyan alkalmazzuk ezeket a gyakorlatban.

  • Szerver-kliens API

Az adatcsere egyik kulcsfontosságú eleme a szerver-kliens modell, amelyben a kliens oldal kezdeményezi a kommunikációt, aktívan küld, illetve kér le adatokat, vagy parancsot továbbít, míg a kiszolgáló (szerver), ahogy a neve is mutatja, kiszolgálja a kéréseket, adatokat dolgoz fel, ad vissza, vagy feladatokat hajt végre.

A kliens valamilyen csatornán keresztül meghívja a szervert, az pedig feldolgozza a hívást, ideális esetben azonnali választ küldve visszajelzésként. Mindez a kérés/válasz paradigmára épül, amely lehetővé teszi a két vagy több rendszer közti aktív, egyidejű kommunikációt.

Ez a modell ideális olyan aszinkron folyamatok kezelésére is, melyek során a működés sikerességére vonatkozó visszajelzésre van szükség. Egy szerver/kliens felépítés könnyen tudja kezelni a több klienses párhuzamos kapcsolatokat, tehát jól skálázható.

  • Fájlátvitel és adat-közzététel

Ez tulajdonképpen egy protokoll nélküli adatátvitel, melynek során az egyik fél szimplán elérhetővé teszi az adatokat a másik fél számára egyszerű dokumentumként. Ennek leghétköznapibb formája, ha közzétesszük az adatot letölthető formában az interneten, vagy egy FTP szerveren, illetve ha FTP-n keresztül feltöltjük a célszerverre.

Egyszerűségének köszönhetően ez a modell jól működhet olyan körülmények között, ahol a fogadó fél megbízik az adatforrásban, tehát nincs szükség bonyolult hozzáférés-kezelésre, formátum-ellenőrzésre, vagy közvetlen visszajelzésre.

Bár ez a módszer messze nem mondható kifinomultnak és rugalmasnak, tökéletesen illik az adatszolgáltató/fogyasztó paradigma egyirányú információáramlásához, és még ma is rendkívül elterjedt – különösen a termékadatok átvitelében. Ami az átvitt adatokat illeti, természetük szerint aszinkron adatokról van szó, ugyanakkor maga a dokumentum-átadás és -feldolgozás kontrollálható, szabályozható, sorosítható.

Ez a fajta kommunikáció mind a küldő, mind a fogadó fél részéről aktivitást kíván. A küldő félnek aktívan publikálni kell a dokumentumokat, míg a fogadónak aktívan befogadni és feldolgozni. Mindez általában egyedi fejlesztést kíván a fogadó fél oldalán.

  • Közvetlen adatbázis-kapcsolat

A közvetlen adatbázis-kapcsolat hatékony szinkronizálási módszer, a legtöbb esetben azonban sok hibalehetőséget rejt és veszélyes, mivel megkerüli az adatbázis köré épített üzleti logikát.

  • Köztes rendszerek

Külön modell un. köztes rendszerek használata a kommunikációban: ilyenkor az összekapcsolt rendszerek közé beékelődik egy harmadik, mely menedzseli, optimalizálja, naplózza, monitorozza az adatcserét, egymásba alakítja különböző adatformátumokat, vagy akár gyorsítótáraz bizonyos adatokat. Ez a köztes réteg nemcsak két rendszer csatlakozási pontja lehet, hanem alrendszerek egész infrastruktúrájának mindent mindennel összekötő csomópontja.

Ezeket a közbenső szoftvereket gyakran nevezik Vállalati Szolgáltatás Buszoknak (ESB).

Az ilyen szolgáltatási csomópontokra jó példája a Zapier, mely kliensként számtalan különböző rendszer API-jához képes csatlakozni, a forrásrendszerből érkező bemeneti adatokat átalakítja a célrendszer formátumává, és mindezt felhőalapú szolgáltatásként kínálja.

A legizgalmasabb ebben a módszerben, hogy a köztes rendszerben egy bizonyos külső szoftver API-jához csatlakozó klienst csak egyszer kell lefejleszteni, amikor legközelebb egy másik külső rendszert kell illeszteni az eredeti rendszerhez, csak megfelelően le kell képezni közöttük az adatokat.

A köztes rendszert természetesen ki lehet egészíteni saját szerver-végpontokkal illetve  API-val annak érdekében, hogy kívülről aktívan elérhető legyen.

Ugyanennek az elvnek még fejlettebb változata, amikor a bemeneti adatokat egy univerzális belső formátumra fordítják le az API kliensek köré épített kiegészítő rétegben. Ebben az esetben az adatcsomópont különböző szerver/kliens végpontjai ugyanazt a nyelvet beszélik és nincs szükség a rendszeren belül két pont közti közvetlen átalakításra. Az adatokat ilyenkor mindössze megfelelően kell irányítani a különböző végpontok között. Ez persze erősen idealizált modell, de a komplex adathálózatok népszerű irányzata napjainkban.

Ma már több rendszerintegrátor kihasználja a köztes rendszerek valamilyen formáinak előnyeit; különösen igaz ez azokra az integrátorokra, melyek többféle ERP-t kapcsolnak  össze többféle e-kereskedelmi platformmal, hiszen az egyes rendszerek közt külön-külön lefejlesztett közvetlen integráció többszörös erőfeszítést, potenciális problémákat és költségeket jelent.

  • Közvetlen integráció vagy köztes rendszer

A ponttól pontig integráció azt jelenti, hogy két rendszer közvetlenül kapcsolódik egymáshoz. A P2P kapcsolat szerver-kliens szempontból sokféle lehet. Vannak bizonyos esetek, amelyekben az ERP kapcsolódik kliensként az e-kereskedelmi platformhoz, más esetekben mindez fordítva történik, és vannak helyzetek, amikor ezek kombinációja valósul meg. Előfordul, hogy az API-kat menet közben, kimondottan a P2P integráció kedvéért építik egyik vagy mindkét végponton.

P2P integráció esetén általában nagyobb a lehetőség a tervezésre és a testreszabásra, és a konkrét üzleti igények szabják meg a fejlesztés irányát.

Hogyan válasszunk?

Integráció során a legfontosabb szempont, hogy a rendszer maradéktalanul kielégítse az üzleti igényeket. A megfelelő adatfolyam-modell és a megvalósított funkciók a legfontosabb tényezők közé tartoznak, de az integrátortól, a választott technológiától és az alkalmazott  technológiát függetlenül egyéb szempontok is rendkívül fontosak lehetnek.

A konkrét technológia vagy technológiák, illetve a rendszerintegrátor kiválasztásakor a megbízhatóság és a célszerűség az elsődleges szempont, miközben meg kell találni az egészséges egyensúlyt költségek, a teljesítmény, a skálázhatóság, a támogatás minősége és egyéb tényezők között. A megrendelő és a rendszerintegrátor közös felelőssége tisztázni a prioritásokat és megérteni a kritikus pontokat.

Az alábbi dolgokat mindenesetre érdemes számba venni, mielőtt belekezdenénk a folyamatba:

  • Kis- vagy nagyvállalkozás vagyunk?
  • Mi az integráció fő célja?
  • Milyen megrendelési mennyiségre számítunk a jövőben?
  • Hány beszállítóval dolgozunk együtt?
  • Mennyire bonyolult az általunk használt rendszerek összetettsége?
  • Mik azok a munkafolyamatok, melyek rendszerünk gyengepontját jelentik?

Mit kérdezzünk egy rendszerintegrátortól?

Az alábbiakban összegyűjtöttünk néhány kérdést, melyek segíthetnek a különböző megoldások összehasonlításában és kiválasztásában.

Megbízhatóság: Hogyan garantált az integráció megbízhatósága?

Ha egy folyamat kritikus az üzletünk számára, például a raktárkészlet frissítése, arra fel kell hívnunk a rendszerintegrátor figyelmét, és különösen fontossá válik a naplózás, monitorozás, az automatikus hibakezelés, az értesítési rendszer és akár folyamatosan elérhető segítségnyújtás.

Kérdések:

Teljesítmény: Hogyan fokozható a teljesítmény? Elérhetők-e teljesítménytesztek vagy összehasonlítások? Mi az integráció szűk keresztmetszete, illetve mik a korlátai? Hogyan küszöbölhető ki a szűk keresztmetszet? Mi az egyes folyamatok teljesítményének felső határa?

Teljesítmény szempontjából érdemes meghatározni a várható legnagyobb terhelést és összevetni a kínált megoldás mutatóival. Meg kell fogalmazni az elvárásainkat, és ha azok nincsenek összhangban az integrátor által szállított megoldás lehetőségeivel, akkor az integráció testre szabására, esetleg alternatív megoldásra lehet szükség.

A kötegelt adatimport és -frissítések okoznak a legkönnyebben teljesítményproblémákat, ezért bárhol, ahol nagy mennyiségű adatot szinkronizálunk egyszerre, különös körültekintésre van szükség.

Skálázhatóság: További erőforrások hozzáadásával javítható-e a teljesítmény? Ki lehet a megoldást terjeszteni úgy, hogy további webshopokat tudjon kezelni?

Meg kell győződnünk róla, hogy az integráció képes megfelelni minden jelenlegi, illetve potenciális jövőbeli üzleti elvárásnak.

Adatgazda, adatbiztonság és átláthatóság: Kinek a tulajdonában van az adatok? Hogyan garantált az adatbiztonság? A szinkronizálási folyamatok mennyire átláthatók a kereskedő számára?

Ezek lényeges kérdések lehetnek abban az esetben, ha bizalmas adatokat kezelünk, és felhő alapú, illetve szolgáltatott szoftver (SaaS) megoldásban gondolkozunk.

Egyedi fejlesztés: Hogyan történik a hibajavítás és az új szoftververziók telepítése? Bővíthető-e az integráció harmadik fél által? A részben vagy egészben nyílt forrású e- a szoftver? Rendelkezésre áll műszaki vagy fejlesztői dokumentáció?

Az integráció során valamilyen szintű testreszabásra a legtöbb esetben szükség van, illetve gyakran új kérések merülnek fel menet közben. Nagyobb szabadságot tesz lehetővé a megrendelő számára, ha külső, vagy saját fejlesztőket is be lehet vonni.

Kód karbantartás és aktív fejlesztés: A kódot aktívan karbantartják? Milyen gyakran jönnek ki új kiadások? Mennyire egyszerűen tudja a kereskedő az új változatokat vagy frissítéseket telepíteni? Tartalmazza-e a támogatási csomag ezeket a folyamatokat?

Költségek és szállítási határidők: Milyen költségei vannak a telepítésnek, a konfigurálásnak, a támogatásnak és a testre szabásnak? Milyen szolgáltatásokat tartalmaz a meghirdetett ár? Mennyire bonyolult a megoldás konfigurálása? Mennyi egyedi fejlesztésre van szükség az alapértelmezett megoldáshoz képest?

Általában minél inkább lefedi egy kulcsra kész megoldás a kereskedő igényeit, annál kevésbé kockázatos annak testreszabása és élesítése. Egy megoldás megvalósításának és üzemeltetésének teljes költségének számos összetevője van, és érdemes minddel tisztában lenni.

Támogatás: Milyen támogatást nyújt az integrátor felhasználói kérdések megválaszolásában, sürgős esetben elérhető-e műszaki személyzet, amely azonnal cselekedni tud?

Természetesen az állandóan rendelkezésre álló támogatás a legelőnyösebb, de amennyiben ez nem elérhető, győződjünk meg róla, hogy a szolgáltató reakcióideje megfelelő a számunkra.

Konklúzió

A Magento-ERP integráció komplex feladat, rengeteg lehetséges szemponttal, amit figyelembe kell venni. Mielőtt belevágnánk a megvalósításba, még az egyszerűbb esetekben is ajánlott felmérni az üzleti igényeket, számba venni és fontossági sorrendbe állítani a kívánt funkciókat, a teljesítménnyel szembeni elvárásokat és egyéb számunkra lényeges tényezőket.

Szintén hasznos előre tájékozódni a különböző megoldások előnyeiről és hátrányairól – a fenti lista remélhetőleg segítséget nyújt ebben.

Az AionHill-nél az évek során számos ERP és egyéb külső rendszert integráltunk sikeresen Magento webshoppal, és készséggel állunk rendelkezésére bárkinek, akinek segítségre van szüksége.

Amennyiben bármilyen kérdésed merülne fel a témával kapcsolatban, írd meg kommentben és szívesen válaszolunk.