Magento 2 modulfejlesztés lépésről lépésre – 2. rész

Cikksorozatunk előző részében bemutattuk, miért érdemes webáruház fejlesztéséhez a Magento 2-t választani, és hogyan kezdhetünk bele a saját, felhasználói modulok fejlesztésébe. Összefoglaltuk a munkához szükséges követelményeket, bemutattuk, hogyan telepíthetjük a webáruházunk üzemeltetéséhez szükséges rendszert, és felvázoltuk a munka kezdetéhez nélkülözhetetlen beállításokat. Bemutattuk egy alap modul felépítését, valamint belekezdtünk annak elkészítésébe.

Ebben a cikkben folytatjuk a munkát, és komolyabb vizekre evezünk. Sok más, hasznos funkció melett megismerkedünk az adminisztrációs felületen a modulunkhoz tartozó menüpontok létrehozásának folyamatával, az editáláshoz szükséges admin block-ok létrehozásával, illetve a controller-ek és layout létrehozásával is.

A következő témákkal fogunk megismerkedni:

  • 1) Admin menüpont és táblázat (grid) elkészítése
  • 2) UI Components avagy az admin táblázat (grid) új kialakítása
  • 3) UI component osztályok
  • 4) Adminhtml controller-ek
  • 5) Object manager konfigurációs
  • 6) Editáláshoz szükséges admin block-ok létrehozása
  • 7) Controller-ek és layout létrehozása

1) Admin menüpont és táblázat (grid) elkészítése

Első lépésben létre kell hoznunk az adminisztrációs felületen a modulunkhoz tartozó menüpontot. Ezt külön (új) főmenüben is elhelyezhetjük, de célszerű a modul működéséhez igazodva besorolni a már létező főmenüpontok alá. Jelen esetben a Content főmenüpontban helyezzük el a sajátunkat.

Ehhez szükségünk lesz egy új file-ra. Ezt a menüpontot az app/code/Aion/Test/etc/adminhtml/ könyvtárban lévő menu.xml-ben valósíthatjuk meg. A fájl tartalma:

<?xml version="1.0"?>
<!--
/**
 * Copyright © 2016 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_Backend:etc/menu.xsd">
    <menu>
        <add id="Aion_Test::content_elements" title="Test Extension" module="Magento_Backend" sortOrder="10" parent="Magento_Backend::content"
             resource="Magento_Backend::content_elements"/>
        <add id="Aion_Test::aion_test" title="Manage Items" module="Aion_Test" sortOrder="10" parent="Aion_Test::content_elements" action="test/test"
             resource="Aion_Test::test"/>
    </menu>
</config>

A file-ban első lépésben definiálunk egy főelemet, ami nem más, mint az id=Aion_Test::content_elements és a menüpontot ez alá helyezzük el, úgy hogy a menüpont (id=Aion_Test::aion_test) parent-nél a főelemet adjuk meg. Ha mindent jól csináltunk, az adminisztrációs felületen a Content főmenüpontban megjelenik a saját almenüpontunk is.

A menüpontnál még fontos megemlíteni az Action=”test/test” paramétert, ami a később kialakítandó adminhtml controller útvonalát hivatott megadni.   A következő lépésben szükséges elkészíteni az adminhtml controllert és layout file-t, ami a grid megjelenítésért felelős.

Azonban előtte létre kell hoznunk egy abstract controller osztályt, hogy a backend jogosultság kezelést egy helyen valósítsuk meg.   Az abstract controller osztályt az app/code/Aion/Test/Controller/Adminhtml/ 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\Controller\Adminhtml;

/**
 * Aion manage items controller
 */
abstract class Test extends \Magento\Backend\App\Action
{
    /**
     * Core registry
     *
     * @var \Magento\Framework\Registry
     */
    protected $_coreRegistry = null;

    /**
     * @param \Magento\Backend\App\Action\Context $context
     * @param \Magento\Framework\Registry $coreRegistry
     */
    public function __construct(\Magento\Backend\App\Action\Context $context, \Magento\Framework\Registry $coreRegistry)
    {
        $this->_coreRegistry = $coreRegistry;
        parent::__construct($context);
    }

    /**
     * Init page
     *
     * @param \Magento\Backend\Model\View\Result\Page $resultPage
     * @return \Magento\Backend\Model\View\Result\Page
     */
    protected function initPage($resultPage)
    {
        $resultPage->setActiveMenu('Aion_Test::aion_test')
            ->addBreadcrumb(__('Test'), __('Test'))
            ->addBreadcrumb(__('Items'), __(''));
        return $resultPage;
    }

    /**
     * Check the permission to run it
     *
     * @return boolean
     */
    protected function _isAllowed()
    {
        return $this->_authorization->isAllowed('Aion_Test::test_menu');
    }
}

Az abstract controller initPage() függvénye (metódusa) felelős az aktív menüpont beállítása mellett a breadcrumb (morzsa menü) útvonal beállításáért is. A másik fontos függvény az _isAllowed(), ami az adminisztrátor jogosultságot ellenőrzi és kezeli.

Ezután elkészítjük az admin táblázat (grid) kezeléséhez szükséges controllert is, amit az imént említett abstract controller-ből fogunk kiterjeszteni. A controller osztályt az app/code/Aion/Test/Controller/Adminhtml/Test könyvtárban lévő Index.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\Controller\Adminhtml\Test;

class Index extends \Aion\Test\Controller\Adminhtml\Test
{
    /**
     * @var \Magento\Framework\View\Result\PageFactory
     */
    protected $resultPageFactory;

    /**
     * @param \Magento\Backend\App\Action\Context $context
     * @param \Magento\Framework\Registry $coreRegistry
     * @param \Magento\Framework\View\Result\PageFactory $resultPageFactory
     */
    public function __construct(
        \Magento\Backend\App\Action\Context $context,
        \Magento\Framework\Registry $coreRegistry,
        \Magento\Framework\View\Result\PageFactory $resultPageFactory
    ) {
        $this->resultPageFactory = $resultPageFactory;
        parent::__construct($context, $coreRegistry);
    }

    /**
     * Index action
     *
     * @return \Magento\Framework\Controller\ResultInterface
     */
    public function execute()
    {
        /** @var \Magento\Backend\Model\View\Result\Page $resultPage */
        $resultPage = $this->resultPageFactory->create();
        $this->initPage($resultPage)->getConfig()->getTitle()->prepend(__('Items'));
        return $resultPage;
    }
}

A controller-ben lévő $resultPage és $this->resultPageFactory helyettesíti Magento 1.x-ből megismert $this->loadLayout() és $this->renderLayout() hívásokat.   Ahhoz, hogy a Magento 2.0 felismerje a létrehozott adminhtml controller-ek útvonalát, ezt definiálnunk kell egy külön fájl-ban. Az útvonal definiálását az app/code/Aion/Test/etc/adminhtml/ könyvtárban lévő routes.xml-ban valósítjuk meg. A fájl tartalma:

<?xml version="1.0"?>
<!--
/**
 * Copyright © 2016 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:App/etc/routes.xsd">
    <router id="admin">
        <route id="test" frontName="test">
            <module name="Aion_Test" before="Magento_Backend" />
        </route>
    </router>
</config>

A fájlban két lényeges tag és hozzá tartozó paraméter látható. Az első a <router id=”admin”> ami jelzi, hogy ez egy backend útvonal. A második a <route id=”test” frontName=”test”> ahol a frontName határozza meg az elkészült adminhtml controllerek fő útvonalát (az admin url utáni első paramétert).

Következő lépésben létre kell hoznunk a collection-t, melynek feladata, hogy a fenti admin táblázatot (grid) kiszolgálja a szükséges adatokkal. A collection-t az app/code/Aion/Model/ResourceModel/Test/Grid/ 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\Grid;

use Magento\Framework\Api\Search\SearchResultInterface;
use Magento\Framework\Search\AggregationInterface;
use Aion\Test\Model\ResourceModel\Test\Collection as TestCollection;

/**
 * Collection for displaying grid of Aion Items
 */
class Collection extends TestCollection implements SearchResultInterface
{
    /**
     * @var AggregationInterface
     */
    protected $aggregations;

    /**
     * @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 string $mainTable
     * @param string $eventPrefix
     * @param string $eventObject
     * @param string $resourceModel
     * @param string $model
     * @param string|null $connection
     * @param \Magento\Framework\Model\ResourceModel\Db\AbstractDb $resource
     *
     * @SuppressWarnings(PHPMD.ExcessiveParameterList)
     */
    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,
        $mainTable,
        $eventPrefix,
        $eventObject,
        $resourceModel,
        $model = 'Magento\Framework\View\Element\UiComponent\DataProvider\Document',
        $connection = null,
        \Magento\Framework\Model\ResourceModel\Db\AbstractDb $resource = null
    ) {
        parent::__construct(
            $entityFactory,
            $logger,
            $fetchStrategy,
            $eventManager,
            $storeManager,
            $connection,
            $resource
        );
        $this->_eventPrefix = $eventPrefix;
        $this->_eventObject = $eventObject;
        $this->_init($model, $resourceModel);
        $this->setMainTable($mainTable);
    }

    /**
     * @return AggregationInterface
     */
    public function getAggregations()
    {
        return $this->aggregations;
    }

    /**
     * @param AggregationInterface $aggregations
     * @return $this
     */
    public function setAggregations($aggregations)
    {
        $this->aggregations = $aggregations;
    }


    /**
     * Retrieve all ids for collection
     * Backward compatibility with EAV collection
     *
     * @param int $limit
     * @param int $offset
     * @return array
     */
    public function getAllIds($limit = null, $offset = null)
    {
        return $this->getConnection()->fetchCol($this->_getAllIdsSelect($limit, $offset), $this->_bindParams);
    }

    /**
     * Get search criteria.
     *
     * @return \Magento\Framework\Api\SearchCriteriaInterface|null
     */
    public function getSearchCriteria()
    {
        return null;
    }

    /**
     * Set search criteria.
     *
     * @param \Magento\Framework\Api\SearchCriteriaInterface $searchCriteria
     * @return $this
     * @SuppressWarnings(PHPMD.UnusedFormalParameter)
     */
    public function setSearchCriteria(\Magento\Framework\Api\SearchCriteriaInterface $searchCriteria = null)
    {
        return $this;
    }

    /**
     * Get total count.
     *
     * @return int
     */
    public function getTotalCount()
    {
        return $this->getSize();
    }

    /**
     * Set total count.
     *
     * @param int $totalCount
     * @return $this
     * @SuppressWarnings(PHPMD.UnusedFormalParameter)
     */
    public function setTotalCount($totalCount)
    {
        return $this;
    }

    /**
     * Set items list.
     *
     * @param \Magento\Framework\Api\ExtensibleDataInterface[] $items
     * @return $this
     * @SuppressWarnings(PHPMD.UnusedFormalParameter)
     */
    public function setItems(array $items = null)
    {
        return $this;
    }
}

A fájlban definiált osztály felelős a kialakítandó admin táblázatban (grid) az adatok hozzáadásáért, keresés és lapozás implementálásáért. A következőkben leírt UI Components megfelelő működéséhez szükséges a fenti függvények implementálása.

Másik előnye, hogy az itt definiált osztályt könnyen máshol is fel tudjuk használni, amennyiben máshol is megszeretnénk jeleníteni a modul adatait admin táblázatban (grid), például egy product vagy customer ajax tab-on az adminisztrációs felületen.

Már csak egy dolog van hátra, ami nem más, mint az Index controllerhez tartozó layout file elkészítése. A layout file-t az app/code/Aion/Test/view/adminhtml/layout/ könyvtárban lévő test_test_index.xml-ban valósítjuk meg. Jól látható a korábban definiált route a fájl nevében: alap route -> könyvtár -> controller action. A fájl tartalma:

<?xml version="1.0"?>
<!--
/**
 * Copyright © 2015 Magento. All rights reserved.
 * See COPYING.txt for license details.
 */
-->
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
    <body>
        <referenceContainer name="content">
            <uiComponent name="test_test_listing"/>
        </referenceContainer>
    </body>
</page>

A layout fájlban lévő „content” referencia konténerben van definiálva a korábban említett UI component file neve, amire a következő pontban térünk ki részletesen.

2) UI Components avagy az admin táblázat (grid) új kialakítása

A Magento 2.0-ban bevezetett UI component-ek használatával sokkal könnyebben tudunk admin táblázatot (grid) létrehozni és emellett az adminisztrátor számára sokkal több lehetőséget nyújt a táblázatban történő kereséshez, szűréshez, az oszlopok tetszőleges megjelenítéséhez. Emellett külön megjelenítések menthetők le.

A UI component-ek működéséhez több fájlt is létre kell hoznunk és megfelelően implementálnunk. A legfontosabb fájl, ami az admin táblázat működését és megjelenését meghatározza egy xml fájl. Ez a mi modulunk esetében a test_test_listing.xml nevet kapta (lásd előző pont) és az app/code/Aion/Test/view/adminhtml/ui_component könyvtárban van elhelyezve. A fájl nagyon hosszú, így tartalmát darabolva jelenítjük meg cikkünkben.

<?xml version="1.0" encoding="UTF-8"?>
<!--
/**
 * Copyright © 2016 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
-->
<listing xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Ui:etc/ui_configuration.xsd">
    <argument name="data" xsi:type="array">
        <item name="js_config" xsi:type="array">
            <item name="provider" xsi:type="string">test_test_listing.test_test_listing_data_source</item>
            <item name="deps" xsi:type="string">test_test_listing.test_test_listing_data_source</item>
        </item>
        <item name="spinner" xsi:type="string">test_test_columns</item>
        <item name="buttons" xsi:type="array">
            <item name="add" xsi:type="array">
                <item name="name" xsi:type="string">add</item>
                <item name="label" xsi:type="string" translate="true">Add New Item</item>
                <item name="class" xsi:type="string">primary</item>
                <item name="url" xsi:type="string">*/*/new</item>
            </item>
        </item>
    </argument>
    <dataSource name="test_test_listing_data_source">
        <argument name="dataProvider" xsi:type="configurableObject">
            <argument name="class" xsi:type="string">TestGridDataProvider</argument>
            <argument name="name" xsi:type="string">test_test_listing_data_source</argument>
            <argument name="primaryFieldName" xsi:type="string">test_id</argument>
            <argument name="requestFieldName" xsi:type="string">id</argument>
            <argument name="data" xsi:type="array">
                <item name="config" xsi:type="array">
                    <item name="update_url" xsi:type="url" path="mui/index/render"/>
                </item>
            </argument>
        </argument>
        <argument name="data" xsi:type="array">
            <item name="js_config" xsi:type="array">
                <item name="component" xsi:type="string">Magento_Ui/js/grid/provider</item>
            </item>
        </argument>
    </dataSource>

 

A fájlban lévő első argument tag-ben vannak definiálva az alábbiak:

  • adat forrás név (test_test_listing_data_source) lásd második dataSource tag: <dataSource name=”test_test_listing_data_source”>
  • oszlopok tag neve: test_test_columns, erre továbbiakban lesz szükségünk
  • az új elem hozzáadása és egyéb gombok definiálása, lásd: <item name=”buttons” xsi:type=”array”> tag
<container name="listing_top">
    <argument name="data" xsi:type="array">
        <item name="config" xsi:type="array">
            <item name="template" xsi:type="string">ui/grid/toolbar</item>
        </item>
    </argument>
    <bookmark name="bookmarks">
        <argument name="data" xsi:type="array">
            <item name="config" xsi:type="array">
                <item name="storageConfig" xsi:type="array">
                    <item name="namespace" xsi:type="string">test_test_listing</item>
                </item>
            </item>
        </argument>
    </bookmark>
    <component name="columns_controls">
        <argument name="data" xsi:type="array">
            <item name="config" xsi:type="array">
                <item name="columnsData" xsi:type="array">
                    <item name="provider" xsi:type="string">test_test_listing.test_test_listing.test_test_columns</item>
                </item>
                <item name="component" xsi:type="string">Magento_Ui/js/grid/controls/columns</item>
                <item name="displayArea" xsi:type="string">dataGridActions</item>
            </item>
        </argument>
    </component>

Az xml fájlt tovább böngészve definiálásra kerülnek a táblázat felett elhelyezkedő funkciók. Ezek az alábbiak:

  • lementhetjük az aktuális táblázat megjelenést több view-ban, lásd: <bookmark name=”bookmarks”> tag
  • beállíthatjuk túl sok oszlop esetén, hogy melyek jelenjenek meg és az előbb említett bookmarks-nál menthetjük le, lásd: <component name=”columns_controls”> tag
<filterSearch name="fulltext">
    <argument name="data" xsi:type="array">
        <item name="config" xsi:type="array">
            <item name="provider" xsi:type="string">test_test_listing.test_test_listing_data_source</item>
            <item name="chipsProvider" xsi:type="string">test_test_listing.test_test_listing.listing_top.listing_filters_chips</item>
            <item name="storageConfig" xsi:type="array">
                <item name="provider" xsi:type="string">test_test_listing.test_test_listing.listing_top.bookmarks</item>
                <item name="namespace" xsi:type="string">current.search</item>
            </item>
        </item>
    </argument>
</filterSearch>
<filters name="listing_filters">
    <argument name="data" xsi:type="array">
        <item name="config" xsi:type="array">
            <item name="columnsProvider" xsi:type="string">test_test_listing.test_test_listing.test_test_columns</item>
            <item name="storageConfig" xsi:type="array">
                <item name="provider" xsi:type="string">test_test_listing.test_test_listing.listing_top.bookmarks</item>
                <item name="namespace" xsi:type="string">current.filters</item>
            </item>
            <item name="templates" xsi:type="array">
                <item name="filters" xsi:type="array">
                    <item name="select" xsi:type="array">
                        <item name="component" xsi:type="string">Magento_Ui/js/form/element/ui-select</item>
                        <item name="template" xsi:type="string">ui/grid/filters/elements/ui-select</item>
                    </item>
                </item>
            </item>
            <item name="childDefaults" xsi:type="array">
                <item name="provider" xsi:type="string">test_test_listing.test_test_listing.listing_top.listing_filters</item>
                <item name="imports" xsi:type="array">
                    <item name="visible" xsi:type="string">test_test_listing.test_test_listing.test_test_columns.${ $.index }:visible</item>
                </item>
            </item>
        </item>
    </argument>
</filters>

Hozzáadásra kerül a text alapú kereső és a táblázat szűrése (filters). Ezek az alábbiak:

  • varchar, text típusú oszlopokban kereshetünk egy input mezőben, lásd: <filterSearch name=”fulltext”> tag
  • minden egyes oszlopot szűrhetünk megfelelő paraméterek szerint view(Aion\Test\Ui\Component\Listing\Column\Test\Options), select, dátum, ID(range), text típusú szűrések, lásd: <filters name=”listing_filters”> tag
<massaction name="listing_massaction">
    <argument name="data" xsi:type="array">
        <item name="config" xsi:type="array">
            <item name="selectProvider" xsi:type="string">test_test_listing.test_test_listing.test_test_columns.ids</item>
            <item name="indexField" xsi:type="string">test_id</item>
        </item>
    </argument>
    <action name="delete">
        <argument name="data" xsi:type="array">
            <item name="config" xsi:type="array">
                <item name="type" xsi:type="string">delete</item>
                <item name="label" xsi:type="string" translate="true">Delete</item>
                <item name="url" xsi:type="url" path="test/test/massDelete"/>
                <item name="confirm" xsi:type="array">
                    <item name="title" xsi:type="string" translate="true">Delete items</item>
                    <item name="message" xsi:type="string" translate="true">Are you sure you wan't to delete selected items?</item>
                </item>
            </item>
        </argument>
    </action>
    <action name="disable">
        <argument name="data" xsi:type="array">
            <item name="config" xsi:type="array">
                <item name="type" xsi:type="string">disable</item>
                <item name="label" xsi:type="string" translate="true">Disable</item>
                <item name="url" xsi:type="url" path="test/test/massDisable"/>
            </item>
        </argument>
    </action>
    <action name="enable">
        <argument name="data" xsi:type="array">
            <item name="config" xsi:type="array">
                <item name="type" xsi:type="string">enable</item>
                <item name="label" xsi:type="string" translate="true">Enable</item>
                <item name="url" xsi:type="url" path="test/test/massEnable"/>
            </item>
        </argument>
    </action>
</massaction>

A massaction tag-en belül kerülnek hozzáadásra tetszőleges általunk definiált műveletek, melyek a tömeges adatmódosításra szolgálnak. A modulunkban ezek az alábbiak:

  • tömeges törlés, lásd: <action name=”delete”> tag
  • tömeges engedélyezés és tiltás, lásd: <action name=”disable”> és <action name=”enable”> tag-ek. Ezek a modulunk adatbázis táblájában korában kialakított is_active adatot módosítják.
    <paging name="listing_paging">
        <argument name="data" xsi:type="array">
            <item name="config" xsi:type="array">
                <item name="storageConfig" xsi:type="array">
                    <item name="provider" xsi:type="string">test_test_listing.test_test_listing.listing_top.bookmarks</item>
                    <item name="namespace" xsi:type="string">current.paging</item>
                </item>
                <item name="selectProvider" xsi:type="string">test_test_listing.test_test_listing.test_test_columns.ids</item>
            </item>
        </argument>
    </paging>
</container>

A <paging name=”listing_paging”> tag implementálja lapozást és a listázott elemek számának választhatóságát (select) a táblázatunkban.

    <paging name="listing_paging">
        <argument name="data" xsi:type="array">
            <item name="config" xsi:type="array">
                <item name="storageConfig" xsi:type="array">
                    <item name="provider" xsi:type="string">test_test_listing.test_test_listing.listing_top.bookmarks</item>
                    <item name="namespace" xsi:type="string">current.paging</item>
                </item>
                <item name="selectProvider" xsi:type="string">test_test_listing.test_test_listing.test_test_columns.ids</item>
            </item>
        </argument>
    </paging>
</container>

Fentiek után következik a táblázat oszlopainak meghatározása, lásd: <columns name=”test_test_columns”> tag. Ennek nevét már a fájl elején definiáltuk. A korábban említett mass action-ökhez beállított ID mező, lásd: <selectionsColumn name=”ids”> tag.

<column name="test_id">
            <argument name="data" xsi:type="array">
                <item name="config" xsi:type="array">
                    <item name="filter" xsi:type="string">textRange</item>
                    <item name="sorting" xsi:type="string">asc</item>
                    <item name="label" xsi:type="string" translate="true">ID</item>
                </item>
            </argument>
        </column>
        <column name="name">
            <argument name="data" xsi:type="array">
                <item name="config" xsi:type="array">
                    <item name="editor" xsi:type="array">
                        <item name="editorType" xsi:type="string">text</item>
                        <item name="validation" xsi:type="array">
                            <item name="required-entry" xsi:type="boolean">true</item>
                        </item>
                    </item>
                    <item name="filter" xsi:type="string">text</item>
                    <item name="label" xsi:type="string" translate="true">Name</item>
                </item>
            </argument>
        </column>
        <column name="email">
            <argument name="data" xsi:type="array">
                <item name="config" xsi:type="array">
                    <item name="editor" xsi:type="array">
                        <item name="editorType" xsi:type="string">text</item>
                        <item name="validation" xsi:type="array">
                            <item name="required-entry" xsi:type="boolean">true</item>
                        </item>
                    </item>
                    <item name="filter" xsi:type="string">text</item>
                    <item name="label" xsi:type="string" translate="true">Email</item>
                </item>
            </argument>
        </column>
        <column name="creation_time" class="Magento\Ui\Component\Listing\Columns\Date">
            <argument name="data" xsi:type="array">
                <item name="config" xsi:type="array">
                    <item name="filter" xsi:type="string">dateRange</item>
                    <item name="component" xsi:type="string">Magento_Ui/js/grid/columns/date</item>
                    <item name="dataType" xsi:type="string">date</item>
                    <item name="label" xsi:type="string" translate="true">Created</item>
                </item>
            </argument>
        </column>
        <column name="update_time" class="Magento\Ui\Component\Listing\Columns\Date">
            <argument name="data" xsi:type="array">
                <item name="config" xsi:type="array">
                    <item name="filter" xsi:type="string">dateRange</item>
                    <item name="component" xsi:type="string">Magento_Ui/js/grid/columns/date</item>
                    <item name="dataType" xsi:type="string">date</item>
                    <item name="label" xsi:type="string" translate="true">Modified</item>
                </item>
            </argument>
        </column>
        <column name="sort_order">
            <argument name="data" xsi:type="array">
                <item name="config" xsi:type="array">
                    <item name="editor" xsi:type="array">
                        <item name="editorType" xsi:type="string">text</item>
                        <item name="validation" xsi:type="array">
                            <item name="required-entry" xsi:type="boolean">true</item>
                        </item>
                    </item>
                    <item name="filter" xsi:type="string">text</item>
                    <item name="label" xsi:type="string" translate="true">Sort Order</item>
                </item>
            </argument>
        </column>
        <column name="is_active">
            <argument name="data" xsi:type="array">
                <item name="options" xsi:type="array">
                    <item name="disable" xsi:type="array">
                        <item name="value" xsi:type="string">0</item>
                        <item name="label" xsi:type="string" translate="true">Disabled</item>
                    </item>
                    <item name="enable" xsi:type="array">
                        <item name="value" xsi:type="string">1</item>
                        <item name="label" xsi:type="string" translate="true">Enabled</item>
                    </item>
                </item>
                <item name="config" xsi:type="array">
                    <item name="filter" xsi:type="string">select</item>
                    <item name="component" xsi:type="string">Magento_Ui/js/grid/columns/select</item>
                    <item name="editor" xsi:type="string">select</item>
                    <item name="dataType" xsi:type="string">select</item>
                    <item name="label" xsi:type="string" translate="true">Status</item>
                </item>
            </argument>
        </column>
        <actionsColumn name="actions" class="Aion\Test\Ui\Component\Listing\Column\TestActions">
            <argument name="data" xsi:type="array">
                <item name="config" xsi:type="array">
                    <item name="indexField" xsi:type="string">test_id</item>
                </item>
            </argument>
        </actionsColumn>
    </columns>
</listing>

Ezt követően a táblázatban lévő oszlopokat kell meghatároznunk. Az egyes oszlopoknál beállíthatjuk a típust, pl.: text, select, textRange, dateRange stb. Az utolsó oszlop az alap action-öket tartalmazza, lásd: <actionsColumn name=”actions” class=”Aion\Test\Ui\Component\Listing\Column\TestActions”> tag

Ezzel el is készültünk a grid definíciós xml-lel (test_test_listing.xml). A továbbiakban megnézünk néhány osztályt, ami az utolsó oszlopban lévő action-ökért felel.

3) UI component osztályok

Az előző pontban kialakított grid definíciós xml-ben található action oszlop működéséhez szükségünk van egy osztályra, mely a megjelenítést és a működést segítik.   Az első az előző pontban látható <actionsColumn name=”actions” class=”Aion\Test\Ui\Component\Listing\Column\TestActions”> tag-ben látható a TestActions osztály.

A fájl az app/code/Aion/Test/Ui/Component/Listing/Column könyvtárban van elhelyezve TestActions.php néven. A fájl tartalma:

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

use Magento\Framework\UrlInterface;
use Magento\Framework\View\Element\UiComponent\ContextInterface;
use Magento\Framework\View\Element\UiComponentFactory;
use Magento\Ui\Component\Listing\Columns\Column;

/**
 * Class TestActions
 */
class TestActions extends Column
{
    /**
     * Url path
     */
    const URL_PATH_EDIT = 'test/test/edit';
    const URL_PATH_DELETE = 'test/test/delete';

    /**
     * @var UrlInterface
     */
    protected $urlBuilder;

    /**
     * Constructor
     *
     * @param ContextInterface $context
     * @param UiComponentFactory $uiComponentFactory
     * @param UrlInterface $urlBuilder
     * @param array $components
     * @param array $data
     */
    public function __construct(
        ContextInterface $context,
        UiComponentFactory $uiComponentFactory,
        UrlInterface $urlBuilder,
        array $components = [],
        array $data = []
    ) {
        $this->urlBuilder = $urlBuilder;
        parent::__construct($context, $uiComponentFactory, $components, $data);
    }

    /**
     * Prepare Data Source
     *
     * @param array $dataSource
     * @return array
     */
    public function prepareDataSource(array $dataSource)
    {
        if (isset($dataSource['data']['items'])) {
            foreach ($dataSource['data']['items'] as & $item) {
                if (isset($item['test_id'])) {
                    $item[$this->getData('name')] = [
                        'edit' => [
                            'href' => $this->urlBuilder->getUrl(
                                static::URL_PATH_EDIT,
                                [
                                    'test_id' => $item['test_id']
                                ]
                            ),
                            'label' => __('Edit')
                        ],
                        'delete' => [
                            'href' => $this->urlBuilder->getUrl(
                                static::URL_PATH_DELETE,
                                [
                                    'test_id' => $item['test_id']
                                ]
                            ),
                            'label' => __('Delete'),
                            'confirm' => [
                                'title' => __('Delete "${ $.$data.name }"'),
                                'message' => __('Are you sure you wan\'t to delete a "${ $.$data.name }" record?')
                            ]
                        ]
                    ];
                }
            }
        }

        return $dataSource;
    }
}

Az osztály előállítja a mass action megjelenítéséhez szükséges tömböt a megfelelő formátumban. A file elején lévő konstantsoknál fontos a pontos útvonal meghatározása, hogy a megfelelő adminhtml controller-re mutassanak.

4) Adminhtml controller-ek

A grid teljes működéséhez néhány controller-t még el kell készíteni. Nézzük sorban őket.

A tömeges törléshez a massDelete controller-t használjuk. A fájl az app/code/Aion/Test/Controller/Adminhtml/Test/ könyvtárban van elhelyezve MassDelete.php néven. A fájl tartalma:

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

use Magento\Framework\Controller\ResultFactory;
use Magento\Backend\App\Action\Context;
use Magento\Ui\Component\MassAction\Filter;
use Aion\Test\Model\ResourceModel\Test\CollectionFactory;

/**
 * Class MassDelete
 */
class MassDelete extends \Magento\Backend\App\Action
{
    /**
     * @var Filter
     */
    protected $filter;

    /**
     * @var CollectionFactory
     */
    protected $collectionFactory;

    /**
     * @param Context $context
     * @param Filter $filter
     * @param CollectionFactory $collectionFactory
     */
    public function __construct(Context $context, Filter $filter, CollectionFactory $collectionFactory)
    {
        $this->filter = $filter;
        $this->collectionFactory = $collectionFactory;
        parent::__construct($context);
    }

    /**
     * Execute action
     *
     * @return \Magento\Backend\Model\View\Result\Redirect
     * @throws \Magento\Framework\Exception\LocalizedException|\Exception
     */
    public function execute()
    {
        $collection = $this->filter->getCollection($this->collectionFactory->create());
        $collectionSize = $collection->getSize();

        foreach ($collection as $item) {
            $item->delete();
        }

        $this->messageManager->addSuccess(__('A total of %1 record(s) have been deleted.', $collectionSize));

        /** @var \Magento\Backend\Model\View\Result\Redirect $resultRedirect */
        $resultRedirect = $this->resultFactory->create(ResultFactory::TYPE_REDIRECT);
        return $resultRedirect->setPath('*/*/');
    }
}

A controller osztály execute() függvénye – vagyis az action – egy collection-t kap (\Magento\Ui\Component\MassAction\Filter osztálytól), amin végig iterálva törli az elemeket. A tömeges státusz módosításhoz a massEnable és massDisable controller-eket használjuk.

A fájlok az app/code/Aion/Test/Controller/Adminhtml/Test/ könyvtárban vannak elhelyezve MassEnable.php és MassDisable.php néven. A fájlok tartalma:

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

use Magento\Framework\Controller\ResultFactory;
use Magento\Backend\App\Action\Context;
use Magento\Ui\Component\MassAction\Filter;
use Aion\Test\Model\ResourceModel\Test\CollectionFactory;

/**
 * Class MassEnable
 */
class MassEnable extends \Magento\Backend\App\Action
{
    /**
     * @var Filter
     */
    protected $filter;

    /**
     * @var CollectionFactory
     */
    protected $collectionFactory;

    /**
     * @param Context $context
     * @param Filter $filter
     * @param CollectionFactory $collectionFactory
     */
    public function __construct(Context $context, Filter $filter, CollectionFactory $collectionFactory)
    {
        $this->filter = $filter;
        $this->collectionFactory = $collectionFactory;
        parent::__construct($context);
    }

    /**
     * Execute action
     *
     * @return \Magento\Backend\Model\View\Result\Redirect
     * @throws \Magento\Framework\Exception\LocalizedException|\Exception
     */
    public function execute()
    {
        $collection = $this->filter->getCollection($this->collectionFactory->create());

        foreach ($collection as $item) {
            $item->setIsActive(true);
            $item->save();
        }

        $this->messageManager->addSuccess(__('A total of %1 record(s) have been enabled.', $collection->getSize()));

        /** @var \Magento\Backend\Model\View\Result\Redirect $resultRedirect */
        $resultRedirect = $this->resultFactory->create(ResultFactory::TYPE_REDIRECT);
        return $resultRedirect->setPath('*/*/');
    }
}
<?php
/**
 * Copyright © 2016 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
namespace Aion\Test\Controller\Adminhtml\Test;

use Magento\Framework\Controller\ResultFactory;
use Magento\Backend\App\Action\Context;
use Magento\Ui\Component\MassAction\Filter;
use Aion\Test\Model\ResourceModel\Test\CollectionFactory;

/**
 * Class MassDisable
 */
class MassDisable extends \Magento\Backend\App\Action
{
    /**
     * @var Filter
     */
    protected $filter;

    /**
     * @var CollectionFactory
     */
    protected $collectionFactory;

    /**
     * @param Context $context
     * @param Filter $filter
     * @param CollectionFactory $collectionFactory
     */
    public function __construct(Context $context, Filter $filter, CollectionFactory $collectionFactory)
    {
        $this->filter = $filter;
        $this->collectionFactory = $collectionFactory;
        parent::__construct($context);
    }

    /**
     * Execute action
     *
     * @return \Magento\Backend\Model\View\Result\Redirect
     * @throws \Magento\Framework\Exception\LocalizedException|\Exception
     */
    public function execute()
    {
        $collection = $this->filter->getCollection($this->collectionFactory->create());

        foreach ($collection as $item) {
            $item->setIsActive(false);
            $item->save();
        }

        $this->messageManager->addSuccess(__('A total of %1 record(s) have been disabled.', $collection->getSize()));

        /** @var \Magento\Backend\Model\View\Result\Redirect $resultRedirect */
        $resultRedirect = $this->resultFactory->create(ResultFactory::TYPE_REDIRECT);
        return $resultRedirect->setPath('*/*/');
    }
}

A két controller működése nagyon hasonló egymáshoz. Mindkettő a Filter osztálytól kapott collection-ön iterál végig, és állítja be az is_active data kulcsot massEnbale esetén true-ra, míg massDisable esetén false-ra, majd menti a collection elemeit.

5) Object manager konfigurációs

Ahhoz, hogy az elkészített admin táblázat(grid) megfelelően működjön, meg kell adnunk a forrás adat objektumokat és filter-eket. Ehhez szükségünk lesz egy definíciós xml-re. A fájl az app/code/Aion/Test/etc/ könyvtárban van elhelyezve di.xml néven. A fájl tartalma:

<?xml version="1.0"?>
<!--
/**
 * Copyright © 2016 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:ObjectManager/etc/config.xsd">
    <type name="Magento\Framework\View\Element\UiComponent\DataProvider\CollectionFactory">
        <arguments>
            <argument name="collections" xsi:type="array">
                <item name="test_test_listing_data_source" xsi:type="string">Aion\Test\Model\ResourceModel\Test\Grid\Collection</item>
            </argument>
        </arguments>
    </type>
    <type name="Aion\Test\Model\ResourceModel\Test\Grid\Collection">
        <arguments>
            <argument name="mainTable" xsi:type="string">aion_test</argument>
            <argument name="eventPrefix" xsi:type="string">aion_test_grid_collection</argument>
            <argument name="eventObject" xsi:type="string">test_grid_collection</argument>
            <argument name="resourceModel" xsi:type="string">Aion\Test\Model\ResourceModel\Test</argument>
        </arguments>
    </type>
    <virtualType name="TestGirdFilterPool" type="Magento\Framework\View\Element\UiComponent\DataProvider\FilterPool">
        <arguments>
            <argument name="appliers" xsi:type="array">
                <item name="regular" xsi:type="object">Magento\Framework\View\Element\UiComponent\DataProvider\RegularFilter</item>
                <item name="fulltext" xsi:type="object">Magento\Framework\View\Element\UiComponent\DataProvider\FulltextFilter</item>
            </argument>
        </arguments>
    </virtualType>
    <virtualType name="TestGridDataProvider" type="Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider">
        <arguments>
            <argument name="collection" xsi:type="object" shared="false">Aion\Test\Model\ResourceModel\Test\Collection</argument>
            <argument name="filterPool" xsi:type="object" shared="false">TestGirdFilterPool</argument>
        </arguments>
    </virtualType>
</config>

Ebben a fájlban definiáljuk a grid-hez szükséges collection-t (lásd: <item name=”test_test_listing_data_source” xsi:type=”string”>Aion\Test\Model\ResourceModel\Test\Grid\Collection</item>), filter-t és data provider-t, mely UI component megfelelő működéséhez szükséges.

Az egyes elemek editálását, mentését és egyenkénti törlését a következőkben írjuk le.

6) Editáláshoz szükséges admin block-ok létrehozása

Ahhoz, hogy a modulhoz tartozó adatokat létre tudjuk hozni az admin felületen és szerkeszteni tudjuk, szükségünk lesz a megfelelő osztályokra. Első lépésben a container osztályt kell létrehozni, mely később a form-ot fogja tartalmazni.

Az osztályt az Aion/Test/Block/Adminhtml/ könyvtárban lévő Test.php fájlban valósítjuk meg:

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

/**
 * Adminhtml Aion items content block
 */
class Test extends \Magento\Backend\Block\Widget\Grid\Container
{
    /**
     * @return void
     */
    protected function _construct()
    {
        $this->_blockGroup = 'Aion_Test';
        $this->_controller = 'adminhtml_test';
        $this->_headerText = __('Items');
        $this->_addButtonLabel = __('Add New Item');
        parent::_construct();
    }
}

Az osztályban lényeges a megfelelő blockGroup és controller meghatározása.

A következő lépésben szükségünk lesz a form container osztályra. Itt határozzuk meg szerkesztetés alatt álló objektum admin oldalának title-jét, és adhatunk hozzá tetszőleges button-okat az alap gombokon kívül, vagy távolíthatunk el.

Az osztályt az Aion/Test/Block/Adminhtml/Test könyvtárban lévő Edit.php fájlban valósítjuk meg:

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

/**
 * Adminhtml Aion items content block
 */
class Test extends \Magento\Backend\Block\Widget\Grid\Container
{
    /**
     * @return void
     */
    protected function _construct()
    {
        $this->_blockGroup = 'Aion_Test';
        $this->_controller = 'adminhtml_test';
        $this->_headerText = __('Items');
        $this->_addButtonLabel = __('Add New Item');
        parent::_construct();
    }
}

Amennyiben WYSWYG editort is szeretnénk használni például textarea típusú mezőhöz, akkor azt a _construct() függvényben kell elhelyezni, vagy a prepareLayout() függvényben. Az osztályban lévő getHeaderText() függvény határozza meg az admin oldal title értékét.

Az utolsó block, amit el kell készítenünk, a form megjelenítését és kezelését végzi. Az osztályt az Aion/Test/Block/Adminhtml/Test/Edit könyvtárban lévő Form.php fájlban valósítjuk meg:

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

/**
 * Adminhtml Aion item edit form
 */
class Form extends \Magento\Backend\Block\Widget\Form\Generic
{
    /**
     * @var \Magento\Cms\Model\Wysiwyg\Config
     */
    protected $_wysiwygConfig;

    /**
     * @var \Magento\Store\Model\System\Store
     */
    protected $_systemStore;

    /**
     * @param \Magento\Backend\Block\Template\Context $context
     * @param \Magento\Framework\Registry $registry
     * @param \Magento\Framework\Data\FormFactory $formFactory
     * @param \Magento\Cms\Model\Wysiwyg\Config $wysiwygConfig
     * @param \Magento\Store\Model\System\Store $systemStore
     * @param array $data
     */
    public function __construct(
        \Magento\Backend\Block\Template\Context $context,
        \Magento\Framework\Registry $registry,
        \Magento\Framework\Data\FormFactory $formFactory,
        \Magento\Cms\Model\Wysiwyg\Config $wysiwygConfig,
        \Magento\Store\Model\System\Store $systemStore,
        array $data = []
    ) {
        $this->_wysiwygConfig = $wysiwygConfig;
        $this->_systemStore = $systemStore;
        parent::__construct($context, $registry, $formFactory, $data);
    }

    /**
     * Init form
     *
     * @return void
     */
    protected function _construct()
    {
        parent::_construct();
        $this->setId('test_form');
        $this->setTitle(__('Item Information'));
    }

    /**
     * Prepare form
     *
     * @return $this
     */
    protected function _prepareForm()
    {
        $model = $this->_coreRegistry->registry('test_item');

        /** @var \Magento\Framework\Data\Form $form */
        $form = $this->_formFactory->create(
            ['data' => ['id' => 'edit_form', 'action' => $this->getData('action'), 'method' => 'post']]
        );

        $form->setHtmlIdPrefix('item_');

        $fieldset = $form->addFieldset(
            'base_fieldset',
            ['legend' => __('General Information'), 'class' => 'fieldset-wide']
        );

        if ($model->getId()) {
            $fieldset->addField('test_id', 'hidden', ['name' => 'test_id']);
        }

        $fieldset->addField(
            'name',
            'text',
            [
                'name' => 'name',
                'label' => __('Name'),
                'title' => __('Name'),
                'required' => true
            ]
        );

        $fieldset->addField(
            'email',
            'text',
            [
                'name' => 'email',
                'label' => __('Email'),
                'title' => __('Email'),
                'required' => true,
                'class' => 'validate-email'
            ]
        );

        $fieldset->addField(
            'is_active',
            'select',
            [
                'label' => __('Status'),
                'title' => __('Status'),
                'name' => 'is_active',
                'required' => true,
                'options' => ['1' => __('Enabled'), '0' => __('Disabled')]
            ]
        );
        if (!$model->getId()) {
            $model->setData('is_active', '1');
        }

        $fieldset->addField(
            'sort_order',
            'text',
            [
                'name' => 'sort_order',
                'label' => __('Sort Order'),
                'title' => __('Sort Order'),
                'required' => false
            ]
        );

        $form->setValues($model->getData());
        $form->setUseContainer(true);
        $this->setForm($form);

        return parent::_prepareForm();
    }
}

Az osztály _prepareForm() függvényében adjuk hozzá a szerkesztésre szánt mezőket, ami a mi esetünkben a name, email és sort_order mezők. Ezek mellett szerepel még a multistore kezelés szempontjából fontos store_id field is, illetve is_active field is, ami jelen esetben select típusú és a szerkesztés alatt álló elem státuszát hivatott beállítani.

A fent említett három osztállyal el is készítettük az adminisztrációs felületen történő szerkesztéshez szükséges fájlokat.

7) Controller-ek és layout létrehozása

Az editálás megvalósításához a fenti osztályokon kívül szükségünk lesz még a megfelelő controller osztályokra és layout fájlokra.   Az első osztályt az Aion/Test/Controller/Adminhtml/Test/ könyvtárban lévő NewAction.php fájlban valósítjuk meg:

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

class NewAction extends \Aion\Test\Controller\Adminhtml\Test
{
    /**
     * @var \Magento\Backend\Model\View\Result\ForwardFactory
     */
    protected $resultForwardFactory;

    /**
     * @param \Magento\Backend\App\Action\Context $context
     * @param \Magento\Framework\Registry $coreRegistry
     * @param \Magento\Backend\Model\View\Result\ForwardFactory $resultForwardFactory
     */
    public function __construct(
        \Magento\Backend\App\Action\Context $context,
        \Magento\Framework\Registry $coreRegistry,
        \Magento\Backend\Model\View\Result\ForwardFactory $resultForwardFactory
    ) {
        $this->resultForwardFactory = $resultForwardFactory;
        parent::__construct($context, $coreRegistry);
    }

    /**
     * Create new item
     *
     * @return \Magento\Framework\Controller\ResultInterface
     */
    public function execute()
    {
        /** @var \Magento\Framework\Controller\Result\Forward $resultForward */
        $resultForward = $this->resultForwardFactory->create();
        return $resultForward->forward('edit');
    }
}

Az osztály az új elemek létrehozására szolgál és lényegében az action függvénye (execute()) átirányít az Edit controller osztályra.   A következő lépésben létrehozzuk a szerkesztéshez szükséges controller-t.

Az osztályt az Aion/Test/Controller/Adminhtml/Test/ könyvtárban lévő Edit.php fájlban valósítjuk meg:

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

class Edit extends \Aion\Test\Controller\Adminhtml\Test
{
    /**
     * @var \Magento\Framework\View\Result\PageFactory
     */
    protected $resultPageFactory;

    /**
     * @param \Magento\Backend\App\Action\Context $context
     * @param \Magento\Framework\Registry $coreRegistry
     * @param \Magento\Framework\View\Result\PageFactory $resultPageFactory
     */
    public function __construct(
        \Magento\Backend\App\Action\Context $context,
        \Magento\Framework\Registry $coreRegistry,
        \Magento\Framework\View\Result\PageFactory $resultPageFactory
    ) {
        $this->resultPageFactory = $resultPageFactory;
        parent::__construct($context, $coreRegistry);
    }

    /**
     * Edit item
     *
     * @return \Magento\Framework\Controller\ResultInterface
     * @SuppressWarnings(PHPMD.NPathComplexity)
     */
    public function execute()
    {
        // 1. Get ID and create model
        $id = $this->getRequest()->getParam('test_id');
        $model = $this->_objectManager->create('Aion\Test\Model\Test');

        // 2. Initial checking
        if ($id) {
            $model->load($id);
            if (!$model->getId()) {
                $this->messageManager->addError(__('This item no longer exists.'));
                /** @var \Magento\Backend\Model\View\Result\Redirect $resultRedirect */
                $resultRedirect = $this->resultRedirectFactory->create();
                return $resultRedirect->setPath('*/*/');
            }
        }
        // 3. Set entered data if was error when we do save
        $data = $this->_objectManager->get('Magento\Backend\Model\Session')->getFormData(true);
        if (!empty($data)) {
            $model->setData($data);
        }

        // 4. Register model to use later in blocks
        $this->_coreRegistry->register('test_item', $model);

        /** @var \Magento\Backend\Model\View\Result\Page $resultPage */
        $resultPage = $this->resultPageFactory->create();

        // 5. Build edit form
        $this->initPage($resultPage)->addBreadcrumb(
            $id ? __('Edit Item') : __('New Item'),
            $id ? __('Edit Item') : __('New Item')
        );
        $resultPage->getConfig()->getTitle()->prepend(__('Items'));
        $resultPage->getConfig()->getTitle()->prepend($model->getId() ? $model->getName() : __('New Item'));
        return $resultPage;
    }
}

Az edit action(execute() függvény) első lépésben lekéri a test_id paramétert. Ezt követően inicializálja az Aion/Test/Model/Test modell osztályt. Amennyiben a test_id paraméternek van értéke, a modellt megpróbálja betöltelni az említett id-val.

Sikertelen esetben hibaüzenet állít be, majd visszairányít. Ellenkező esetben a betöltött modellt a registry-ben tárolja ($this->_coreRegistry->register(’test_item’, $model)). Ezt olvassa ki a registry-ből a fent már említett form container osztály is, és használja fel.

Végezetül létrehozza az oldalt ($resultPage), majd beállítja az oldal title paraméterét és breadcrumb-ot is.   A controller-hez tartozó layout fájlt az Aion/Test/view/adminhtml/layout/ könyvtárban lévő test_test_edit.xml fájlban valósítjuk meg:

<?xml version="1.0"?>
<!--
/**
 * Copyright © 2016 AionNext Ltd. All rights reserved.
 * See COPYING.txt for license details.
 */
-->
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
    <update handle="editor"/>
    <body>
        <referenceContainer name="content">
            <block class="Aion\Test\Block\Adminhtml\Test\Edit" name="test_test_edit"/>
        </referenceContainer>
    </body>
</page>

A következő lépés a mentés elkészítése. Az osztályt az Aion/Test/Controller/Adminhtml/Test/ könyvtárban lévő Save.php fájlban valósítjuk meg:

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

class Save extends \Aion\Test\Controller\Adminhtml\Test
{
    /**
     * Save action
     *
     * @return \Magento\Framework\Controller\ResultInterface
     */
    public function execute()
    {
        /** @var \Magento\Backend\Model\View\Result\Redirect $resultRedirect */
        $resultRedirect = $this->resultRedirectFactory->create();
        // check if data sent
        $data = $this->getRequest()->getPostValue();
        if ($data) {
            $id = $this->getRequest()->getParam('test_id');
            $model = $this->_objectManager->create('Aion\Test\Model\Test')->load($id);
            if (!$model->getId() && $id) {
                $this->messageManager->addError(__('This item no longer exists.'));
                return $resultRedirect->setPath('*/*/');
            }

            // init model and set data

            $model->setData($data);

            // try to save it
            try {
                // save the data
                $model->save();
                // display success message
                $this->messageManager->addSuccess(__('You saved the item.'));
                // clear previously saved data from session
                $this->_objectManager->get('Magento\Backend\Model\Session')->setFormData(false);

                // check if 'Save and Continue'
                if ($this->getRequest()->getParam('back')) {
                    return $resultRedirect->setPath('*/*/edit', ['test_id' => $model->getId()]);
                }
                // go to grid
                return $resultRedirect->setPath('*/*/');
            } catch (\Exception $e) {
                // display error message
                $this->messageManager->addError($e->getMessage());
                // save data in session
                $this->_objectManager->get('Magento\Backend\Model\Session')->setFormData($data);
                // redirect to edit form
                return $resultRedirect->setPath('*/*/edit', ['test_id' => $this->getRequest()->getParam('test_id')]);
            }
        }
        return $resultRedirect->setPath('*/*/');
    }
}

A controller osztály első lépésben várja a korábban kialakított form által posztolt adatokat ($data = $this->getRequest()->getPostValue();). Amennyiben ez nem egy üres tömb, inicializálja az Aion/Test/Model/Test modell osztályt és ha létezik a paraméterként kapott test_id is (vagyis nem új objektum mentésére kerül sor), akkor betölti a megfelelő id-val. Ezt követően a post-ban kapott adatokat beállítja majd menti a modellt.

Amennyiben mindezzel elkészültünk, akkor a korábban kialakított admin grid-ből (táblázat) új objektumokat tudunk hozzáadni és menteni, majd ezeket szerkeszteni. Még egy fontos controller van hátra, ami a törlést hivatott megvalósítani.

Az osztályt az Aion/Test/Controller/Adminhtml/Test/ könyvtárban lévő Delete.php fájlban valósítjuk meg:

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

class Delete extends \Aion\Test\Controller\Adminhtml\Test
{
    /**
     * Delete action
     *
     * @return \Magento\Framework\Controller\ResultInterface
     */
    public function execute()
    {
        /** @var \Magento\Backend\Model\View\Result\Redirect $resultRedirect */
        $resultRedirect = $this->resultRedirectFactory->create();
        // check if we know what should be deleted
        $id = $this->getRequest()->getParam('test_id');
        if ($id) {
            try {
                // init model and delete
                $model = $this->_objectManager->create('Aion\Test\Model\Test');
                $model->load($id);
                $model->delete();
                // display success message
                $this->messageManager->addSuccess(__('You deleted the item.'));
                // go to grid
                return $resultRedirect->setPath('*/*/');
            } catch (\Exception $e) {
                // display error message
                $this->messageManager->addError($e->getMessage());
                // go back to edit form
                return $resultRedirect->setPath('*/*/edit', ['test_id' => $id]);
            }
        }
        // display error message
        $this->messageManager->addError(__('We can\'t find the item to delete.'));
        // go to grid
        return $resultRedirect->setPath('*/*/');
    }
}

A delete action (execute() függvény) első lépésben lekéri a test_id paramétert. Ezt követően inicializálja az Aion/Test/Model/Test model osztályt. Amennyiben a test_id paraméternek van értéke, a modellt megpróbálja betölteni az említett id-val, majd elvégzi a törlést.

Folytatása következik

Ebben a cikkben ismét átvettünk néhány témakört, melyek segítenek a saját Magento 2.0 modulod fejlesztésében. Bízunk benne, hogy sikerült átadnunk mindazt a hasznos tudást, mely hozzájárul ahhoz, hogy funkcionális modulokat fejlesztess, elvégezd azok beállításait, valamint olyan fájlokat és elemeket szerkeszthess, mint az adatbázis tábla, modell, collection, block, admin táblázat, layout stb.

A 2. RÉSZNEK VÉGE, DE HAMAROSAN FOLYTATJUK!   A cikk első részét ide kattintva olvashatod. A következő részben ismét érdekes és hasznos témakörökkel, többek közt az observer-ek létrehozásával és implementálásával ismerkedhetszt meg.

 

Segítünk webáruházra váltani!

Nincsenek vásárlók a boltban? Kénytelen voltál bezárni? Elképesztő válság alakult ki egyes szektorokban a koronavírus járvány hatására, -pedig még nem is látjuk a végét, mi lesz májusban, júniusban. Nemzetközi hálózatkutató szakértők szerint 2020 őszére lehet vége a koronavírus járványnak. A működő webáruházak értékesebbé váltak, a jelentőségük a kereskedelemben tovább fog nőni.

Akinek most stabil webáruháza és vevőköre van, átvészelheti a válságot

Az elmúlt hónapban dupla annyian kerestek rá élelmiszerek házhozszállításával kapcsolatos kifejezésekre hazánkban. Megtriplázódó kosárértékekről osztanak meg híreket webkereskedők egymás közt. A jelenlegi egészségügyi helyzetben a webáruházas értékesítés tűnik az egyedül biztonságosnak. A vásárlók számára a biztonság elsődleges szempont lett: így weben rendelnek. Kevésbé árérzékenyen. Megfigyelhető még egy fontos trend: az eddig a magyar piacon szinte lebeszélhetetlenek voltak a vásárlók az utánvétes, készpénzes fizetésről. Most készpénzmentesen, előre utalással kifizetik a megrendelt árut, csökkentve ezzel a fertőzés veszélyt.

 

Hogy a különbséget érzékeltessük a boltok és a webáruházak forgalma között, a Dockyard-nál tavaly márciushoz képest 80%-kal növekedett a webshop forgalma a hónap első felében, míg az üzletekbe betérő vásárlóké 30-40%-kal visszaesett.  Persze sok webshop tulajdonos számára nehézséget is jelent az értékesítés felfuttatása. Akinek akadozó, rosszul kereshető, kevéssé használható a webshopja, sok bevételtől esik el.

 

A webáruházak egyre népszerűbbé válnak

Bár a plázák, butikok, szállodák és éttermek komolyan megsínylik a koronavírus járvány miatt kialakult válságot, a webáruházak előtt hatalmas felfutás áll. Több helyről lehet hallani, hogy olyan termékköröket forgalmazó webáruházakban is megugrottak a megrendelések, jelentek meg az érdeklődők, ahol eddig kifejezetten mérsékelt volt az érdeklődés (pl. barkács szerszámok).

Az idei év a webáruházak és az online piacterek erősödéséről fog szólni. Mindent visznek a vásárlók, amihez webáruházon keresztül hozzá lehet jutni. A saját árukészlettel rendelkező, gyors és kényelmes fizetést lehetővé tevő, vásárlási élményt adó áruház tulajdonosok most nyertesei ennek a pörgésnek.

Magento webáruházakat fejlesztünk. Egy Magento webáruház képes arra, hogy azt a vásárlási biztonságot megteremtse, amire a vásárlók törekedni fognak. Szabad kapacitásaink felszabadulásának ütemében vállalunk most is projekteket! A tervezéstől egészen a működtetés beindításáig segítséget adunk ügyfeleinknek. Évtizedes tapasztalattal segítünk kereskedőknek átállni a webáruházas értékesítésre. Ez idő alatt többszáz kereskedőnek hoztunk létre webáruházat.

Vérbeli kereskedő vagy? Az előtted álló heteket, hónapokat töltsd felkészüléssel!

A vevőid talán éppen most regisztrálnak egy webshopba, mert azt a terméket keresik, amit eddig Tőled vettek.

Ha két hét van a válság végéig? Felmérjük az igényeidet és komplett árajánlatot kaphatsz, mennyibe kerülne most egy új webáruház lefejlesztése, vagy átállítása Magento alapokra.

Ha két hónap? Ez idő alatt el is készül az új Magento webáruházad, amelyben kezdheted az internetes értékesítést.

És ha mindaz, amit eddig gondoltunk a vásárlásról, gyökeresen meg fog változni? Még inkább szükséged lesz arra, hogy megtaláld azt a formát, ahogy értékesíteni tudsz!

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.

 

Termék importálás Magento webshopba a Magmi rendszerrel

Tartalom

    • Mi is az a Magmi?
    • A Magmi és a Magento 2.0
    • A Magmi telepítése
    • A Magmi alapbeállítása
    • Magmi plugin-jainak a beállítása
  • Egyszerű termék importálása
  • Hogyan kell csoportos árat (Group Price) importálni?
  • Hogyan kell mennyiség kedvezmény árat (tier prices) beállítani?
  • Hogyan tudom a termékeket hozzárendelni a több website-os áruházban?
  • Hogyan kell importálni?
  • Konfigurálható termék importálása
  • Kötegelt termék importálása
  • Csoportos termék importálása
  • Letölthető termék importálása
  • Virtuális termék importálása
  • Jellemző és jellemzőhalmaz importálása
  • Termékkategóriák importálása
  • Többnyelvű importálás

Mi is az a Magmi?

A Magento egy erőteljes, a legtöbb e-kereskedelemmel kapcsolatos feladat ellátására alkalmas platform. Alapértelmezett kezelőfelülete azonban hagy némi kívánnivalót maga után. A Magmi, azaz a Magento Mass Importer feladata, hogy segítsen ezeknek a réseknek a kitöltésében, és könnyebbé tegye a Magento rendszeren üzemeltetett webáruházunk működtetését.

Gyakran merül fel az igény például arra, hogy egyszerre több száz, vagy akár több ezer termékből álló online katalógus hozzunk létre és kezeljünk, a lehető legegyszerűbb és leghatékonyabb módon. Ennek kivitelezése a Magento kezelőfelületén keresztül, manuális módon egyáltalán nem egyszerű feladat.

A Magmi egy olyan, nyílt forráskódú rendszer, melynek segítségével egy sor olyan import/export opcióhoz férhetünk hozzá, amelyek alapból nem találhatóak meg a Magento rendszerében, ám rendkívül megkönnyíthetik az ilyen, és ehhez hasonló munka elvégzését. Lényegében egy külső felhasználói felület, mely segítségével könnyedén importálhatunk termékeket (akár nagy számban is) egyszerű CSV-fájlokból a Magento alapú webáruházunkba.

Sajnos az adatbázist valamilyen módon mindenképpen nekünk kell kialakítanunk, ami azt jelenti, hogy az ehhez használt .csv kiterjesztésű fájlokat továbbra is nekünk kell létrehoznunk. Ezek a fájlok azonban az MS Excel vagy a LibreOffice Calc segítségével is könnyen szerkeszthetők, a Magmi segítségével pedig gyorsabbá és egyszerűbbé tehetjük az adatbázis feltöltésének feladatát. Legnagyobb erőssége, hogy olyan dolgokat is megtehetünk a segítségével, mint például a képek tömeges importálása, vagy éppen a kategóriák automatikus létrehozása termékeink importáláskor.

A Magmi használatának hátránya mindössze annyi, hogy a már megszokott magento kezelőfelület mellett egy újabb adminisztrációs interfész használatát meg kell tanulnunk, a tapasztalatok szerint azonban ez egyáltalán nem teljesíthetetlen feladat. Az applikáció bőséges dokumentációja ugyanis lépésről lépésre vezet minket végig minden fontos funkción, a fejlesztők pedig még saját Wikit is létrehoztak annak érdekében, hogy segítség a Magmi használata mellett döntő felhasználókat..

A Magmi és a Magento 2.0

Mint azt már nyilván sokan tudják, a Magento 1.x verzióinak hivatalos támogatása 2020 júniusában véget ér. Ez azt jelenti, hogy a keretrendszer 2.0-nál korábbi verziói ettől az időponttól kezdve sem szoftveres, sem pedig biztonsági támogatásban nem részesülnek hivatalosan, így használatuk veszélyessé válik.

A legtöbb e-kereskedő éppen ezért árhatóan a Magento 2.x verzióira vált majd, ezzel a váltással pedig óhatatlanul felmerül a kérdés: mi a helyzet a Magmi-val, ami a Magento 1.x verziói esetében olyan jó szolgálatot tett, ha a webruházba történő importálás és expotálás feladatáról volt szó?

Nos, van egy jó hírünk! A Magmi természetesen a Magento 2.0 verziójához is elérhető, habár bizonyos funkciói egyelőre kevésbé működnek hatékonyan, mint a rendszer korábbi változatai esetében. A Magento 1.x támogatásának megszűnésével azonban várható, hogy a fejlesztők belevetik magukat a Magmi új rendszerrel kompatibilis verziójának tökéletesítésébe, és hamarosan egy minden funkciójában tökéletes, az export és import feladatokat hibátlanul ellátó kiegészítőt köszönthetünk a legújabb Magmi-frissítés személyében.

A Magmi telepítése

A Magmi telepítése

A Magmi telepítése némi gyakorlatot igényel, azonban az interneten rengeteg segédanyagot találhatunk azzal kapcsolatban, hogyan is csináljuk helyesen, és természetesen most mi is azért vagyunk itt, hogy segítsünk.

A cikkben a Magmi 0.7.22 verziójának telepítését és alkalmazását fogjuk bemutatni.

  • Első lépésként töltsük le a Magmi-t a GitHub-ról. A Magento 2.0 verziójával kompatibilis változat az oldalon, ide kattintva érhető el.
  • Ha ez megtörtént, az FTP-kliens segítségével másoljuk fel a magento root könyvtárunkba.
  • Aki régebbi Magmi verziót használ (< 0.7.22) annak ajánlott a Magmi mappát átneveznie, és e mellet még htaccess-es megoldással levédeni a magmi/ root mappáját. Ha ezeket a beállításokat nem végezzük el, akkor bárki elérheti a Magmis felületünket.

 

Magmi plugin-jainak a beállítása

Magmi pluginjainak a beállítása

A Magmi kiegészítőinek beállításai a Configure Current Profile opció alatt, illetve a general és az itemprocessors résznél találhatók.

Mindegyik plugin-nál található egy Info gomb, melyre rákattintva rövid leírást kapunk az adott kiegészítőről. A Documentation gomb (mely nem biztos, hogy minden felhasználónál megjelenik) pedig a Magmi Wiki oldalára visz, ahol részletesebb leírást is találhatunk az adott pugin-ról.

Ha az egyik plugin-t aktiváljuk, megjelenik egy Configure gomb is, melynek megnyomása után be tudjuk állítani a kiegészítőhöz tartozó, fontos beállításokat.

Most minden plugin-ról leírunk pár fontos tudnivalót, a teljes, részletes ismertetőket a plugin-ok fentebb említett dokumentációjában találhatod meg.

Magmi beállítás általános

Remote Agent Plugin v0.0.1

  • Fejlesztette: Dweeves
  • Leírás: ez a plugin lehetővé teszi a távoli rendszeren való működést, akkor használatos, ha a Magmi távoli rendszeren van telepítve
  • Beállításai:
    • HTTP Url for magento base dir: távoli rendszer magento mappa url-je

Attribute Cleanup v0.0.1

  • Fejlesztette: 5byfive GmbH
  • Leírás: ez a plugin eltávolítja azokat a jellemzőket, melyek az adott terméknél nem használunk
  • Beállításai: nincs

Attribute Set Importer v0.0.2

  • Fejlesztette: 5byfive GmbH
  • Leírás: ez a plugin lehetővé teszi a jellemzőhalmazok és jellemzők importálását.
  • Beállításai:
    • Enable attribute import (Engedélyezzük-e a jellemző importálását)
      • CSV import mode: fentebb részletezve (a további beállítások is ugyanazok, mint a CSV options-nál)
      • Set default values for non-existing columns in CSV (JSON): ide kell beírni azokat az értékeket, amelyek mindegyik jellemzőnél ugyanazok, JSON formátumban kell megadni, pl. {“is_user_defined”:1,”is_visible”:1,”default_value”:”Test”}
      • Prune attributes which are not in CSV from database: ha ez be van kapcsolva, akkor először lefutatja a jellemző-importot, majd az összes olyan jellemzőt törli, ami nincs a csv-ben. Ez akkor jó, ha mindig az összes jellemzőt importáljuk és szeretnénk, ha a felesleges jellemzőket a plugin törölné.
      • Don’t touch non-user attributes when pruning (ha a prune attributes be van kapcsolva): Ezt akkor kell használnunk, ha csak azokat a jellemzőket szeretnénk törölni, amik is_user_defined = 1, vagyis a nem rendszer attribútumok. (ezt az egyedi fejlesztések során létrejött jellemzőkre szoktuk állítani)
      • additionally, keep following attributes when pruning, even if not given in CSV (comma-separated): Ebbe a mezőbe azoknak a jellemzőknek a kódját kell beírni (vesszővel elválasztva), amelyeket nem szeretnénk törölni (ezt akkor érdemes használni, ha a csv-ben nem adjuk meg a jellemzőt, de mégse szeretnénk, hogy a rendszer törölje)
      • Delete attributes marked “magmi:delete” = 1: ha ez be van kapcsolva és a csv-ben a magmi:delete oszlop létezik, amelynél 1-es értékre van állítva, akkor azt a jellemzőt törölni fogja
      • Create attributes from CSV which are not in database: ha ez bevan kapcsolva, akkor a plugin létrehozza azokat a jellemzőket, amelyek még nincsenek az adatbázisban. Ha nincs bekapcsolva, akkor a csv-ben lévő jellemzők
      • Update attributes from CSV which are already in database: kapcsoljuk be, ha szeretnénk, hogy frissítse a csv-ben megadott jellemzőket (ami szerepel az adatbázisban)
    • Enable attribute set import: engedélyezzük a jellemzőhalmaz importálását, Az itt található többi beállítás ugyanaz, mint a jellemzőnél.
    • Enable attribute association import: Ezzel tudjuk összepárosítani, hogy melyik jellemző melyik jellemzőcsoportba tartozzon.
      • CSV import mode: fentebb részletezve (a további csv beállítás is ugyanaz, mint a CSV options-nál)
      • Add these attribute associations to given CSV data: ide lehet plusz jellemző párosítást beletenni, vesszővel kell elválasztani ilyen formában: (attribute_set_name,attribute_code,attribute_group_name)

Ehhez tartozó beállítás ugyanaz, mint az előbbiekben leírtaknál.

Import Report Mail Notifier v1.0.0

  • Fejlesztette: Dweeves
  • Leírás: ezzel tudunk jelentést küldeni az importról
  • Beállításai:
    • Email report to: Kinek küldje a jelentést. Vesszővel elválasztva több e-mail címet is megadhatunk.
    • Report sender: küldő e-mail címe
    • Report sender alias: küldő alias-a
    • Subject: tárgy
    • Body: tartalom
    • Attachments: csatolmányok:
      • Attach import log: csatolja-e a jelentés log-ot
      • Attach source CSV: a csv forrást csatolja-e
      • Zip attachments: összecsomagolja-e a csatolmányokat

Magmi Import Url UI v1.0.3

  • Fejlesztette: Dweeves
  • Leírás: ez nem befolyásolja az importot, csak kiírja nekünk, hogy milyen url-en lehet meghívni. Ezeket általában cronjob-okba szokták írni.
  • Beállításai: nincs

Magmi Optimizer v1.0.5

  • Fejlesztette: Dweeves
  • Leírás: ez a plugin indexeket tesz pár olyan táblára, ahol észleli, hogy szükség van rá.
  • Beállításai: nincs

Magmi Magento Reindexer v1.0.3a

  • Fejlesztette: Dweeves
  • Leírás: ez a plugin a Magento-s reindexet hívja meg shell-ből, vagyis reindexelést végez.
  •  Beállításai:
    • PHP CLI command: php cli parancs
    • Indexing : Ki kell választani, hogy melyik index típusokat szeretnék, ha újraindexelné.

On the fly category creator/importer v0.2.5

  • Fejlesztette: Dweeves
  • Leírás: ezzel lehet importáláskor a kategóriákat létrehozni.
  • Beállításai:
    • Assign product to: Melyik kategóriához rendelje a terméket.
      • all categories in tree: az összes kategóriához a kategória fában (pl. Fő kategória/Alkategória/ ebben az esetben mind a 2 kategóriába bele fog tartozni)
      • last category of each branch: itt csak az utolsó szinten lévő kategóriába teszi bele a terméket.
    • Tree level separator: Alkategória elválasztójel (pl. / ebben az estben Kategória 1/Kategória 2)
    • base category tree: főkategória, ezt akkor ajánlott használni, ha mindegyik kategóriánk ugyanabba a főkategóriába tartozik.
    • url ending: url utótag, általában ajánlott a .html végződés

Downloadable products importer v1.0.0.1

  • Fejlesztette: Tangkoko SARL
  • Leírás: ez a plugin importálja a letölthető termékeket
  • Beállításai: Bővebben a „Letölthető termék importálása” résznél foglalkozunk vele

Group Price Importer v0.0.4 info

  • Fejlesztette: Tim Bezhashvyly és Dweeves
  • Leírás: csoportos árakat lehet importálni vele
  • Beállításai:
    A csv-ben ezt az oszlopot kell megadni:
    “group_price:groupName” ahol a groupName a vevőcsoport neve.
    Bővebben kifejtem a „Egyszerű termék importálása” résznél.

Image attributes processor v1.0.33a

  • Fejlesztette: Dweeves és Tommy Goode
  • Leírás: ez a plugin importálja a termékekről készült képeket.
  • Beállításai:
    • Image search path: melyik mappákban keresse a képeket (ezeket előzőleg fel kell tölteni a szerverre, ajánlott a media/import mappa), pontosvesszővel kell elválasztani, ha több mappát szeretnénk megadni
    • Image Renaming: átnevezze-e a képeket; hagyjuk üresen, ha az eredeti fájlnevet szeretnénk megtartani.
      Itt lehet dinamikus változókat használni.
      Ha szeretnénk átnevezni a képet, a következő formátumot javaslom:
      {item.sku}_{meta.attr_code}_{meta.store}.{meta.imagename.ext}
    • Image import mode: importálás módja
      • Keep existing images: ebben az esetben nem írja felül, vagy nem fogja letölteni (távoli url-ről) azokat a képeket, amelyek ugyanazon a néven léteznek.
      • Overwrite Existing Images: felülírja és újra letölti (távoli url-ről) az ugyanazon a néven szereplő képeket.
    • Assing only existing images: (ezt a beállítást nem figyeli a rendszer ebben a verzióban)
      • Import into DB: adatbázisba importálja-e; ezt csak akkor állítsuk Enabled-re, ha be van állítva a Magento-nkba a Media storage.
      • Debug mode: hibakeresés be legyen-e kapcsolva
      • Remote Image root: tavoli képek útvonala (ha nincs, üresen kell hagyni)
      • Remote root Authentication: szükség van-e távoli bejelentkezésre
      • Pre-download check: (ezt a beállítást nem figyeli a rendszer ebben a verzióban)

On the fly indexer v0.2

  • Fejlesztette: Dweeves
  • Leírás: ez a plugin importáláskor ír néhány index táblába (url_rewrites és a category_products)
  • Beállításai:
    • URL endings: url végződések, legyenek-e használva, és ha igen, akkor mik legyen azok.
    • Use Categories in Url: kategoriák legyenek-e az url-ben

Custom Options v0.0.7a

  • Fejlesztette: Pablo és Dweeves
  • Leírás: ezzel a plugin-nal lehet beimportálni a termékekhez az egyedi opciókat
  • Beállításai: a következőképp kell beállítani a csv-ben a custom optionokat:
    Name:Type:Is Required:sort number
    vagyis pl. Size:drop_down:1:1, és a terméksorba pedig pl: Small|Medium|Large
    A többi részletes variációt megtalálhatjuk a plugin dokumentációs oldalán.

Product Deleter v0.0.2

  • Fejlesztette: Dweeves
  • Leírás: ezzel a plugin-nal termékeket lehet törölni
  • Beállításai:
    • Delete Children products: törölje-e az alá tartozó termékeket. Ez a konfigurálható és kötegelt termékeknél lényeges.
      A csv-be új oszlopként fel kell venni a magmi:delete-et, és a törlendő termékeknél 1-re kell állítani.

Product Tags Importer v0.0.3

  • Fejlesztette: Dweeves, Pawel Kazakow
  • Leírás: termék címkéket lehet importálni vele
  • Beállításai:
    csv-ben vesszővel elválasztva kell beírni a címkéket a tags oszlopba

Tier price importer v0.0.9a

  • Fejlesztette: Dweeves, bepixeld
  • Leírás: ezzel lehet mennyiségre vonatkozó, kedvezményes árat importálni
  • Beállításai:
    Bővebben az „Egyszerű termék importálása résznél” foglalkozunk vele.

Weee Tax importer v0.0.5

  • Fejlesztette: Garbocom & Dweeves
  • Leírás: ezzel lehet a Weee-ket, vagyis környezetvédelmi adókat importál
  • Beállításai:
    • Weee Tax Attribute name: a környezetvédelmi adó jellemző kódja
    • Weee Tax Country code: az adó ország kódja (pl. FR)

Column mapper v0.0.3b

  • Fejlesztette: Dweeves
  • Leírás: ezt a plugin-t akkor érdemes használni, ha az import fájlban eltérőek az oszlopok nevei a Magento jellemzőkódoktól.
  • Beállításai:
    • Mapped columns list: ide kell felsorolni, vesszőkel elválasztva a Magento-ban szereplő jellemzőkódokat
    • New name for col X: ide írjuk be az import fájlban szereplő nevét az adott jellemzőnek (ha a Mapped columns listbe újat írunk be, akkor jelenik meg a New name for col …)

SKU Finder v0.0.3

  • Fejlesztette: Dweeves
  • Leírás: ezt a kiegészítőt akkor kell használnunk, ha nem adjuk meg az import fájlunkban az SKU vagyis cikkszám oszlopot, helyette egy másik termékjellemző alapján kell összepárosítani
  • Beállításai:
    • sku find attribute code: a párosítandó jellemző kódja.

Default Values setter v0.0.5

  • Fejlesztette: Dweeves
  • Leírás: ezzel lehet beállítani az olyan értékeket, amelyek mindegyik jellemzőnél ugyanazok, így nem kell az import fájlba beírni
  • Beállításai:
    • Default attribute list: vesszővel elválasztva be kell írni a jellemző kódjait, ahogy a Magento-ban szerepel, majd az alatta lévő oszlopokba pedig az értéket

Magmi Import Limiter v0.0.7

  • Fejlesztette: Dweeves
  • Leírás: ezt akkor kell használni, ha limitálást szeretnénk az importjainkra tenni, vagyis pl. csak bizonyos jellemzőket szeretnénk beimportálni, vagy csak bizonyos sortól sorig használni azokat.
  • Beállításai:
    • Column filter: melyik jellemzőket importáljuk, pl. sku,price,qty
    • Limiter ranges: pl. 1-100, vagyis hogy melyik sortól kezdve meddig importáljon
    • Limiter filters: csak azokat a termékeket importáljuk, amelyek bizonyos szűrési feltételnek megfelelnek,
      pl. sku::00.* – vagyis csak azokat a cikkszámokat importálja, amelyek 00-val kezdődnek
      pl. sku:00.*;;!name::.*blue.* – vagyis a 00-val kezdődő cikkszámokat és a név nem blue-val kezdődik.

Generic mapper v0.0.6a

  • Fejlesztette: Dweeves
  • Leírás: ezzel a plugin-nal a Magento-s értékekkel való értékpárosítást lehet elvégezni. Tipikus jellemző a page_layout és a visibility.
  • Beállításai:
    Ha szeretnénk használni, akkor az adott jellemzőre létre kell hoznunk a jellemző nevével egy csv fájlt a „magmi/plugins/itemprocessors/genericmapper/mappings” könyvtárba, pl. „magmi/plugins/itemprocessors/genericmapper/mappings/is_recurring.csv”
    Ennek a tartalmába be kell az érték párost írni. pl.
    „Yes”,1
    „No”,0
    Részletesebb leírást a plugin dokumentációjában olvashatunk.

Value Replacer v0.0.8a

  • Fejlesztette: Dweeves
  • Leírás: ezzel a plugin-nal jellemzők értékeit tudjuk lecserélni. Dinamikus változókat is használhatunk, vagyis pl. ha az összes termék cikkszámához szeretnénk perfixet tenni, akkor a következőképp kell beírni a mezőbe: prefix-{item.sku}
  • Beállításai:
    • Replaced attributes: fel kell sorolni a jellemzőkódokat, amelyeknél szeretnénk cserélni az értéket (vesszővel elválasztva)
    • New value for X: ide kell beírni az értéket
      További leírás a dokumentációban található.

Value Trimmer for select/multiselect v0.0.3

  • Fejlesztette: Dweeves
  • Leírás: ez a plugin automatikusan levágja az üres helyeket a többszöri vagy sima kiválasztós jellemzők értékénél
  • Beállításai: nincs

Grouped Item processor v1.4.1

  • Fejlesztette: Alpine Consulting, Inc & Dweeves
  • Leírás: ezzel lehet csoportos termékeket importálni
  • Beállításai:
    • Perform simples/group link: összekapcsolja-e az egyszerű termékeket a csoportos termékkel.
    • auto match simples skus before grouped: ezzel tudjuk beállítani, hogy automatikusan keresse-e meg a csoportos termékhez tartozó egyszerű termékeket, ha nem, akkor az import fájlban léteznie kell a „grouped_skus” oszlopnak, ahol pontosvesszővel elválasztva fel kell sorolni a hozzá tartozó egyszerű terméket.
    • Force simples visibility: az egyszerű altermékek láthatóságát állítsa-e, ha igen, akkor mire.

Bundle Item processor v1.1

  • Fejlesztette: Björn Tantau, Dweeves, igi8819
  • Leírás: Kötegelt termékeket importálhatunk vele
  • Beállításai:
    A „Kötegelt termékek importálása” résznél bővebben kitérünk rá, de mindegyik beállítás arra szolgál, hogy beállítsa az értékeket a megadott típushoz, abban az esetben, ha az import fájlban nem írjuk be azokat.

Configurable Item processor v1.3.7a

  • Fejlesztette: Dweeves
  • Leírás: Segítségével onfigurálható termékeket lehet importálhatunk.
  • Beállításai: ugyanazok, mint a csoportos terméknél, melyek fentebb olvashatók.

Cross/Upsell Importer v1.0.3

  • Fejlesztette: Dweeves
  • Leírás: Segítségével cross- és upsell termékeket importálhatunk.
  • Beállításai:
    Az import fájlban két új oszlopot kell beírni:
    us_skus – Upsell
    cs_skus – Cross sell
    Mindkettőnél cikkszámokat kell felsorolni, vesszővel elválasztva.

Product relater v1.0

  • Fejlesztette: Dweeves, jwtechniek
  • Leírás: Segítségével hasonló termékeket impotálhatunk.
  • Beállításai:
    Az import fájlban a re_skus oszlopba kell beírni a cikkszámokat.
    Részletesebb leírást a plugin dokumentációban olvasnhatunk.
    A plugin beállításait a lenti Save Profile gombbal kell elmenteni.

 

Egyszerű termék importálása

Egyszerű-termék-importálás

Első lépésként fontos, hogy konfiguráljuk a plugin-ok legfontosabb beállításait.
Ezután leírjuk, hogyan is kell egy import fájlt létrehozni. Mint ahogy az elején említettük, ezt egy CSV-fájlon keresztül fogjuk bemutatni.

Mielőtt azonban nekikezdenénk, bizonyosodjunk meg róla, hogy van olyan programunk, ami alkalmas a CSV-fájlok kezelésére. Amennyiben még nem rendelkezel ilyennel, azt javasoljuk, hogy szerezd be a következő két, ingyenes program valamelyikét:

  • Open Office (azon belül is a Calc)
  • Libre Office (azon belül is a Calc)

Fontos, hogy a CSV-t mindig UTF-8 beállítással és a megadott elválasztó paraméterekkel kell megnyitnunk/mentenünk.

Magmi CSV szöveg import

Miután megnyitottuk, a következő oszlopokat kell beírni fejlécként a CSV-be:

  • sku: termék cikkszáma, ezzel fogja a rendszer módosításkor beazonosítani a meglévő terméket
  • attribute_set: jellemzőhalmaz neve, ugyanúgy kell beírnunk, mint ahogy a Magento-ban szerepel, pl. Default
  • type: a termék típusa, lehetőségek:
    • simple – egyszerű
    • configurable – konfigurálható
    • downloadable – letölthető
    • bundle – kötegelt
    • grouped – csoportos
    • virtual – virtuális
  • websites: Ez a 0.7.17 verziótól elavulttá vált.
  • store: ide kell beírni, hogy melyik store view-hoz rendeljük hozzá (mindig a store view kódot kell megadnunk). Ezzel lehet a nyelvesítést elvégezni, amit bővebben a „Többnyelvű importálás” résznél fejtünk ki. Ha egy store view-nk van, vagyis egynyelvű az áruházunk, akkor nem kell, hogy szerepeljen az import fájlban. Illetve a képen látszik, hogy admin van beírva a store-nak, ilyenkor ez ugyanaz, mintha be se írtuk volna az oszlopot.
  • categories: ide kell beírni, hogy mely kategóriákhoz rendeljük a terméket (ha nincs bekapcsolva az „On the fly category creator/importer v0.2.5” plugin, akkor a beírt kategóriáknak léteznie kell a rendszerben, még mielőtt importálunk. A beírt adatok szintaxisa:
    • Kategória1
    • Főkategória/Alkategória
    • Kategória1;;Kategória2 – vagyis ha több kategóriába is beletartozik egy árucikk, akkor kettő darab pontosvesszővel kell elválasztani
    • Kategória1/Alkategória1;;Kategória1/Alkategória2;;Kategória2/AlKategória3
  • name: a termék neve
  • description: termék hosszú leírása, html tag-ek engedélyezve vannak
  • short_description: termék rövid leírása, html tag-ek engedélyezve vannak
  • price: a termék ára, itt mindig az alapértelmezett pénznemben kell beírni, adó nélkül (tehát nettó árat), pl. 150
  • special_price: a termék kedvezményes ára, ha nincs, akkor 0
  • special_from_date: ha a terméknek van kedvezményes ára, akkor ide be lehet írni, hogy mikortól legyen akciós (pl. 2016-05-20), ha mindig, akkor üresen kell hagynunk
  • special_to_date: meddig legyen akciós a termék, üresen hagyva a végtelenségig akciós lesz
  • news_from_date: újdonságnak jelölt termék kezdeti dátuma
  • news_to_date: újdonságnak jelölt termék befejezési dátuma
  • qty: ha van készletkezelés, akkor a termék raktáron lévő mennyisége (pl. 5)
  • in_in_stock: van-e raktáron, értékek: 1 – igen, 0 – nem
  • manage_stock: használja-e ennél a terméknél a raktárkezelést (ha használunk raktárkezelést, ki lehet egyes terméknél kapcsolni, hogy legyen-e vagy sem), értékek:1 – igen, 0 – nem
  • use_config_manage_stock: használja-e a rendszerbeállításban megadott raktárkezelést. Ha állítani akarjuk az előbbi manage_stock értéket, akkor itt 0-át kell megadni, hogy ne a rendszerbeállításból olvassa ki az értéket, hanem az ennél a terméknél megadott manage_stock értékből.
  • status: engedélyezve van-e a termék, értékek: 1 – igen, 0 – nem
  • visibility: a termék láthatósága, értékek:

1 – egyedileg nem látható, ezt általában a konfigurálható, csoportos termékeknél szokták használni. Ebben az esetben a termékadatlap sem érhető el, a többinél a termékadatlap elérhető
2 – csak a katalógusban, vagyis a kategória oldalakon látható, a keresésnél nem
3 – Csak a keresésnél látható
4 – Mindenhol látható

  • weight: a termék súlya, pl. 0.5. Ha ezt nem szeretnénk használni, akkor a jellemzőnél át kell tenni, hogy ne legyen kötelező megadni.
  • tax_class_id: az adóosztály id-je vagy a neve, pl. Taxable goods
  • thumbnail: a termék bélyegképe, pl. ball-for-football.png
  • small_image: a termék kis képe
  • image: a termék főképe
  • media_gallery: termékgaléria, itt a képek nevét pontosvesszővel kell elválasztani, pl. ball-for-football.png;ball-for-football2.png

Magmi CSV minta

 

A képeket csak akkor fogja importálni a rendszer, ha a „Image attributes processor v1.0.33a” plugin be van kapcsolva.

Természetesen a többi jellemzőt bele kell írni az import fájlunkba.

A select, vagyis egyszeri kiválasztós jellemzőknél a szöveges értéket kell beírnunk. (pl. a color jellemzőnek a Red szót írhatjuk.)

A többszöri kiválasztós értékeknél ugyanúgy kell tennünk, mint a select-nél, csak ha több értéke van, akkor a Magmi beállításában megadott Multiselect Separator-nál megadott karakterrel kell elválasztanunk (pl. Red|Green|Blue)

Magmi csoportos ár

Hogyan kell csoportos árat (Group Price) importálni?

A csoportos ár importálásához a CSV-fájlba fel kell vennünk egy “group_price:groupName” oszlopot, ahol a gropName a csoport neve, ahogy a Magento-ban szerepel.

Ha több csoporthoz szeretnénk árat importálni, még ha egyformát is, akkor külön oszlopba be kell azt beírnunk.

Ha nem létezik az adott vásárlócsoport, akkor a Magmi létre fogja azt hozni.

Hogyan kell mennyiség kedvezmény árat (tier prices) beállítani?

Az import fájlban egy új oszlopként be kell írnunk a következőt:
tier_price:group1 – ahol a group1 a vásárló csoport nevét jelöli.

Ha szeretnénk, hogy az összes csoportra érvényes legyen, akkor tier_price:_all_
Ha több csoportnak szeretnénk beállítani, akkor ugyanúgy, mint a csoportos árnál, új oszlopban kell felsorolnunk.

A terméksorba pedig:
25:10.00;50:9.00;100:8.00 – ami annyit jelent ebben az esetben, hogy 25 mennyiségnél vagy felette 10-be, 50 felett 9-be, 100 felett pedig 8-ba kerül.

Százalékos kedvezményt is meg lehet adni, ilyenkor pl. 25:85%, vagyis 25 mennyiségnél vagy felette 85 százalékos kedvezményt adunk.

Magmi CSV kedvezmény ár

Hogyan tudom a termékeket hozzárendelni a több website-os áruházban?

Ha olyan áruházat üzemeltetünk, mely egyszerre több weboldallal is rendelkezik, és vannak olyan termékeink, amelyek csak egyes oldalakon érhetők el, akkor a CSV-ben a store oszlopba azokn üzletek a store_view kódjait kell felsorolnunk, amelyekben a termék elérhető. Bemutatom egy példával:

8-Magmi-egyszeru-weboldal-aruhaz

A következő képen látható, hogy van 2 weboldalunk. Mindkettőnél 1 store van, az US store-nál csak angol nyelv, az EU store-nál pedig három nyelv is szerepel.
American English store_view kódja legyen:us, eu store-nál az Engilsh legyen: en, a German: de, a Hungarian pedig: hu.

  • Ha pl. a test 1-es termékünk, csak az us websopban van, akkor a store oszlopba az us kódot írjuk be.
    • Ha pl. az test 2-es termékünk csak az eu storokban szerepel, akkor fel kell sorolni mind a 3 nyelvet, vagyis en,de,hu
    • Ha a termék mindegyiknél szerepel, akkor az admin szót kell beírni.

Magmi egyszerű weboldal áruház csv

A többnyelvűség beállításával a „Többnyelvű importálás” részben bővebben foglalkozunk.
Itt található példa egy egyszerű termék importjára: magmi_simple_example.csv

Hogyan kell importálni?

A Magmi oldalán láthatunk egy Run Magmi feliratot, ott kell kiválasztanunk, hogy melyik profil alapján, milyen módban szeretnénk elvégezni az importálást.

Importálás után szükséges a reindexálás kell (reindex plugin a Magmiban is elérhető), illetve törölni ekll a cache-t a Magento-ban.

  • Update existing items only, skip new ones: csak a már Magento-ban létező termékeket frissíti, az újakat figyelmen kívül hagyja.
  • create new items & update existing ones: újakat is és a meglévőket is frissíti
  • create new items only, skip existing ones: csak az újakat hozza létre

Ezután a run import gombot kell megnyomnunk az importálási folyamat elvégzéséhez.

Konfigurálható termék importálása

A konfigurálható termék importálás funkció eléréséhez be kell kapcsolnunk a „Configurable Item processor” plugin-t. A konfigurálható terméknél most csak az egyszerű termékhez képesti különbségeket foglaljuk össze, mivel a többi beállítás gyakorlatilag megegyezik.

Magmi CSV konfigurálható termék

A konfigurálható termék több egyszerű termékből áll össze. Az import fájlban mindig az egyszerű termékeket kell előre tenni, és utána jön a konfigurálható termék.

Konfigurálható termék importálásakor először is meg kell adnunk, hogy mely jellemzők lesznek választhatóak a vásárlók számára (pl. méret, szín).
Csak „Globális” hatókörű, „Lenyíló” típusú jellemzőt lehet használni konfigurálásra és be is kell, hogy állítsuk a jellemzőnél, hogy konfigurálásra használható.

Fontos továbbá, hogy az a jellemző az adott jellemzőhalmaz része legyen.
Ha nem írjuk bele a fájlba a párosítandó cikkszámokat, akkor a plugin-ban be kell kapcsolnunk, hogy automatikusan megkeresse az altermékeket („auto match simples skus before configurable”), ilyenkor a cikkszámot a következőképp kell elnevezni:

Magmi CSV konfigurálható auto match

A konfigurálható cikkszáma (pl. testconf) Az altermékek cikkszáma: testconf1*** – a csillag helyére bármi mást be lehet írni, javasolt a konfigurálható jellemző értéke, (pl. testconf1-white-s, testconf1-white-m).

Ha pedig egyedi cikkszámot szeretnénk a termékeknél, akkor a simple_skus oszlopba kell beírni, hogy mely cikkszámok tartoznak alá.
Ha eltér az altermékek ára (pl. az M-es méretű drágább, mint az L-es) akkor a fájlba be kell írnunk a „super_attribute_pricing” oszlopot, amibe a konfigurálhatónál a következőképp kell  megadni:
jellemzőkód::érték:ár;érték:ár, jellemzőkód::érték:ár;érték:ár

vagyis pl. size::L:43;M:55

Ha fix ár helyett százalékos növelést szeretnénk, akkor pedig:
jellemzőkód::érték:ár:százalékos-e;érték:ár:százalékos-e
size::L:15:1;M:20:1 – vagyis, ha 1-es, akkor százalék, ha 0 akkor fix ár.

Ha nem adjuk meg ezt az értéket, a rendszer alapból fix árat fog használni.

Magmi CSV konfigurálható példa

Itt található egy konfigurálható termék import példa: magmi_configurable_example.csv

Kötegelt termék importálása

Ebben a részben azt mutatjuk be, hogy mit kell beállítani az import fájlban annak érdekében, hogy kötegelt termékeket tudjunk importálhassunk.

A Magmi plugin-jai között először is kapcsoljuk be a „Bundle Item processor” plugin-t.
Itt ugyanúgy kell létrehozni és kitölteni a CSV-fájlt, mint az egyszerű terméknél, ezért csupán a két módszer közötti különbséget mutatjuk be.

A következő oszlopokat kell beletennünk:

bundle_options:

Magmi CSV kötegelt opciók

-*;Code,Option name;type:is_required;position

pl.

-*;CPU:Central Processing Unit:radio:1:0;RAM:Random Access Memory:select:1:1;MOUSE:Mouse:checkbox:0:2

Ahol:

  • -* ha ezt az elejére írjuk, akkor a rendszer törli az előzőleg beírt opciókat a Magento-ból. Ha ezt nem írjuk, akkor a meglévőkhöz hozzáteszi a beírtakat.
  • Code: ez lesz a kódja az opciónak, ezt használjuk a bundle_skus-nál az összepárosításra
  • Option name: ez a neve az opciónak, ez a szöveg fog látszódni a terméknél
  • type (radio, checkbox, select, multi): ez az opció típusa
  • is_required: kötelező-e a vásárlónak választani az adott opcióból (1-igen, 0-nem)
  • position: a termék adatlapon milyen sorrendbe jelennek meg (számokat kell írni)
  • bundle_skus:

Magmi CSV kötegelt SKUS

Code:sku:selection_qty:can_change_qty:position:is_default:selection_price_value:selection_price_type
pl.
CPU:cpu1:1:0:1:1:0:0;CPU:cpu2:1:0:0:1:0:0;RAM:ram1;RAM:ram2;MOUSE:mouse1:1:0:0:1:50:1

Ahol:

  • Code: a bundle_options-nál is megadott kód
  • sku: az altermék cikkszáma
  • selection_qty: a kosárba helyezés mennyisége
  • can_change_qty: kiválaszthatja-e a vásárló, hogy az adott opcióból mennyit vásárol
  • position: opciók pozíciója
  • is_default: alapértelmezett-e az adott opció
  • selection_price_value: a kiválasztás ára (ez csak akkor érvényesül, ha a csv-ben a bundle-nél vagy a plugin beállításánál a price_type 1-re (Percent) van állítva
  • selection_price_type: az ár típusa (0 – Fixed, 1 – Percent)
  • price_view: az ár megjelenési típusa, 1 (Legkisebb ár, amelyen megveheti), 0 (ár tartomány, tehát x összegtől y összegig)
  • price_type: ár számítási típusa, 0 – dinamikus, 1 – fix ár
  • options_container: Hol jelenítse meg az opciókat (container1, container2), ez témától függ
  • shipment_type: a kötegelt elemek szállítása, 1 – elkülönítve, 0 – egyben
  • sku_type: cikkszám típusa, 0 – dinamikus, 1 – fix
  • weight_type: súly típusa, 0 – dinamikus, 1 – fix

Magmi CSV kötegelt egyéb

Importálás után csináljunk egy reindexet és cache-frissítést. Ha mindent jó állítottunk be, akkor a képen látható módon kell a termék adatlapnak megjelennie.

16-Magmi-kotegelt-Frontend

Itt található egy kötegelt termék import példa: magmi_bundle_example.csv

Csoportos termék importálása

A csoportos termék beállításai nagyon hasonlóak a konfigurálható termékéhez.
Először is, a Magmi plugin-jai között be kell kapcsolnunk a „Grouped Item processor” plugin-t. Eztuán az import fájlba a grouped_skus oszlopot kell beillesztenünk, amiben az egyszerű altermékek cikkszámai szerepelnek.

17-Magmi-csoportos-pelda

Itt található egy példa a csoportos termék importjára: magmi_grouped_example.csv

Letölthető termék importálása

A letölthető termék importfájlja hasonló az egyszerű termékéhez. A „links” oszlop kell bele, amit a következőképp kell kitölteni:

file:link,sort_order :position,title:file title,sample :example link,is_shareable :config or 0 or 1,number_of_downloads :value

  • file: ide kell a letölthető fájl linkje, url vagy teljes útvonal, ha lokálisan szerepel
  • sort_order: pozíció (ha több links van)
  • title: fájl neve
  • sample: betekintő fájl
  • is_shareable: a vásárló megoszthatja-e mással a fájlt
  • number_of_donwloads: hányszor töltheti le a fájlt

Ha több fájlunk van, akkor csak a fenti sort kell duplázni, pontosvesszővel elválasztva (pl. file:https://aionhill.com/test.zip,sort_order:1,title:Test,sample:,is_shareable:1,number_of_downloads:100;file:https://aionhill.com/test2.zip,sort_order:2,title:Test2,sample:,is_shareable:0,number_of_downloads:1; )

Magmi letölthető példa

Itt található egy letölthető egy példa a letölthető termék importjára: magmi_downloadable_example.csv

Virtuális termék importálása

Virtuális termék importálása ugyanaz, mint az egyszerű terméké, annyi a különbség, hogy a type nem simple, hanem virtual.

Magmi Virtuális példa

Itt található egy példa a virtuális termékimportra: magmi_virtual_example.csv

Jellemző és jellemzőhalmaz importálása

Jellemző vagy jellemzőhalmaz importjához először is be kell kapcsolnunk és beállítanunk az „Attribute Set Importer” plugin-t.
Itt három CSV import fájlt kell létrehozni: egyet a jellemzőkre, egyet a jellemzőhalmazokra és egyet a párosításokra.
A jellemzőnél kötelezően meg kell adnunk az attribute_code-ot, vagyis a jellemző kódját (pl. color).
A többi oszlop megadása nem kötelező, csak akko, ha nem az alapértelmezett értéket szeretnénk használni.

Jellemző, magmi

A jellemzőcsoport esetében meg kell adnunk az attribute_set_name-et, vagyis a jellemzőcsoport nevét (pl. Ruházat).
A többi oszlop megadása nem kötelező, csak akkor szükséges, ha nem az alapértelmezett értéket szeretnénk használni.

Jellemzőhalmaz, Magmi

A jellemző és jellemzőcsoport párosításánál pedig a következőket kell megadnunk:

  • attribute_set_name: jellemzőhalmaz neve
  • attribute_code: jellemző kódja
  • attribute_group_name: melyik jellemzőcsoportba kerüljön a halmazon belül

Jellemzőhalmaz, Magmi, jellemző, párosítás

Termékkategóriák importálása

A termékkategóriák a termék importáláskor jönnek létre, ha a Magmi-ban be van kapcsolva az „On the fly category creator/importer” plugin.
Leggyakrabban a képen látható beállítás alapján használják a plugin-t.

Magmi kategória importer beállítás

Ez alapján a következőképp kell a CSV-ben a kategóriát beállítanunk.

Magmi kategória Importer CSV

A képen látható példában a termék a „Football” főkategóriában szereplő „Ball” és „Accessories” kategóriákba fog bekerülni.

A per (/) jellel lehet az alszinteket megadni, pl. Elsőszintű/Másodszintű/Harmadszintű.
A kettő darab pontosvesszővel tudjuk több kategóriába is besorolni, pl. Elsőszintű/Másodszintű/Harmadszintű;;MásikElsőszintű/MásikMásodszintű/MásikHarmadszintű
Új kategóriáknál megadhatjuk azt, hogy aktív-e, link-e, és hogy a navigációs menüben benne legyen-e, szintakszisa: category name::[is_active]::[is_anchor]::[include_in_menu]
pl. Football/Ball::1::0::0

Többnyelvű importálás

Többnyelvű (ami több store view-t jelent, ahol webáruházunk más-más nyelven jelenik meg) importálásnál minden terméket annyiszor kell a beírnunk az import fájlba, ahány nyelven azt szeretnénk megjeleníteni.

magmi többnyelvű importálás

Ahány nyelv, annyi sor, a store oszlopba kell beírni annak a store_view-nak a kódját amelyik nyelvű boltnézetbe szeretnénk beletenni.

A kategóriáknál sajnos a rendes fordítás nem megoldott, így vagy adminból fordítunk, vagy minden nyelvnek saját kategóriafát hozunk létre, pl.:

  • English Root
    • Ball
  • German Root
    • Ball
  • Hungarian Root
    • Labda

A name, description stb. oszlopba az adott nyelven kell beírni a szövegeket.

A lenyílós jellemzőknél a következőképp:
Adott nyelvű érték::[Admin érték]
Az első elem az adott nyelven megírt fordítása, a kapcsos zárójelbe kell az admin vagyis a default nyelven létező string-et írnunk. (pl. Red::[Red], Piros::[Red] )

Itt található egy példa többnyelvű importra: magmi_multilanguage_example.csv

Összegzés

A Magmi előnyei:

  • Telepítése és beállítása egyszerű
  • Használata felgyorsítja a munkát (egyszerre akár több ezer terméket is pár perc alatt importálhatunk a segítségével)
  • mind a 6 terméktípus importálására képes
  • automatizálható (vagyis automatikusan futó importokat is létrehozhatunk)

A Magmi hátrányai:

  • az importfájlok létrehozása kicsit bonyolult, maximális pontosságot igényel annak érdekében, hogy minden adat megfelelően jelenjen meg
  • mivel nyílt forráskódú, így sajnos akadnak benne apróbb hibák, egyes kiegészítők nem működnek mindig tökéletesen
  • a termék mentésekor futó observerek enm futnak le, mivel direkt SQL-el dolgozik
  • a Magento mellett még egy adminisztrációs felület használatát meg kell tanulnunk

Reméljük, sikerült minden részletre kiterjedően bemutatnunk a Magmi tulajdonságait, beállításait és használatát. Ha bármilyen témába vágó megjegyzésed vagy kérdésed lenne, ne habozz megírni alább, a komment részlegben. Ahol tudunk, segíteni fogunk abban, hogy a Magento és a Magmi segítségével te is kihozhasd saját webáruházadból a maximumot!

 

Magento 1 vs. Magento 2: 15 ok, amiért Magento 2-re érdemes váltanod

Jelenleg is rengeteg webáruház használja aktívan a Magento 1.x verziójú rendszereket, azonban ha eddig nem tettük meg, itt az idő az átállásra. A Magento ugyanis hamarosan véglegesen megszünteti a 2.0 előtti rendszerek támogatását, ami az jelenti, hogy a korábbi verziók sem biztonsági, sem minőségbeli frissítést nem kapnak majd a fejlesztőktől.

 

Ebben a cikkben megmutatjuk miért érdemes minél hamarabb átállni a 2.0 rendszerre, és hogyan lehet a váltás folyamata zökkenőmentes.

A Magento 2.0 béta verziójának megjelenését a fejlesztők már 2010-ben bejelentették, maga a rendszer pedig 2015-ben vált elérhetővé. Ez nem tegnap történt, több ezer e-kereskedő azonban máig nem szánta rá magát arra, hogy 1.x verziójáról az újabb, több lehetőséget kínáló megoldásra váltson. Ennek több oka is lehet, a leginkább általános azonban az újítástól, valamint az ezzel járó teendőktől való félelem.

Most azonban eljött az idő. 2020 júniusában ugyanis a Magento 2.0 előtti verzióinak hivatalos támogatását a fejlesztők végleg megszüntetik.

A továbbiakban sorra vesszük a váltással kapcsolatos, fontos szempontokat: A szükséges fejlesztéseket, az új funkciókat, az átálláshoz szükséges büdzsét.Valamint azt, hogy a régi rendszer a hivatalos támogatás elvesztése után meddig, milyen formában, illetve milyen kockázatok mellett lesz használható.

Az alábbi a pontokon fogunk végighaladni:

    • A Magento 2-ről általában
    • Mikor érdemes váltanod?
    • Mennyire problémás a migráció?
    • Fejlesztés
    • Fejlesztési büdzsé
    • A közösségi faktor
    • A Magento 2 újításai
      1. Skálázható, gyorsabb rendszer
      2. Reszponzív, jól böngészhető
      3. Könnyített fizetés
      4. Elasticsearch
      5. Olcsóbb, könnyebb frissítés
      6. Ajax add-to-cart
      7. Egyszerűbb navigáció
      8. Elkülönített adatbázisok
      9. Dashboard
      10. Egyszerűbb termékfeltöltés
      11. Hatékonyabb perszonalizáció
      12. Platformkompatibilitás
      13. Hardverkövetelmények
      14. Hatékonyabb tesztelés
      15. Egyszerűbb integráció
    • Mikor avul el a Magento 1.x?
    • Megéri vagy sem?

 

A Magento 2-ről általában

Magento 1

A Magento 2 megjelenésével alapjaiban változott meg a jól ismert webáruház-rendszer mögött álló szoftver, melyet világszerte e-kereskedők százezrei használnak.

A fejlesztők stratégiája az új verzió létrehozása során egyértelműen az új rendszer megerősítése, funkcióinak bővítése volt, elsősorban úgy, hogy a nagyvállalatok számára különösen vonzóvá tegyék a Magento 2-t.

A funkcionalitás sok szempontból javult, de az új verzió alapvetően három téren hozott komoly előrelépést:

  •  technológiai szinten,
  • · modularitásban (backend és frontend szinten egyaránt),
  • · illetve teljesítményben.

A Magento 2 éppen elődeinél sokkal jobban képes alkalmazkodni a mai modern, többcsatornás értékesítési környezethez. Használatával a kereskedők munkáját a teljesítmény és biztonság növekedését szolgáló fejlesztések mellett továbbgondolt, kibővített szolgáltatások is segítik.

Páratlan rugalmassága lehetővé teszi a kereskedők számára azt, hogy a lehető legkisebb kiadások mellett, rekordidő alatt biztosítsák a tökéletes kereskedelmi élményt.

Annak érdekében pedig, hogy a rendszer minden elvárásnak megfeleljen, negyedévente új funkciókat kap a hivatalos fejlesztőcsapattól. Ez egyaránt érvényes a Magento ingyenesen használható Community, valamint a prémium, Enterprise változataira is.

Mikor érdemes váltanod Magento 1-ről Magento 2-re?

Ha egészen idáig Magento 1.x verziójú webshopot használtál, nem feltétlenül kellett azzal foglalkoznod, hogy a 2.0 rendszerre válts, hacsak az általad használt verzió nem volt túlzottan elavult, és nem jelentkeztek a működéssel kapcsolatos problémák.

Most azonban felforrósodott a talaj, és ha hosszabb távra tervezel, mindenképp itt az ideje annak, hogy Mageto 1.x motorral működő webshopodat új alapokra helyezd.

A korábbi rendszerek ugyanis 2020 júniusában kapják meg az utolsó, hivatalos biztonsági és szoftveres támogatást.

Sőt, ami ennél is fontosabb, hogy a Magento 1.x által használt PHP 5.6 támogatása már lejárt, ez pedig csak tovább sürgeti az új rendszerre történő átállást.

A hír persze nem újdonság. Az eredeti tervek szerint ugyanis a Magento 1 szoftveres támogatásának már 2018 novemberében le kellett volna állnia. A fejlesztők azonban belátták azt, hogy számos olyan kereskedő használja a rendszer különböző verzióit, akiknek a 2.0-ás verzióra történő, sikeres átállás több időt vehet igénybe.

Ennek érdekében a támogatás leállításának időpontját 18 hónappal meghosszabbították. Ilyen módon a kereskedőknek 2020 júniusáig van idejük arra, hogy rendezzék soraikat, és végrehajtsák az új rendszerbe történő migrációhoz szükséges feladatokat.

És hogy miért annyira fontos ez?

A támogatás megszűnésével a Magento 1 alapú webhelyek sebezhetősége fokozottan megnövekszik. A folyamatosan frissülő biztonsági szolgáltatások hiányában érzékenyek lesznek a fenyegetésekre, és jóval nagyobb valószínűséggel érheti őket hackertámadás.
Ez azt jelenti, hogy az elavult rendszer használatával nem csak saját vállalkozásod és bevételed, de ügyfeleid adatainak biztonsága is veszélybe kerül.
A váltástól azonban nem kell megijedni, hiszen a Magento 2 számos új funkciót, lehetőséget és újítást hozott magával, amelyek nem csak garantálják webshopod biztonságát, de utat nyithatnak a növekedés felé is. Ilyen módon úgy szolgálhatod ki ügyfeleidet, ahogyan korábban erre nem lett volna lehetőséged.

A konkrét eltérésekről alább beszélgetünk részletesen.

 

Mennyire problémás a migráció?

Nézzünk szembe a tényekkel: a bútorokat, dekorációt, a lakókat átmozgathatjuk egy kalyibából egy palotába, de a plusz emeletet vagy a hozzátoldott garázst nem vihetjük magunkkal.

A migráció sohasem fájdalommentes folyamat, még akkor sem, ha ugyanazon rendszer két verziója között zajlik.

A Magento 2-re való áttérést ugyanilyen komplex tevékenység. Nem tekinthetjük egyszerű „verziófrissítésnek”, valójában ugyanis egy teljesen új, a Magento 1-hez képest lényeges keretbeli különbségekkel rendelkező platformra való áttérésről beszélünk.

Ez némileg megnehezíti a migráció folyamatát, és komoly energiabefektetéssel is járhat.

A termékeket, attribútumokat, adatbázisokat természetesen magaddal viheted a régi keretrendszerből, ezek nélkül aligha érné meg még a fejlesztésekkel együtt is bárkinek a migráció.

Viszont az egyedi fejlesztéseket, a személyre szabott dizájnmegoldásokat sajnos hátra kell hagynod. Vagy ha meg akarod őket tartani, akkor a Magento 2 alapú rendszeredre újra kell őket fejlesztetned.

Minden kiterjesztést és egyéni kódot felül kell vizsgálni, át kell írni, és kompatibilissé kell tenni a Magento és a PHP újabb verzióival is.
Azonban ha ránk hallgatsz, akkor erre nem visszahúzó erő, hanem egy hatalmas lehetőségként tekintesz. Hogy miért?

Az átmeneti erőfeszítést nem más, mint a siker érdekében nélkülözhetetlen, újjáépítési folyamat. Igen, valóban pluszmunkát jelent és pluszköltségekkel is járhat, azonban arra is rákényszerít, hogy ahol csak lehet, megújulj, és magad mögött hagyd a vállalkozásodat visszahúzó tényezőket.

  • Átgondolhatod, eddig valóban jól csináltál-e mindent,
  • nincsenek-e felesleges elemek az áruházadban,
  • van-e olyan, ami hiányzik, és már régóta beépítenéd,
  • összességében javíthatsz az üzleteden.

A továbbiakban látni fogod azt, hogy a Magento 2 számos újdonságot hozott magával, a migrációt pedig ez az érzékelhető technológiai ugrás teszi nehézkessé.

Nem azért nehéz a váltás, mert egy nehezebb, bonyolultabb rendszerbe költöznek adataid, hanem azért, mert a Magento 2 rengeteg szempontból messze meghaladja az 1.x változatokat, sok új megoldást alkalmaz, és rengeteg lehetőséget tartogat..

Elsőre tehát nagy kihívásnak tűnhet a folyamat, az eddigi tapasztalatok azonban azt igazolják, hogy az adatbázisok migrációja a két rendszer között, különösen az elérhető Data Migration eszköz segítségével, egyáltalán nem jelent problémát.

Az ügyféladatbázisok, termékek, rendelések és hasonló információk átvitelével, jó eséllyel simán megy– de azért érdemes a munkát egy hozzáértő profi segítségével elvégezni, hiszen az ilyen adatbázisok egy webáruház számára a legnagyobb értéket jelentik.

Fejlesztés

Néhány évvel ezelőtt még nehezen találhattunk olyan fejlesztőt, aki a Magento 1 meleltt az új platformon is dolgozott, mára azonban ez a feladat sem jelent különösebb kihívást.
A legtöbb fejlesztéssel foglalkozó cég az elmúlt időszakban már átállt az új keretrendszerre, és a projekteket már a modern elvárásoknak megfelelő, Magento 2 alapon indítják.
Ilyen módon a saját funkciók és kiegészítők tervezése, a régi platformról történő átemelésük is egyszerűbb, gördülékenyebb feladattá vált.

Fejlesztési büdzsé

Az átállás egyéni igények esetén azzal jár, hogy mindenképpen fejlesztőhöz kell fordulnunk.

Azt azonban, hogy pontosan mekkora büdzsé szükséges egy Magento webáruház lefejlesztéséhez, nem tudjuk megmondani. Éppen az a különleges ugyanis ebben a rendszerben, hogy szinte a végtelenségig személyre szabható, az egyéni igényekhez igazítható, ennek következtében viszont nem is lehet általános becslést adni.
A Magento 2 alapon működő webshopok fejlesztése összetett feladat, melynek ára főként a projekt jellegétől és funkcionalitásától függ. Míg korábban azonban jóval többet kellett érte fizetnünk, mint az 1.x verzióval működő oldalakért, mára az árak közt kevés eltérés tapasztalható.

A közösségi faktor

A Magento esetében nagy erősséget jelent, hogy hatalmas és profi fejlesztői közösség áll mögötte. Tekintve, hogy nyílt forráskódú rendszerről beszélünk, rengetegen foglalkoznak napi szintű fejlesztésével, javításával.

Az elmúlt több, mint 10 évben ez a közösség a Magento 1.x változatokat használta, ezekkel dolgozott, így aki a legfrissebb Magento verzióval kapcsolatban szeretett volna fejlesztői segítséget kapni, bármikor hozzájuthatott.

Az elmúlt években szerencsére a közösség tagjai egyre inkább áttértek a Magento 2.0 verziójának használatra, és egyre többen foglalkoznak olyan mélységben vele, mint a rendszer korábbi változatával.

Így ma már az új platform támogatottsága is egyre nagyobb, napról napra gördülékenyebb feladat az esetlegesen felmerülő problémák megoldása.

 

A Magento 2 újításai

Magento 2 áruház

A korábbi verziókhoz képest a Magento 2-ben mind kívül, mind belül rengeteg dolog változott. A kódolástól kezdve a szemmel látható funkciókig és felhasználói élményig szinte minden megújult – néhány főbb szempontot emelünk most ki ezek közül, amelyek jól mutatják, hogy mekkorát fejlődött a Magento a 2-es verzió megjelenésével.

1) Skálázható, gyorsabb rendszer

A Magento 2 használatával a webshop oldalainak betöltési ideje lényegesen csökkenthető, ami által gyorsabbá tehető a vásárlás folyamata és hatékonyan növelhető a felhasználói élmény.

A Magento 2 betöltési ideje messze a sztenderdként meghatározott 3 másodperc alatt van. A főoldal, kategóriaoldalak és termékoldalak is kevesebb, mint 1,5 másodperc alatt töltenek be.

 

Megjegyzés: A szakértők szerint, ha egy weboldalad 3 másodpercnél tovább tölt vagy 3 MB-nál nagyobb, akkor kezdened kell vele valamit, ennek köze van ahhoz is, hogy ennél hosszabb idő elteltével a felhasználók jelentős része elkattint.

Az aktuális felmérések szerint ráadásul nem csak a betöltési sebesség gyorsabb. A Magento 2 használatával 39%-al növelhető a megrendelések feldolgozásának hatékonysága, és akár 51%-al is növelhető a checkout folyamatának sebessége.

Ez többek közt annak is köszönhető, hogy a korábbi verziókkal ellentétben a Magento 2 támogatja a PHP legújabb verzióját.

2) Reszponzív, jól böngészhető

Ami a frontendet illeti, a Magento 2 természetesen reszponzív, ami azt jelenti, bármilyen eszközről böngészhetik a vásárlók. Ez rendkívül sokat jelent, hiszen a Google 2015 óta hivatalosan is előnyben részesíti a mobilbarát oldalakat, a rangsorolásban is.

Emellett pedig természetesen a reszponzivitás a felhasználói élményt is javítja.

3) Könnyített fizetés

Az új rendszerrel a checkout is egyszerűbb lett, könnyebben és gyorsabban fizethetnek az áruért a vásárlók.
Vásárolhatnak vendégként, regisztráció nélkül is, de a regisztrált vásárlókat e-mail címűk alapján már automatikusan meg is keresi a rendszerben a Magento 2.
A checkout-nál lehetőség van a regisztrációra is, ami ugyancsak leegyszerűsödött, a vásárlók ott helyben a fizetésnél hozhatnak létre új felhasználót.

4) Elasticsearch

Az Elasticsearch segítségével javult a webáruházban lefuttatott keresések minősége (Enterprise Edition), a háttérben futó reindexeléssel és horizontális skálázással pedig a felhasználói élmény is emelkedett.
Nem elhanyagolható szempont, hogy az Elastisearch már eleve 33 nyelvet képes kezelni, ezért nyilvánvaló, hogy a Magento fejlesztői a jövőben továbbra is szeretnének a használatára támaszkodni.

5) Olcsóbb, könnyebb bővítményfrissítés

A Magento 1.x rendszerekhez képest jóval egyszerűbbé, és így egyben olcsóbbá is vált az új bővítmények, modulok telepítése.

Korábbi cikkünkben beszéltünk már arról, hogy még ha csak 1-2 tucat alapvető modult akarunk is a Magento 1.x változatokhoz telepíteni, az is rengeteg munkaórájába kerülhet még a profi fejlesztőnek is. Nem számolva azzal, hogy a telepített modulok között problémák, összeütközések is akadhatnak.

Ez a feladat most némileg könnyebbé vált, ahogyan a frontend fejlesztés is egyszerűsödött, köszönhetően a HTML5 és CSS3 csodájának.

6) Ajax add-to-cart

A Magento 1 esetében komoly teljesítménybeli problémát jelent, hogy akárhányszor a kosárba helyezünk valamit, a rendszer újratölti az oldalt.
Ez a folyamat rosszabb esetben másodperceket is igénybe vehet, ha pedig rendszeresen olvasod a blogot, tudhatod, hogy százalékokban mérhető azoknak a felhasználóknak az aránya, akik akár néhány másodperc késlekedés miatt úgy döntenek, hogy elállnak a vásárlástól.

Ha kisebb értékű termékeket forgalmazol, ha eleve több terméket helyeznek a kosárba a vásárlóid, akkor ez olyan probléma, ami felett nem hunyhatsz szemet.

 

Az új rendszernél az Ajax add-to-cart alkalmazása miatt már nincsen szükség arra, hogy egy kosárba helyezés esetén újratöltődjön a teljes oldal, ez pedig mindenképpen pozitívan befolyásolja majd a felhasználói élményt, és hatással lesz a bevételeidre.

7) Egyszerűbb navigáció

A Magento 1 kapcsán a webshopot üzemeltetők egyik legnagyobb fájdalma mindig is az volt, hogy az adminisztrációs felület kissé bonyolult, nehezen kezelhető. Csak azok igazodtak el benne ösztönszerűleg, akiknek korábban is volt már dolguk komplexebb felületekkel.
A Magento 2-es verziójában a fejlesztők egyszerűsítették és modernizálták a navigációs interfészt, így az adminpanelek között sokkal gyorsabban navigálhatunk, egyszerűbben találhatjuk meg a szükséges információkat, és összességében hatékonyabban menedzselhetjük a webáruházat akkor is, ha alacsonyabb felhasználói szinten állunk.

Akinek nincsen saját Magento fejlesztője, annak igazi megváltás lehet az új, egyszerűbb és egyértelműbb adminfelület.

 

8) Elkülönített adatbázisok

A Magento 1-ben a vásárlóknak, adminoknak, és a fejlesztőknek is mind ugyanazt az egy adatbázist kellett használniuk, ez viszont azt jelentette, hogy az könnyen túl is terhelődhetett.

Ha az adminfelületen valamiért túlságosan leterheltük az adatbázist, a vásárlóinknál nehézségek jelentkezhettek.

A Magento 2-ben (Enterprise Edition) megvan a lehetőségünk arra, hogy három külön adatbázist hozzunk létre:

  • egy fő adatbázist,
  • egyet, amelyet a checkout folyamatnál használ a rendszer,
  • és egyet, ahol a rendeléseket tárolja.

Így az az egyik adatbázison keletkező, esetleges terhelés nem befolyásolja majd negatívan a másikat, és nem lassítja le rendszerünket.

9) Dashboard

Hatalmas könnyebbséget jelentő újítás, hogy a Magento 2-ben a legfontosabb információkat végre mind egy helyen találhatjuk meg.
Az átfogó Dashboard kezelőfelület azonnal megmutatja,

  • mennyi eladásunk volt,
  • mekkora az átlagos kosárérték,
  • láthatjuk a legutóbb leadott rendeléseket,
  • a leggyakoribb kereséseket,
  • a legnépszerűbb megtekintett termékeket,
  • az új vásárlókat és így tovább.

Rálátunk a pénzügyi adatokra is, tehát a webáruház általános helyzetéről egy pillanat alatt tájékozódhatunk.

magento 2 admin dashboard

10) Egyszerűbb termékfeltöltés

A Magento 2-ben az új termékek létrehozása is egyszerűsödött.
Az új rendszerben egy egyértelműsített folyamatot lépésről lépésre vezet minket végig mindenen.

A korábbi verziókhoz képest újdonságnak tekinthető az is, hogy most már nemcsak képeket tölthetünk fel az egyes termékekhez, hanem a kor követelményeinek megfelelően videókat is linkelhetünk hozzájuk.

11) Hatékonyabb perszonalizáció

A perszonalizált vásárlói élmény ma már alapkövetelménynek tekinthető egy komolyabb webáruház szempontjából.

Az upsell és cross-sell ajánlatok, a személyre szabott fizetési opciók, akár megjelenés, a korábbi viselkedés alapján adott kuponok mind olyan eszközök, amelyek a Magento 2-ben az e-kereskedő rendelkezésére állnak.

Az on-site viselkedési adatok folyamatos megfigyelésével befolyásolhatjuk azt, hogy a felhasználó milyen tartalmakat lásson, milyen kedvezményeket és milyen ajánlatokat kapjon a rendszertől.

12) Platformkompatibilitás

A Magento 2 támogatja a legfejlettebb webes technológiákat, köztük a CSS3-at, HTML5-öt és természetesen a MySQL-t is.

Újdonság, hogy a prototype.js helyett már jQuery könyvtárat használ.

13) Hardverkövetelmények

A korábbi verzióktól eltérő kódsturktúra és adatbázis egyik legnagyobb előnye, hogy a Magento 2 hardverigényei nem emelkedtek. Sőt, az új rendszernek ugyanolyan teljesítmény eléréséhez kevesebb hardverre van szüksége.

Ez pedig mind költségek, mind a kezelhetőség szempontjából kiváló hír.

Az új hardver beszerzése ugyanis nem olcsó mulatság. Már évente egy-két darab vásárlása is komolyan megterhelheti egy fejlődőben lévő vállalkozás büdzséjét. Emellett a több szerver kezelése több munkával jár, és több potenciális probléma lehetőségét is magában rejti.

Ha nem saját szerveren, hanem hoszting szolgáltatónál fut a webáruház, akkor is olcsóbban jövünk ki az új változat használatával.

14) Hatékonyabb tesztelés

A Magento 1 esetében a regressziós tesztelés, mely a regressziós hibák előzetes feltárására hivatott, egyáltalán nem jelentett egyszerű feladatot.
Ha komplexebb Magento rendszerrel dolgozunk, sok egyedi fejlesztéssel, bővítménnyel, modullal használjuk webáruházunkat, és kifejezetten akkor, ha egy nagyobb forgalmú webshopot üzemeltetünk, természetes, hogy szeretnénk a kockázatokat minimálisra csökkenteni.

A tesztelés tehát elengedhetetlen, ezért szerencsés, hogy a Magento 2 esetében könnyebbé tették számunkra a feladatot.

Az új rendszerben sokkal egyszerűbben bizonyosodhatunk meg arról, hogy a hozzáadott funkciók, modulok nem zavarják a már létező rendszert, nem produkálnak váratlan hibákat.

A beépített tesztelési keretrendszerrel mérettől függetlenül bármilyen Magento oldalon futtathatunk automatizált teszteket.

15) Egyszerűbb integráció

Webáruház-tervezés során már a Magento korábbi verziói esetében is rendkívül hasznos funkciónak bizonyult az, hogy a munkánk során rengeteg különféle rendszert tudtunk integrálni – leltárszoftvereket, ERP-t, CRM-et.

Abban az esetben azonban, ha az integráció nem sikerült tökéletesen, egyáltalán nem volt egyszerű kitalálni azt, hogy a Magento és a másik rendszer között pontosan hol nem érkeztek meg megfelelően a működéshez szükséges üzenetek.

A Magento 2 Enterprise Edition ezt a problémát is orvosolja, méghozzá egy beépített keretrendszer, a RabbitMQ (Message Queue) segítségével, melynek feladata a Magento és az integrált rendszerek közötti kommunikáció folyamatos vizsgálata.

Legfőbb funkcióját a nevének második fele mutatja meg: a valamiért el nem küldött üzeneteket tárolja, és amint lehetséges, továbbítja azokat megfelelő rendszernek (például abban az esetben, ha a leltárszoftver csak naponta egyszer frissül).

Mikor avul el a Magento 1.x?

Magento 2

Mint azt fentebb már említettük, a technikai támogatás 2020 júniusáig működik az 1.x verzióknál. A Magento 1 persze ezután is használható, azonban rendkívül sérülékennyé, az esetleges kibertámadásokkal szemben kiszolgáltatottá válik.

A migráció így lényegében elkerülhetetlen, hiszen a fejlesztők csak a Magento 2 folyamatos támogatását folytatják hivatalosan.

Aki új áruházat szeretne tehát indítani, annak már egyértelműen a Magento 2-ben kell gondolkodnia. Hamarosan ugyanis nem csak új funkciók és patchek nem jelennek meg a korábbi rendszerhez, de a biztonsági és szoftveres támogatását is teljes mértékben elveszíti.

Éppen ezért legyünk óvatosak, hiszen elszaporodhat az olyan, kártékony szoftverek a száma, melyek kifejezetten azokat a sebezhetőségeket célozzák, amelyek az utolsó biztonsági frissítések publikálása óta kerültek napvilágra.

Persze, megteheted, hogy a fejlesztőkkel patchelteted a rendszered a sebezhetőségek ellen, ez azonban plusz fejlesztési költségeket és rengeteg plusz munkát jelent, miközben nem lehetsz biztos abban, hogy akár már másnap nem publikálnak egy újabb kiaknázható sebezhetőséget.

A stabilitás tehát igen komoly szempont lehet, ha hosszú távra tervezel, és egyértelműen olyan tényező, ami az újonnan induló vagy már kifejezetten elavult 1.x változatot használók esetében egyértelműen a Magento 2-t teszi jó választássá.

Megéri vagy sem?

A válasz arra, hogy Magento 1-et vagy 2-t éri meg jobban használnod, a hamarosan bekövetkező változásoknak köszönhetően egyértelmű: ha új webáruházat indítanál, mindenképp a 2-est válaszd, ha pedig jelenlegi webshopot Magento 1 alapon működik, itt az idő, hogy továbblépj!

Hosszú távon csak ez a megoldás az, amely képes biztosítani a megfelelő stabilitást, hiszen az 1.x rendszerek a támogatás megszűnése után elkezdenek veszélyesen elavulni. Ez az időpont pedig vészesen közeleg!

A plusz költségeket és a migrációval járó munkát pedig tekintsd egyszerűen befektetésnek. A rengeteg fejlesztési munkára ugyanis idővel így vagy úgy, de mindenképp szükség lesz. És ha már ez elkerülhetetlen, akkor sokkal jobban megéri a Magento 2-re váltanod, amely várhatóan 7-8 évig az uralkodó, stabil és megbízható alapverzió lesz a piacon.

 

Mennyibe kerül valójában egy Magento webáruház?

Miért a Magento-t választanátok? Biztosra vesszük,hogy az ok a funkcionalitás: ezen a téren magabiztosan mondhatjuk, hogy egyetlen rendszer sem képes felvenni vele a versenyt.

Viszont azt is leírtuk már, hogy nem való mindenkinek.

Ennek fő oka a büdzsé: a Magento fejlesztése nem két fillér, hiszen nagyon komoly szakembergárda végzi. Ez garantálja a profi végeredményt.

A fejlesztési költség olyasmi, amivel muszáj számolni, ez a leggyakoribb kérdés, amelyet bármely Magento-val foglalkozó cégnek feltesznek az érdeklődők.

Gond az is, hogy nem egyszerű előre egyértelműen megállapítani, mennyibe fog kerülni a fejlesztés: az árak évről évre, régióról régióra változnak, az elérhető forrásokban nem egyszer hatalmas eltéréseket olvashatunk, akár óradíjról, akár projektalapú árazásról beszélünk.

Ennek a cikknek nem egyszerűen az a célja, hogy segítsen neked eligazodni az ártengerben.

El is magyarázzuk, hogy a Magento fejlesztése miért annyiba kerül, amennyibe, hogy min nem érdemes spórolni, és hogyan veheted észre, ha át akarnak verni.

Ezzel a tudással felvértezve már magabiztosan becsülheted meg az e-kereskedelmi projekted kivitelezésének büdzséjét, és biztosabban kerülheted el a kellemetlen meglepetéseket.

 

Eszerint haladunk végig az árazás kérdésein:

  • Magento Community vagy Enterprise Edition?
    • Néhány szó a bővítményekről
    • Magento 1 vagy Magento 2?
  • Házon belül fejlesszünk vagy bízzuk külső szakemberre?
    • Mennyibe kerül a házon belüli fejlesztés pontosan?
  • Fejlesztőcég vagy szabadúszó fejlesztő?
    • Megbízhatóság
    • Minőség
    • Tapasztalat és nézőpont
    • Ügynökségi árazás
  • Erre figyelj (árajánlat és egyéb tényezők)
  • Magento hosztolás árak
  • A pontos árak
    • Fapados Magento webáruház
    • Alap Magento webáruház
    • Egyedi Magento webáruház
    • Magento Enterprise webáruház
  • Nem az ár az elsődleges kérdés, hanem ez: mire van szükséged?

 

Magento Community vagy Enterprise Edition?

 

Az első döntés, melyet meg kell hoznod, hogy melyik Megento-változatot akarod használni, ez már önmagában is jelentős hatással van ugyanis a büdzsére.

A Community Edition ingyenesen letölthető és használható, ugyanakkor semmilyen támogatás nem jár mellé a Magento részéről.

Ha valamit tehát változtatni akarunk, akkor ezt saját magunknak vagy az ezzel megbízott fejlesztőcégnek vagy szabadúszónak kell megoldania.

Ezzel szemben az Enterprise Edition-ért fizetnünk kell.

A Gold Support csomag esetén egy évben több mint 22 ezer dollárt. Választhatunk Platinum Support csomagot is ez még drágább, illetve forgalomarányosan jutalékot kell fizetnünk érte.

A pénzért cserébe természetesen supportot kapunk, illetve új fejlesztéseket és funkciókat, amelyek gyorsítják a weboldalt, az adatbázis-kezelést és így tovább.

Ha a Community Edition-nél akarunk hasonló funkcionalitást elérni, ahhoz körülbelül 65 bővítményre lesz szükségünk. (Az persze az egyéni igényektől függ, hogy valóban minden modulra szükségünk van-e.)

A Magento 2 megjelenésével együtt a Magento 1 Enterprise Edition elérhetősége megszűnt, és az árazási modell is átalakult.

Renato Medina az MDN blogján szedte össze, hogy milyen árakkal számolhatunk az új, jutalékos rendszerben.

Tehát a bevételtől teszik függővé, mennyit fizetünk, méghozzá sávos rendszerben. Ez azt is jelenti, hogy minél magasabb a bevételünk, annak annál kisebb százalékát kell a fix licencdíjra kifizetnünk.

A Magento 2 EE szolgáltatásaiért akkor is 22 ezer dollárt kell fizetnünk, ha egyáltalán nincsen bevétele a webshopnak, 100 millió dollár bevétel felett viszont már évi 250 ezer dollárba is kerülhet a support.

Itt a Gold csomag árairól beszélünk, a Platinum csomag minden esetben +20%-os költséget jelent ezekhez képest.

Ha az első évet követően a licencet nem hosszabbítjuk meg, ettől még természetesen a webshopunk ugyanúgy működni fog, a supportot viszont elveszítjük, tehát ezt követően minden bővítést, változtatást magunknak kell elvégeznünk, elvégeztetnünk, illetve a bővítményeket meg is vásárolhatjuk.

Figyelembe kell viszont venni azt is, hogy a legtöbb megvásárolható bővítmény esetében az EE-változat drágább, mint a CE-változat.

 

Összességében elmondható: a kis és közepes méretű webshopoknak a CE a megfelelő, nagyobb webáruházaknak viszont az EE kötelező.

 

Néhány szó a bővítményekről

 

Már azt sem könnyű eldönteni, hogy pontosan milyen bővítményekre lesz szükségünk, hiszen ehhez nem árt pontosan ismerni a lehetőségeket, a funkciókat, a bővítmények működését – de még egy szakértőnek is nem kevés idejébe kerülhet a tökéletes válogatás.

Ezeket a modulokat aztán telepíteni is kell.

 

Itt is adódhatnak gondok: a Magento komplex rendszer, ami áldás és átok is. A telepítés ritkán sikerül tökéletesen, különösen akkor, ha egyszerre sok bővítménnyel dolgozunk, amik konfliktusba kerülhetnek egymással.

 

A telepítéssel még ideális esetben is rengeteg idő mehet el.

Tegyük fel, hogy a fejlesztő profi, így bővítményenként csak két órára van szüksége. Mondjuk, hogy több mint 60 bővítményből csak 10-et akarunk telepíteni. Ez még így is 20+ munkaórát jelent, és jó eséllyel nem is csak egy ember idejéből, mivel a telepítés során felvetődő kérdéseket meg kell beszélnie az üzemeltetővel, menedzsmenttel, akár marketingessel és így tovább.

Kérdés, hogy milyen óradíjjal dolgozik a fejlesztő – mindössze 10 bővítmény telepítése még akkor is 3-4000 dollárba kerülhet, ha minden tökéletesen működik, zökkenő nélkül, erre viszont ne számítsunk.

Ezután még jön a teljesítményoptimalizálás az új bővítményekkel, és persze időt kell szánni arra is, hogy a bővített rendszert megtanuljuk profin használni.

A fejlesztői, ügynökségi árakról nemsokára részletesen is beszélünk.

 

Magento 1 vagy Magento 2?

 

Szintén fontos kérdés, hogy egyáltalán melyik verziót választjuk – jelenleg is több tízezer webáruház működik 1.x verziójú Magento rendszereket futtatva, éves szinten akár több tízmilliós forgalmat bonyolítva le.

A Magento 1 valamely verziója tehát megfelelő választás lehet, ha viszont teljesen új projektbe akarunk kezdeni, akkor érdemes hosszú távon gondolkodni, és a Magento 2-t választani.

Enterprise Edition esetén persze nincs értelme a kérdésnek, hiszen itt már csakis a 2-t vehetjük igénybe.

 

Házon belül fejlesszünk vagy bízzuk külső szakemberre?

 

Ha nem akarunk külső fejlesztőt – akár szabadúszót, akár ügynökséget – megbízni a fejlesztéssel, mert jobb szeretnénk mindent egy kézben tartani, akkor nem csak fejlesztőkre lesz szükségünk.

A legegyszerűbb esetet tekintve is szükség lesz egy dizájnerre és UX-szakemberre, akik a weboldal megjelenéséért, az alapvető felhasználói élményért felelnek.

Korábbi cikkeinkben beszéltünk már arról, hogy már csak a megfelelő színek kiválasztásának is milyen óriási szerepe lehet – hát ezért kell mindenképpen külön dizájner.

Szükség lesz valakire, aki előzetesen meghatározza, hogy milyen üzleti célokat érhetünk el reálisan, és ehhez az adott piacon (figyelembe véve a célközönséget, terméket, konkurenseket és így tovább) pontosan milyen funkcionalitásra lesz szükségünk, milyen általános specifikációk mentén kell levezényelnünk a projektet.

Ha a projekt komplex frontend funkcionalitással bír, akkor a fő fejlesztőn túl szükség lehet egy frontend szakemberre is.

A frontend (Javascript, HTML, CSS) és backend (Magento PHP) fejlesztéshez eltérő képességek és tapasztalatok kellenek, és ritka az olyan szakember, aki mindkét szakterületen képes maradéktalanul megállni a helyét. (Ahogyan egy plasztikai sebésszel sem húzatnánk szívesen fogat, úgy itt is fontos a specializáció és az adott szakterületen szerzett tapasztalat.)

És persze szükségünk lesz egy projektmenedzserre is, aki az egészet kézben tartja.

A lista tovább bővülhet, ha ennél is komplexebb megoldásokra van szükségünk, kellhet például a csapatba ERP-integrációval foglalkozó szakember vagy 3D-modelleket építő dizájner.

Saját csapatot építeni tehát költséges és komplex feladat.

Ha több millió dolláros éves bevételre számítunk és hosszú távon tervezünk, akkor persze lehet, hogy megéri harmadik fél helyett egy teljesen saját csapatot felépíteni, akiknek semmi más feladata nincs, mint a mi rendszerünkkel foglalkozni.

 

Mennyibe kerül a házon belüli fejlesztés pontosan?

 

A tapasztalatok szerint, ha házon belül akarjuk megoldani a fejlesztést, akkor a CE és EE verziók között nincsen érzékelhető különbség.

Egy kezdő fejlesztő (egy évnél kevesebb tapasztalattal) alkalmazása évente 60-80 ezer dollárba fog kerülni, egy senior fejlesztő ennek legalább kétszeresébe. Átlagosan mondjuk, hogy évente 120 ezer dolláros fizetéssel számolhatunk egy már nem kezdő fejlesztőnél.

Ehhez pedig hozzájöhet még természetesen az eszközköltség (szerverek, megfelelő munkaeszközök), a szükséges szoftverek költségei, adott esetben az iroda bérleti díja és így tovább.

 

Összefoglalva: A legnagyobb cégeknek megérheti saját fejlesztőcsapatot fenntartaniuk, alacsonyabb szinten viszont aligha.

És még a nagyobb cégeknél is rizikós vállalkozás ez, hiszen az alapoktól felépíteni egy csapatot nem egyszerű: a szakemberek akkor dolgoznak jól, ha összeszoktak, és igazán akkor bízhatunk meg bennük, ha megfelelő referenciákkal rendelkezik egy csapat.

Tehát még a legnagyobb vállalatoknak is jobban megérheti egy kipróbált, összeszokott fejlesztőcsapattal, ügynökséggel dolgoznia.

 

Fejlesztőcég vagy szabadúszó fejlesztő?

 

Ha e két lehetőség között hezitálunk, a döntés előtt rengeteg szempontot kell figyelembe vennünk.

Tény, hogy szabadúszót választani rendszerint olcsóbb döntés, megvan azonban az oka annak, hogy az ügynökségek drágábban dolgoznak.

Most sorra veszünk minden szempontot, hogy megkönnyítsük a döntést.

 

Megbízhatóság

 

A szabadúszók egyik gyenge pontja az ügynökségekkel szemben az elérhetőség.

Nem szaktudásról vagy személyes kvalitásokról beszélünk: képzeljük el, mi történik, ha a szabadúszó egy kritikus pillanatban példának okáért annyira lebetegszik, hogy nem tud a projekten dolgozni.

Ezzel szemben egy ügynökségnél csak azért, mert egy ember kiesik, a munka még nem áll meg, hiszen egy fejlesztő helyettesíthető, és jó eséllyel eleve egyszerre többen dolgoznak a projekten, ismerik azt annyira, hogy folytatni tudják a munkát.

 

Kockázat: Egyetlen emberre építeni veszélyes, ha komolyabb projektről van szó, ez komoly kockázatot jelent, pótlása nagyon komoly problémákat okozhat.

 

Minőség

 

A saját tapasztalatunk is ezt támasztja alá: azok az ügyfelek, akik projektválság-kezelés keretében kerestek meg minket, a szabadúszókkal kapcsolatban a rendszertelen kommunikációt, valamint a projektmenedzsment teljes hiányát jelölték meg.

Hogy mennyibe kerül szabadúszóval fejlesztetni, nem könnyen megválaszolható kérdés.

A legolcsóbban dolgozó fejlesztők (jellemzően Délkelet-Ázsiára, Indiára, Pakisztánra jellemző ez) akár már a hihetetlenül olcsó, óránkénti 10-20 dolláros sávban is vállalnak munkát.

Kelet-Európában már jellemzőbb a 20-60 dolláros órabér, míg Nyugaton (Nyugat-Európában, az Egyesül Királyságban és az Egyesült Államokban) már inkább 150-200 dollárral kell számolnunk.

Hogy a legalsó sávban mennyire végezhető ténylegesen minőségi munka, azt mindenki eldöntheti – a mi tapasztalatunk az, hogy komplex projektekkel, egyedi funkcionalitás kivitelezésére szóló megbízásokkal nem érdemes itt szakembert keresni.

Ugyanakkor a template-ek vagy modulok telepítésére megfelelő választás lehet egy szabadúszó, ezekkel elvétve adódik csak gond.

 

Tapasztalat és nézőpont

 

Egyetlen szabadúszóra komplexebb projektet bízni azért sem szerencsés, mert valószínűleg leginkább a saját nézőpontjából nézi majd, és kevéssé figyeli a teljes képet.

Egy ügynökségnél rendelkezésre áll számos szakember, akik egymás álláspontját finomítva egy minden szempontból jól működő rendszert képesek kialakítani.

Egy komolyabb ügynökségnél 20-60 ezer dollárba kerülhet egy olyan Magento oldal felépítése, amely megfelelő alap funkcionalitással bír, és a megjelenésével sincsenek problémák.

Nyilvánvalóan pár ezer dollárból is megúszhatjuk az oldal indítását – ha olyan harmadik felet választunk, aki automata telepítéssel néhány tíz dolláros template-eket telepít valódi fejlesztői munka nélkül.

 

tips Szögezzük le:  senki sem vonja azt kétségbe, hogy egyetlen ember is képes lehet egy működő Magento webáruházat létrehozni. Az viszont tény, hogy egy versenyképes, komplex, ténylegesen minőségi Magento webáruházhoz egyetlen ember kevés.

 

Ügynökségi árazás

 

Ha ügynökséget keresel, többféle árazással is találkozni fogsz.

A leggyakoribb az, hogy projektminimumot adnak meg – infografikánkon láthatod, hogy az Egyesült Államokban és globálisan milyen minimumot határoznak meg az ügynökségek.

 

Ehhez egy megjegyzés: az Egyesült Államokban ugyan átlagosan feleannyi a minimum projektár, hozzá kell azonban számítani, hogy itt sokkal több kifejezetten Magento-fejlesztésre specializálódott ügynökség működik, mint bármely más országban.

Az alacsony árakon dolgozó ázsiai vagy dél-amerikai fejlesztők rendszerint szabadúszók, így kevesebb az alacsony áron dolgozó ügynökség.

Nyugat-Európában viszont az ügynökségek jellemzően nagyobb projektekkel dolgoznak, a legtöbb esetben 20-50 ezer dollár (vagy euró) körül határozzák meg a minimális árat.

 

Ezzel szemben az amerikai ügynökségek között rengeteg olyan kisebb csapatot is találhatunk, akik kifejezetten a kisebb projektekre specializálódtak.

Az ügynökség árazhat havonta is, tapasztalataink szerint ez általában minimum 7500 dollár körüli összeget jelent. Ha hosszú távra tervezünk, és tudjuk, hogy szükség lesz komolyabb fejlesztésekre, érdemes lehet eleve ilyen rendszerben szerződni.

Vannak olyan ügynökségek is, amelyek egyáltalán nem határoznak meg minimumot – jellemzően ők azok, akik a kisebb projekteket szolgálják ki.

Ha árajánlatot kapsz, figyelj arra, mit látsz ebben.

Pontos összeget persze igen nehéz mondania bármilyen tapasztalt fejlesztőnek (hogy miért, azt mindjárt kifejtjük), az ajánlat részletességéből azonban láthatod, hogy mennyire komoly csapatról van szó.

Ha külön látod például, hogy mennyibe kerülhet a dizájn, a frontend és backend fejlesztés, a keresőoptimalizálás, a későbbi karbantartás és így tovább, az jó jel arra nézve, hogy mennyire komoly ügynökséggel van dolgod.

 

Hogy a szabadúszók és ügynökségek árairól átfogó képet adhassunk, felkerestük a CommerceHero.io adatbázist. Itt több száz, kifejezetten a Magento-ra specializálódott fejlesztő és cég képviselteti magát.

A szabadúszókat régiónként és képesítések szerint vizsgáltuk.

Az egyik, ami a számokból jól látszik, hogy minél komolyabb képesítéssel bír egy fejlesztő, annál magasabb az óradíja is: egy Certified Developerhez képest egy Solutions Specialist 10-30 dollárral is többet kérhet óránként, akárhol is dolgozik.

A régiókat tekintve nem szembesülünk különösebb meglepetéssel.

A legdrágábban Észak-Amerikában dolgoznak a fejlesztők, Nyugat-Európa, majd Kelet-Európa követi őket, Dél-Amerikában és Ázsiában pedig már megfeleződnek az árak az Egyesült Államokhoz képest.

 

Ha fejlesztőt keresel és szeretnéd áttekinteni, saját piacodon hol találsz ilyet korrekt áron, ajánljuk az oldal felkeresését: a regisztráció ingyenes, a szűrés pedig remekül működik.

 

Szabadúszó óradíjak régiónként és képesítésenként ($)

 

magento fejlesztési árak, szabadúszók

 

Magento projektek minimum árai országonként (átlagolva):

 

magento minimum projekt árak

 

Erre figyelj – árajánlat és egyéb tényezők

 

Ha árajánlatot kérünk, több mindenre is érdemes figyelni.

A legalapvetőbb: a fejlesztőcég vagy szabadúszó aligha tud előre, mondhatni látatlanban pontos árat mondani arra, hogy mennyibe fog kerülni a projekt.

A legtöbb esetben az árajánlatban becslést kapunk, míg a számlázás már a valós munka alapján történik.

Ez persze kettős helyzetet eredményez.

A megrendelő nyilván szeretné minél pontosabban tudni, hogy mennyibe fog kerülni a fejlesztés. A fejlesztő viszont nem teheti meg, hogy látatlanban kötelezi el magát, mert lehet, hogy ezzel ő kerülne pénzügyileg kilátástalan helyzetbe.

Megrendelőként tehát a legjobb, amit tehetünk, hogy felső és alsó becslést is kérünk, és az előbbivel számolunk, amikor a büdzsénket megtervezzük.

Figyelj arra, aki túl gyorsan akar végezni: a Magento weboldalak felépítése időigényes munka, magas szintű PHP-fejlesztői tudást igényel.

Ne higgy annak, aki azt ígéri, hogy 1-2 hét alatt elkészül az oldaladdal (lásd a példát feljebb arról, mennyi időt emészthet fel egyszerűen a bővítmények telepítése).

Ahogyan a házon belüli fejlesztésnél, úgy a külső fejlesztő alkalmazásánál is adódhatnak plusz költségek.

Az egyedi dizájn például magától értetődően megnöveli majd a büdzsét, már csak azért is, mert a dizájnernek aktívan együtt kell dolgoznia a fejlesztőkkel.

Ne spórolj a szaktudáson!

Egy kezdő fejlesztő vagy egy PHP-fejlesztő egymagában nem lesz képes a teljes Magento wbáruházadat felépíteni.

Egy ilyen projekthez több fejlesztőre (frontend és backend), SEO- és analitika szakemberekre, dizájnerre, grafikusra is szükség lesz.

Egyetlen szabadúszó fejlesztővel elvégeztetheted a bővítmények telepítését, de nem bízhatsz rá egy teljes komplex projektet.

Mielőtt bármilyen ajánlatra rábólintasz, ellenőrizd a fejlesztő(cég) referenciáit.

Főleg külföldi fejlesztők esetében: légy biztos benne, hogy a munka elkészül, és tényleg minőséget várhatsz.

Ne hidd, hogy egyszeri kiadásról van szó.

Az e-kereskedelemben nem állhatsz tétlenül, a rengeteg konkurens, a változó technológiák és csatornák arra kényszerítenek, hogy folyamatos fejlesztésekkel biztosítsd előnyödet.

Folyamatosan költened kell majd arra, hogy a weboldalad naprakész, jobban használható, gyorsabb legyen. Ha tehát hosszú távon gondolkodsz, ennek megfelelően hosszú távra kell büdzsét elkülönítened.

 

tips Nem győzzük eléggé hangsúlyozni: az ár nem minden, soha ne a legolcsóbbat válaszd az ajánlatok közül.

Ha van esély arra, hogy az üzleted komolyan növekedjen, akkor fektesd bele a szükséges tőkét. Lehet, hogy pár ezer dollárért egy úgy-ahogy ténylegesen működő webáruházat kaphatsz, ehet az is, hogy van fejlesztő, aki óránként 30 dollárért elvégzi neked a legszükségesebb feladatokat.

Ezzel viszont nem emelkedsz ki, nem nyújtasz jobb felhasználói élményt, nem segíted elő a növekedést.

 

A profitodból biztosítsd a lehetőséget a növekedésre, és ha 2 millió dolláros éves bevételnél gyorsan növekedsz, ne félj akár 100 ezer dollárt költeni a fejlesztésre.

Ha csak 10%-os növekedéssel számolhatsz ennek következtében, már akkor is több mint kétszeres lesz a befektetésed megtérülése egyetlen év alatt.

 

Magento hosztolás árak

 

A Magento erőssége, hogy elképesztően sok funkcióval bír, testre szabható, olyan komplex rendszert építünk belőle, amilyet csak akarunk – éppen ezért hoszting tekintetében is erőforrásigényes, ha optimális teljesítményt akarunk elérni.

2014 előtt az Enterprise Edition felhasználói még igénybe vehették a Magento saját hoszting szolgáltatását, erre azonban ma már nincsen lehetőség – hosztingról tehát, bármelyik verzió mellett tesszük is le a voksunkat, magunknak kell gondoskodnunk.

A CE esetében egyszerűbb a választás, az EE azonban már legalábbis egy saját, dedikált szervert igényel.

A hoszting olyan költség, amelyet sokan hagynak figyelmen kívül a projekt büdzséjének tervezésekor, pedig a megfelelő hoszting cég megtalálása létfontosságú ahhoz, hogy sikeres vállalkozást indítsunk.

Ha megosztott hosztingot akarunk (CE-t használóknak már ez is megfelelő lehet), 150 dolláros havidíjjal is megúszhatjuk a rendszer működtetését, míg az ennél erőforrásigényesebb projektek esetében a klaszter rendszerben működtetett dedikált szerverekért akár 4500 dollárt is fizethetünk.

 

A hosztingszolgáltató kiválasztásakor ezekre a kérdésekre érdemes választ keresnünk (ezek egy részét már a Magento AWS hosztingról szóló cikkünkben is olvashattad):

  • Mennyi a látogatók száma az oldalon naponta?
  • Mennyi az indított munkamenetek száma egy hónapban?
  • Peak-ek esetén mi volt a legnagyobb munkamenetérték a periódusban?
  • Mekkora ezeknek a csúcsoknak az előfordulási aránya egy adott üzleti évben?
  • Hány párhuzumos munkamenetre számítunk átlagosan és a csúcsidőszakokban?
  • Földrajzilag hová célozzuk a szolgáltatásunkat?
  • Milyen verziójú Magento áruházat szeretnének készíttetni, illetve melyik verziót szeretnék migrálni?
  • Jelen webshopban mekkora az SKU (Stock Keeping Unit)?
  • Használni akarjuk-e a SOLR, Elasticsearch vagy Sphinx keresést a Megento-ban?
  • Használni akarjuk-e a Magento Payment Bridge-et?
  • Az aktuális szerver vagy szerverek milyen specifikációval rendelkeznek?
  • Elegendő lehet a megosztott hoszting vagy dedikált, esetleg többszerveres klaszter rendszerben működő szolgáltatásra van szükségünk?
  • Milyen külső rendszerekkel kommunikál a webáruház, és vannak-e tervek ennek bővítéséről (adatbázis típus/méret, számlázó szoftverek, ERP, CRM stb.)?
  • Elemezzük-e weboldalaink működését, teljesítményét valamilyen külső eszközzel (Pingdom, New Relic stb.)?
  • Szükségünk lesz-e valamilyen tartalomelosztó hálózatra (CDN)?

 

Megosztott hoszting szolgáltatással viszonylag olcsón futtathatjuk a webáruházat, de természetesen ez korlátozásokkal is jár: nagyobb forgalmú áruházat ne akarjunk ilyen rendszerben működtetni.

Hosszú távon gondolkodva mindenképpen számítsunk arra, hogy drágább szolgáltatásra kell váltanunk, dedikált szervereket kell bérelünk egy profi szolgáltatótól.

A megosztott hoszting rendszerben havi 20-120 dollár lehet a hoszting, attól függően, milyen komoly igényeink vannak.

Ha dedikált szerveren akarjuk futtatni a webáruházat, az körülbelül havi 500-750 dollárba fog kerülni szerverenként.

 

A pontos árak

 

Fapados Magento webáruház

 

Becsült ár: 1500 – 5000 dollár (0,5–1,5 millió Ft)

 

Ha szakembert kérdezünk, általában 10-20 ezer dollár körüli minimum költséget mond arra, mennyiért lehet Magento webáruházunk.

Ez, mondjuk úgy, félig igaz csak. 1500 dollárért is lehet egy működő Magento webáruházad.

De nem ajánljuk, hogy legyen.

Ennyi pénzért egy nagyon olcsón dolgozó szabadúszót tudsz felfogadni, és sem idő, sem tapasztalat nem jut majd arra, hogy a lehető legalapvetőbb telepítésen kívül bármi más helyet kapjon a webáruházban, nem is beszélve a későbbi fejlesztésekről.

 

Szögezzük le: Aki ebben az árkategóriában gondolkodik, és 20-50 ezer dollárt komolyan sokall egy webáruházért, annak egyszerűen nem való a Magento.

 

Kis- és középvállalkozások is használják persze, de a Magento lényege éppen fejleszthetősége, komplexitása, a végtelen funkcionalitás – ekkor büdzsével ez kihasználhatatlan, a BigCommerce, WooCommerce vagy valamely más ingyenes rendszer így valószínűleg jobban szolgál majd.

 

Alap Magento webáruház

 

Becsült ár: 10 000 – 40 000 dollár (3–12 millió Ft)

 

Ha más platformról költöztetsz át egy már működő, kisebb webáruházat, vagy éppen el akarod indítani új üzletedet, és a jövőre is gondolva a Magento-t akarod erre használni, akkor ennyi a minimum büdzsé, amivel számolnod kell.

Ennyiért viszont még mindig csak alap funkcionalitásról beszélhetünk.

Láthattuk korábban, hogy már csak a bővítmények telepítése is több ezer dollárba kerülhet, még ha csak töredékükről, és problémamentes telepítésről beszélünk.

Ennyi pénzért tehát megkaphatod az ingyenes Magento CE legújabb verzióját, ehhez egy beépített vagy nagyon olcsó sablont és a legfontosabb funkciókat.

Ennyiért egy profibb szabadúszó vagy egy kisebb ügynökség telepíti az oldalt, a kiválasztott sablont. A dizájnnál szóba jöhet némi minimális testreszabás, az SSL beállítása.

Szó sem lehet viszont bármilyen egyedi fejlesztésről, komolyabb bővítménytelepítésről vagy akár egyedi bővítményekről, teljesen egyedi dizájnról, a Back Office rendszerek integrációjáról.

Kisebb forgalom és termékszám, korlátozott lehetőségek jellemzik az ilyen webáruházakat.

 

Egyedi Magento webáruház

 

Becsült ár: 40 000 – 100 000 dollár (12–30 millió Ft)

 

Ezen az áron egy komolyan vehető ügynökség egy valóban egyedi, az igényeinknek megfelelő Magento weboldalt képes fejleszteni.

 

Kinek való? Olyan kereskedőknek, akik már jól működő, szép profitot termelő webáruházat akarnak Magento alá költöztetni, vagy új üzletágként indítják azt – a lényeg, hogy hosszú távon is legyen büdzsé a fejlesztésekre, hosztingra és növekedésre.

 

Ezért a pénzért egyedi bővítményeket, funkciókat fejlesztethetünk, amelyek illeszkednek a termékkínálathoz, az üzletpolitikához.

Alapos teszteléssel javíthatjuk a felhasználói élményt és teljesen egyedi dizájnt kaphatunk, amelyet dizájner szakemberek a frontend fejlesztővel együtt alkotnak meg.

Itt már használhatjuk az olyan ránk szabott funkciókat, mint a kuponozás, a hírlevelek kiküldése, a tartalmak közzététele, a bonyolultabb keresési lehetőségek.

Emellett a fejlesztőktől is komolyabb támogatást kaphatunk, nem csak tesztelést, de dokumentációt, garanciát, az adatok migrálását más webáruház-rendszerekből.

 

Magento Enterprise webáruház

 

Becsült ár: 100 000 dollártól (40 millió Ft-tól)

 

Nagyvállalatoknak való rendszer, melynek alapja már nem a Community Edition, hanem az Enterprise Edition (ennek árazási struktúrájáról korábban beszéltünk).

 

A Magento Enterprise weboldalak már száz százalékban egyediek lehetnek A funkciók, megjelenés egyedire szabhatóak, emellett pedig a Magento EE olyan alapfunkciói is rendelkezésre állnak, mint

  • a mobilra szabott megjelenés,
  • egyszerre futtatható több webáruház,
  • beépített modulok,
  • keresőoptimalizálás (SEO),
  • szegmentálás,
  • targetált promóciók,
  • egyedi kuponok,
  • retargeting és remarketing eszközök stb.

 

Nem az ár a kérdés, hanem az: mire van szükséged?

 

Egy kis- vagy mikroméretű vállalkozásnak a Magento nem a legjobb rendszer.

Beszéltünk már korábbi cikkeinkben arról, hogy olyan esetekben, amikor elindítani akarunk egy kisebb webáruházat, amelyből komolyabb bevételre nem számítunk (vagyis évi 1-2 millió dollár alatt maradunk), akkor a Magento helyett jobban megérheti valamilyen más, ingyenes, könnyebben testre szabható webáruház-rendszert választani.

Ennek az oka az, hogy a Magento fejlesztése költséges.

A legkisebb webáruházaknak nincsen szüksége olyan szerteágazó funkcionalitásra, amilyet ez a rendszer biztosítani tud, a közepes és nagyvállalatok azonban, amelyeknek ez már létszükséglet ahhoz, hogy versenyképesek maradhassanak és biztosíthassák a növekedést, meg kell tudniuk fizetni a fejlesztőket ügynökségeket akár.

Kérdés az is, hogy mennyire gondolkodunk hosszú távon.

Írtunk róla, hogy a Magento nem egyszeri költséggel járó rendszer, legalábbis, ha komolyan gondoljuk a használatát:

folyamatos fejlesztésre, finomításra szorul, már csak a piaci változások miatt is.

Éppen ezért akinek nem áll rendelkezésre 100-200 ezer dollárja az egyedi fejlesztésekre, jó eséllyel nem a Magento-ban találja meg az ideális webáruház-rendszert.

Szabadúszók segítségével alacsony áron is elindítható egy ilyen webáruház, amely működőképes és nyereséges lehet, kicsi azonban arra az esély, hogy hosszú távon nagyobb növekedést mutasson fel.

Természetesen rengeteg webáruház használ Magento-t, írtunk már arról, mekkora a piaci részesedés – ezek között azonban rengeteg olyat is találunk, amely nem nyereséges, nem képes növekedni.

Az első három évben az induló vállalkozások több mint 90%-a kénytelen csődöt jelenteni – és erről nem a Magento tehet, hanem az elhibázott üzletpolitika.

 

Az igazi kérdés ez: ha egy közepes és gyorsan növekedő vállalkozást vezetsz, hajlandó vagy-e befektetni a növekedésbe?

 

A webáruházadba éppen úgy be kell fektetned, mint egy fizikai boltba: ha az üzleted rozsdás, beázik, ha a kassza nem működik és az eladó is mogorva, a vevők nem vásárolnak majd nálad, inkább mennek néhány utcát a konkurensedig.

A neten nem kell ennyi erőfeszítést tenniük azért, hogy egy nálad jobbat találjanak.

Ha rá tudsz szánni 100-200 ezer dollárt egy Magento webáruház felépítésére úgy, hogy fizetni tudod az alkalmazottaid, a befektetőket, hogy van pénzed egyéb területeken (például a marketingben) is áldozni a bővülésre, és azt is biztosítani tudod, hogy valamilyen váratlan katasztrófa esetén néhány hónapig működhessen a vállalat, akkor érdemes befektetned a jövőbe.

Ha a jobb funkcionalitás, fizetési lehetőségek, felhasználói élmény akár csak 10%-os növekedést hoznak, akkor jó eséllyel már egyetlen év alatt megtérül a befektetésed – márpedig egy egyedi rendszer ennél sokkal többre is képes.

Rengeteget írtunk már arról, hogy megfelelő online marketing eszközökkel megtámogatva mi mindenre képes a Magento: nem kétséges, hogy ha profi fejlesztőcsapattal dolgozol, a 10%-os bevételnövekedés nem elérhetetlen álom.

 

 

Hogyan használd a Twittert? Alapok, üzleti tippek és eszközök

És néha még az is csődöt mond.

A legelső lépésektől átvesszük, hogy pontosan hogyan kezdj bele, hogyan hozd létre a felhasználódat, hogyan találd meg a közönségedet.

Hogy milyen témákban és hogyan posztolhatsz, hogyan találhatsz influencereket és építhetsz követőtábort, és egyáltalán milyen extra eszközökkel turbózhatod fel a teljesítményedet.

 

Kezdjük a közönségeddel

 

A Twitter jelentősége a közösségi platformok között mára ugyan csökkent némileg, de ezzel együtt még mindig 317 millióan használják havonta a 2017 januári adatok szerint.

 

Néhány statisztika arról, hogyan használják a Twittert a felhasználók:

  • A Twitter tartalmai nyilvánosak, csak a tweeteléshez, aktivitáshoz kell regisztráció – éppen ezért az oldalt minden hónapban 500 millióan látogatják meg anélkül, hogy belépnének.
  • A beágyazott tartalmakkal együtt viszont összesen egymilliárdnál is több internet-felhasználót érnek el.
  • A legtöbben mobilról használják a platformot, egészen pontosan a felhasználók 82%-a. (Ez a gyorsaság miatt fontos: a Twitteren az azonnali kommunikációé a főszerep.)
  • A videómegtekintéseknél a mobileszközök részesedése még ennél is nagyobb, 90%.
  • Egy átlagos felhasználót 208-an követnek, 391 milliónak viszont egyáltalán nincsenek követői. (A felhasználói fiókok és a valós, egyes emberekhez köthető, általuk üzemeltetett fiókok között nyilván van különbség.)

 

Rendben, ismerünk adatokat – de abban még nem lehetünk biztosak, hogy a te közönséged ténylegesen ott van-e a Twitteren, aktívan használja a szolgáltatást, vagyis egyáltalán van-e értelme annak, hogy nagyobb energiát fektess a platformba.

Ha ezt már tudod, azt kell meghatároznod, hogyan fogsz velük kommunikálni, milyen stratégiát, megközelítést válassz.

 

A PewResearchCenter 2014-es kutatása szerint a felületen folyó diskurzusoknak, közösségeknek, hat archetípusa azonosítható be:

  • Polarizált közösségek: nagyobb csoportok, amelynek tagjai egy-egy nagyobb témakörben egymással beszélgetnek és az ellentétes véleményű csoport tagjaival vitatkoznak. Az ilyen megosztó diskurzusok jellemzően politikai témák körül alakulnak ki, amikor ún. visszhangkamra-struktúrák alakulhatnak ki és ütközhetnek egymással a közösségi felületeken.
  • Szoros közösségek: szakmai közösségek, hobbik köré szerveződő társaságok, aktuális események, például konferenciák aktív diskurzusai tartoznak ide. Itt nincsenek kívülállók, a résztvevők mind az adott közösség tagjai.
  • Brand-klaszterek: termékek, márkák, hírességek vagy események köré szerveződő diskurzusok, melyeknek nagyon vegyes, sokszínű és nagyszámú résztvevője van, a diskurzus sok, egymástól független szálon, klaszterben fut.
  • Közösségi klaszterek: globális jelentőségű események jellemzően ilyen mintát alakítanak ki, több kisebb és nagyobb résztvevővel, rengeteg különálló csoporttal, amelyek mind egy témáról tweetelnek.
  • Hírhálózatok: hasonlóan a hagyományos médiához, általában híroldalak vagy hírekkel foglalkozó véleményvezérek köré szerveződik. A hírek megjelennek a felhasználók pedig retweetelik, megbeszélik, kommentálják azokat.
  • Támogatói hálózatok: az ügyfélkapcsolatok csoportjai, ilyen az, amikor egy adott fiókot kifejezetten a tömegekkel való kapcsolattartás miatt hozunk létre. Brandek, cégek ugyanúgy jelen vannak itt, mint médiumok, kormányszervek vagy akár vallási csoportok.

 

Figyeld meg, hogy a közönséged milyen diskurzusokban vesz részt, milyen közösségekben aktív (a cikkben olvashatsz néhány analitikai eszközről, amelyek segíteni fognak ebben), és ennek megfelelően alakítsd a saját kommunikációdat is.

 

Mielőtt tweetelni kezdenél…

 

Mielőtt elkezdenéd használni a Twittert, érdemes alaposan elgondolkodnod rajta, hogy mi a célod ezzel.

Számtalan közösségi felület áll rendelkezésedre, hogy a brandedet építsd, hogy eladj vagy tartalmat tégy közzé – a legnagyobbakkal már mind foglalkoztunk ezen a blogon.

A Twitternek is megvannak a maga sajátosságai, ezért kezdd azzal, hogy megfigyeled, hogyan viselkedik itt a célközönséged.

Ha például szeretnek kérdéseket feltenni egymásnak és az üzleteknek, ahonnan vásárolnak, pozicionálhatod magad információforrásként. Hasznos tartalmakat oszthatsz meg, ügyfélszolgálati kérdésekkel foglalkozhatsz és így tovább.

 

Az alapok

 

A Twitternek, mint a legtöbb közösségi felületnek, saját nyelvezete van, szokásai vannak, melyeket ösztönösen kell használnod.

A legfontosabb persze, hogy legfeljebb 140 karakterben írhatunk tweeteket, nagyrészt ez teszi különlegessé az egészet.

Ez kevésnek tűnhet, de meglepően sok mindent fejezhetünk ki már néhány tweetben is – elég csak arra gondolni, hogy a politikában milyen hangsúlyos szerepet kapott az utóbbi néhány évben ez a platform.

Ha azt akarod, hogy a közzétett üzeneteidet könnyen megtalálják, hashtageket kell használnod, melyek elé a # karakter kerül.

Érdemes kitalálnod egy saját hashtaget, hogy így építsd a branded és a közösséget, amelyet remélhetőleg összehozol itt.

Ha valakihez nyilvánosan akarsz szólni, fel akarod hívni a figyelmét, megemlítheted (mention), ekkor az üzenetben a felhasználónevét, előtte pedig a @ karaktert kell használnod.  A másik fél ilyenkor az alapbeállításoknak megfelelően értesítést kap róla, hogy megemlítették a nevét egy tweetben.

Mások tweetjeit újraközölheted, retweetelheted – ha mondjuk az egyik ügyfeled egy pozitív értékelést oszt meg az üzletedről, így a saját csatornádon is helyet kap.

Kedvencnek szintén jelölhetsz olyan üzeneteket, amelyek elnyerik a tetszésedet, ennek jóval kevesebb értelme van, nagyjából a Facebook lájkjának felel meg.

Végül lehetőséged van privát üzenet (direct message) küldésére is, de csak olyanok esetében, akik követnek téged.

Ma már képeket és videókat is feltölthetsz a Twitterre, így színesebbé teheted a csatornádat, nem vagy szigorúan 140 karakterre korlátozva – egyben hatékonyabban hirdetheted is a tartalmaidat, termékeidet.

 

Erre figyelj a profilodon

 

Az első lépés, mint minden esetben, a profilod felépítése.

Figyelj rá, hogy illeszkedjen a branded arculatához.

  • Fejléckép: valami olyat tölts fel, amiről rögtön rád asszociálnak, ami kapcsolódik a tevékenységedhez és átadja az arculatod hangulatát.
  • Profilkép: javasolt, hogy a logódat használd – rögtön felismerhető, egyszerűen beazonosítható.
  • A „handle”, vagyis a név, amellyel a Twitteren elérhető vagy. Ez nem feltétlen kell, hogy egyezzen a felhasználóneveddel.
  • A bio: írd le, mivel foglalkozol, akár azt, mire használatos ez a fiók (például itt publikálod a híreket vagy itt kérdezhetnek tőled).
  • A weboldalad: a fiók rendeltetéséhez képest irányítsd az embereket, megadhatod a blogodat, a webáruház nyitóoldalát, de akár egy landing page-et is.

 

Mit írj, hogyan írj

 

A Twitter nem az a felület, ahol halmoznod kell a tartalmat annak reményében, hogy a későbbiekben organikus forgalmat hoz.

A célod az, hogy reagáljanak arra, amit közzéteszel, ez az engagement (bevonás).

A platform kevés lehetőséget ad neked arra, hogy az üzeneteidet „formázd”, de jó, ha tudsz pár dolgot.

A hivatkozásokat tartalmazó tweetek 86%-kal több retweetet eredményeznek.

Használj linkrövidítő alkalmazást, például a Bit.ly eszközét, hogy minél kevesebb karaktert vegyen el az üzenetedből maga az URL.

(Egyben érdemes azt úgy alakítanod, hogy egyértelmű legyen, a rövidített URL mögötti hivatkozást pedig felparaméterezned, hogy az analitikában pontosan lásd a forgalomforrást.)

 

Igen, beszélgetned kell

 

Tudomásul kell venned, hogy ha a webshopodnak saját csatornája van Twitteren, az ügyfélszolgálati jellegű használata elkerülhetetlen.

A felhasználók java része itt talál meg a leggyorsabban, itt tudnak a legegyszerűbben nyilvánosan kérdezni, üzenni.

A Conversocial egy tanulmánya szerint két év alatt 250%-kal növekedett az ügyfélszolgálati jellegű üzenetek száma a platformon – a felhasználók egyre szívesebben használják ezt az azonnali lehetőséget az érdeklődésre vagy panaszkodásra.

Ennek jó és rossz oldala is van.

A jó az természetesen, hogy azonnal reagálhatsz szinte bármire – ha van erre elegendő időd. (Már csak ezért sem nagy baj, ha van a csapatban egy social media manager, aki az ilyen ügyekkel foglalkozni tud.)

A rossz oldala az, hogy ha felháborodott, csalódott vásárlóval van dolgod, akkor nehéz lehet itt kezelni a panaszokat.

Ha trollok céloznak meg, akkor sem igazán tudod eltüntetni a nyilvánosság elől az egészet, bár kreatív kommunikációval a magad javára is fordíthatod az ilyen eseteket.

 

Ha ügyfélszolgálatról van szó, akkor egyértelműen az Amazon a legjobb példa: Nézd meg, hogyan beszélgetnek folyamatosan a vásárlóikkal. Ha gond adódik, segítenek, de reagálnak a teljesen egyszerű említésekre, feltöltött képekre is, méghozzá nagyon barátságos, közvetlen hangnemben. A világ legnagyobb e-kereskedelmi üzletéről van szó, ügyfelek millióival, mégis képesek úgy beszélgetni a Twitteren a vásárlóikkal, mintha a sarki hentes lennének.

 

Használj hashtageket!

Ez nemcsak 21%-os növekedést hoz átlagosan az engagement arányában, de segít abban is, hogy a megfelelő diskurzusokba kapcsolódj be. Ebben sem hagy magadra a net.

Ott van például a Hashtagify.me, amely segít megtalálni neked az aktuálisan legjobbakat, vagy a Keyhole, amivel egyes hashtageket tudsz követni (ráadásul nem is csak a Twtitteren, hanem az Instagramon és a Facebookon is).

Tartsd viszont észben azt is, hogy míg egy hashtagnél ennyire pozitív a hatás, ha három vagy annál több szerepel a tweetedben, már 17%-kal csökken az engagement.

Ha képeket használsz a tweetben, az a tapasztalatok szerint szintén akár 50%-kal emelheti az elköteleződést – de azért emlékezz, hogy nem az Instagramon jársz.

 

Egy keveset a témákról

 

Olyan nem igazán van, amiről nem beszélhetsz Twitteren, de érdemes meghatároznod, hogy a fiókod pontosan mivel fog foglalkozni.

Zavart kelthet például, ha a kifejezetten tartalomterjesztésre használt accountodon néha ügyfélszolgálati jellegű diskurzusokat is folytatsz, erre két dedikált fiókot is létrehozhatsz.

 

  • Alkalomadtán közzétehetsz promóciókat, új termékajánlatokat, de bánj ezzel óvatosan. Érdemes lehet a twitterezőknek speciális ajánlatokat tenned (ahogy más közönségeknek is), például a nekik szóló promóciós kódot adnod.
  • Tegyél fel kérdéseke Ezzel fokozhatod az aktivitást, de akár kutatási célokra is használhatod, ha például megkéred a követőidet, hogy jellemezzék két szóban a veled vagy termékeddel kapcsolatos tapasztalataikat.
  • Kérd ki a véleményüket – szlogenekről, terméknevekről, logókról, bármiről, amire néhány karakterben is reagálhatnak.
  • Tedd közzé friss tartalmaidat, más csatornákról is mutasd be, mit teszel közzé – blogposztok, YouTube-videók például bátran kerülhetnek ide.
  • Tégy közzé érdekes infografikákat.
  • A rövid, lényegre törő idézeteknek is itt a helye – ezek lehetnek testimonialok, de kerüld a túlzott önfényezést. Inkább legyen hasznos vagy érdekes, mint például az iparági szakértőktől, interjúkból vett megállapítások.

 

Ha brick&mortar üzleted és webshopod is van, akkor például a Home Depot stratégiáját érdemes megnézned.

A Twittert nem öncélúan, hanem egy cross-platform stratégia részeként használják. Megosztanak itt friss tartalmakat (például „csináld magad” témakörben, ami külön nagyszerű húzás), nemcsak bemutatják a terméket, de tippeket is adnak hozzá, hogyan használd, véleményvezéreket, partnereket, testimonialokat tesznek közzé, és szinte minden tartalmuknál a vizualitáson van a hangsúly.

Aztán ott van az Arena Flowers. Virágokat árulnak. Tudod, mit nem találsz a Twitter-feedjükben?

Virágokat.

A cég úgy döntött, nem érdeklik a releváns hashtagek, kulcsszavak, a termékpromóció. Ők egyszerűen egy nagy és lelkes követőtábort akarnak, és ezt humorral érik el.

Egy adott ponton egyszerűen hagyták a korábbi stratégiájukat a fenébe, és elkezdtek vicces képeket, szövegeket feltölteni az idővonalukra.

És ezzel 18 hónap alatt 18 ezer új követőt szereztek, megduplázták az őket megemlítők számát a megelőző év azonos időszakához képest, és összességében annyi embert érnek el, amennyiről egy egyszerű virágküldő szolgálat aligha álmodhat.

 

Mikor tweetelj?

 

Ha aktualitásról van szó, azonnal.

De ha megtervezett, hosszú kampányban használod, akkor érdemes a felhasználói szokásokhoz igazítanod a posztolás idejét.

A Wiselytics szerint egy tweet „élettartama” mindössze 24 perc, ezt követően már nagyon kicsi az esély rá, hogy komolyabb hatást érsz el vele.

Akkor érdemes tehát megjelennie, amikor a közönségedből a lehető legtöbben látják, mert éppen a Twitteren lógnak.

Rengeteg különféle statisztikát mutathatnánk, hiszen abszolút közönségfüggő, ki mikor twitterezik.

Amiben mindenhol egyetértenek, hogy hétköznapokon szerencsésebb posztolni, mint hétvégén.

Napon belül az egyik legszerencsésebb időszak a 12-15 óra közötti, illetve a 17-18 óra közötti – nagyjából ez szűrhető le a Kissmetrics, a HubSpot, a QuickSprout és a többiek adataiból. (A HubSpotnál egy nagyszerű gyűjtést és infografikát találsz erről.)

 

Így találd meg a véleményvezéreket (+eszközök)

 

Ha észre akarod vetetni magad a közösségi médiában, akkor az egyik leghatékonyabb módszer a véleményvezérek megkeresése.

Ez viszont nem egyszerű feladat: a Twtitteren nem találsz listát arról, hogy a te meghatározott közönséged pontosan milyen embereket követ rendszeresen.

A Twitter nagyfokú szervezetlensége és a rengetegféle felhasználó és tartalom okán nehéz megtalálni azokat a fiókokat, akiket követned, retweetelned érdemes, akikkel jó, ha aktívan kommunikálsz vagy ahol jó, ha megjelensz.

Feltételezzük, hogy tudod, kik a konkurenseid a piacon, végeztél már konkurenciakutatást – az ő fiókjaik megkeresésével érdemes kezdened.

Keress rá olyan listákra, amelyeken a szakterületed véleményvezérei szerepelnek.

A Twitter egy idő után magától is elkezd majd olyan felhasználókat ajánlani, akik az általad korábban követettekhez hasonlóak, mindig figyeld, hogy az algoritmus szerint kire kell figyelned.

Trükkökhöz kell tehát folyamodnod ahhoz, hogy a megfelelő embereket megtaláld. És emlékezz arra, hogy akár több tucat vagy több száz is lehet belőlük.

A legegyszerűbb módszer persze az, ha listacikkeket keresel a legbefolyásosabb twitterezőkről egy-egy területen, és ezekből mazsolázod ki a megfelelő jelölteket.

De van más lehetőséged is: a Klear eszközzel például többféle platformon is elemezheted a fiókokat (a Twitter mellett a YouTube-on, az Instagramon és akár blogplatformokon is.)

Bizonyos mértékben még helyi influencerek felkutatására is alkalmas, első körben ugyanis a kategória mellett az országot is megadhatod. Második körben pedig az eredményeket tovább szűrheted, például befolyás, skillek alapján vagy éppen a céges accountokat kiszűrve a listáról.

A tapasztalatok szerint nagyszerűen használható a Little Bird alkalmazás is, amely úgy keres és rangsorol influencereket, ahogyan tíz évvel ezelőtt a Google rangsorolta a honlapokat: az egymáshoz fűződő kapcsolataik alapján.

A logika a következő: ha elég befolyásos véleményvezér vagy, akkor logikus, hogy sok más befolyásos véleményvezér követ téged. Egészen jó arra, hogy egy adott témában feltérképezd a legnagyobb neveket.

Emellett arra is használhatod, hogy a legnépszerűbb tartalmakat figyeld, hogy milyen blogposztokat tesznek közzé a véleményvezérek, szűrhetsz ország szerint is, sőt, előfizetéssel jelentéseket is készíthetsz.

Az Agorapulse arra ad lehetőséget, hogy adott kulcsszavakat kövessünk (több egyéb funkció mellett), lássuk az adott témában megjelenő tweeteket.

Van még benne több hasonlóan hasznos funkció, szűrhetünk például aszerint, hogy kiket retweetelik a legtöbben egy adott időintervallumon belül.

Ezeken felül is rengeteg eszközt használhatsz, az Audiense, a BuzzSumo, a Twitonomy is jól használhatóak adott célokra – azt ajánlom, próbáld ki ezeket, kezdetben használj akár többet is egyszerre, és látni fogod, hogy melyik neked a legkényelmesebb, leghasznosabb.

 

Az e-kereskedő fegyverei

 

Sajnálatos módon a termékkártyák 2015 óta nem elérhetőek a platformon, pedig remek eszköz volt ez az e-kereskedők számára, hogy a 140 karakteren felül extra információkat osszanak meg a közönségükkel.

Másfajta kártyákat azonban használhatsz.

Ha erre a felületre célzol egy kampányt, akkor az érintett termékoldalakba, landing page-ekbe építsd be a kódot, amely alapján a Twitter tudni fogja, hogy milyen információkat kell „behúznia” egy adott linkhez – ilyen a cím, a leírás, a kép.

A leghasznosabb, jelenleg is elérhető típus valószínűleg a website-kártya, amelyhez CTA-t is meghatározhatunk.

Egy másik nemrég végleg elhalálozott eszköz, mellyel az e-kereskedőknek akartak kedvezni, a vásárlásgomb (buy button) volt.

Az okok némileg zavarosak, látszik, hogy nem fókuszáltak erre erősen a cégen belül, de a lényeg, hogy többé nem vásárolhatunk egyetlen kattintással semmit egy tweetből.

 

Mi maradt akkor?

Jelen pillanatban a különféle Twitter-hirdetésekkel dolgozhatnak a kereskedők, ami elég szegényes.

Egyes tweeteket, fiókokat vagy akár trendeket szponzorálhatunk meg, ezzel nagyobb elérést nyerve. Ezek natívan ágyazódnak a felhasználók idővonalaiba.

Ha a brandedet akarod építeni, ha egy új termékről vagy akcióról posztolsz a felületre, akkor ezek hasznosak lehetnek, de abban sajnos nem segítenek, hogy az értékesítést a Twitter felületére vidd, lerövidítsd a vásárlási utat.

 

Különös: Olyan lehetőség, amely jelenleg közvetlen vásárlást kínálna, jelenleg – érthetetlen módon – nem áll rendelkezésünkre.

 

Ugyan 2015 óta beszélnek arról, hogy a vállalat már fejleszti a termékoldalakat, ezen a téren azóta sem sok új hír látott napvilágot.

Néha megemlítik ugyan, de akár arra is fogadhatunk, hogy nemsokára ez az elképzelés is a termékkártyák és a vásárlásgomb sorsára jut.

Ha promotálod a posztjaid, legyenek egyszerűek.

A Twitter saját mérései szerint a 120 karakternél rövidebb üzenetek 8, a 100 karakternél rövidebb üzenetek 18%-kal teljesítenek jobban engagement terén.

A hangvétel legyen közvetlen, érezzék a felhasználók, hogy a „túloldalon” egy ember ül, még akkor is, ha a tweet mellett egy céges logót látnak.

Számos olyan kampányt láthattunk már, ahol az ügyfélszolgálatosok magukat túlteljesítve, egy-egy aktualitás kapcsán közvetlen módon, humorosan válaszoltak minden egyes üzenetre, és a visszhang szinte egyhangúan pozitív.

Ajánlott az is, hogy ne erőltesd az új diskurzust, ne véleményvezér akarj feltétlen lenni, inkább kapcsolódj be.

Ne akard lenyomni a torkukon a terméked, ha a promotált tweetjeidnek csak 20%-ában található valamilyen termékoldalra vagy landing page-re vezető link, az már bőven elég, hiszen a fő cél itt az engagement és a brandépítés.

 

Eszközök a hatékony Twitter-marketinghez

 

Említettünk már néhány hasznos applikációt, amit felhasználhatsz arra, hogy elemezd a Twittert, megfigyeld a követőidet és véleményvezéreket találj.

Ebben az alfejezetben egy kicsit részletesebben bemutatunk néhány igazán nagyszerű eszközt.

 

Social Quant

 

Ha növelni akarod közönséged elköteleződését Twitteren, ezt kell kipróbálnod. Ugyanazt csinálják, mint egy profi közösségimédia-menedzser, csak éppen a big data erejét használva: figyelik a beállított kulcsszavakat és algoritmusokkal elemzik, hogy az egyes diskurzusok résztvevői közül kit érdemes követni, kire érdemes odafigyelni.

Releváns, hűséges, elkötelezett közönséget építhetsz így.

A Social Quant átveszi tőled az építkezés feladatát, hogy nyugodt szívvel a minőségi tartalmak előállítására koncentrálhass.

 

Dripper

 

Ha automatizálni szeretnéd a Twittered, akkor érdemes erre a szolgáltatásra vetned a tekinteted.

A szolgáltatás nemrég indult el – hosszú tesztelést követően, számos influencer bevonásával, hogy mást ne mondjak, Elon Musk személyesen is kipróbálta.

Hogy mire jó? Automatikus említéseket és üzeneteket küldhetsz ki, méghozzá azzal a céllal, hogy twitteres követőidet vásárlókká alakíthasd – a tesztek szerint 10-szer hatékonyabban, mint a korábbi módszerekkel.

 

Post Planner

 

A legjobb tartalom az, amit a közönségedre szabsz.

De hogy ötleteket nyerhess, hogy tudd, valójában mire is vágynak, rengeteg időt kell a kutatásba ölnöd.

Ebben segít a Post Planner: kulcsszavak, hashtagek, Facebook- és Twitter felhasználók figyelésével szolgáltat új tartalmakat és ezzel ötleteket.

Algoritmusok segítségével big data elemzéseket végez és megjósolja, milyen elköteleződést várhatsz egyes közönségek esetében, így a tervezést jóval gyorsabbá teszi.

Az algoritmus még azt is megmondja, hogy a tapasztalatok alapján mikor a leginkább érdemes posztolnod.

 

 

Beszélgetni nem kerül semmibe

 

Mindenképpen próbáld ki a Twittert.

Előtte mérd fel a közönséged – olvasd el cikkünket a szegmentációról, és ha teheted, kérdezd is meg őket arról, hogy használják-e a platformot, és ha igen, akkor mire.

Ha másra nem is jó, az ügyfélszolgálati kommunikációd egy részét ide irányíthatod, és könnyedén kezelheted némi talpraesettséggel.

Használd az eszközöket, amelyeket megmutattunk neked: az automatizáció, az analitika elképesztően hasznos lesz, szinte magától működik majd a Twittered – neked csak arra kell figyelni, hogy stratégiákat, kampányokat dolgozz ki rá és értékes tartalmat gyárts, bármilyen is legyen az.

 

 

Menedzselt hosztolás: a teljes útmutató (alapok, pro és kontra)

Hogyan válassz szolgáltatást?

 

A megfelelő szolgáltató keresése

 

Ebben a fejezetben megvizsgáljuk, hogy ügyfélként mire lehet szükségünk, figyelembe véve a céges ügyvitelünket, működési elveinket, szokásainkat.

 

tips Példa: Ha egy webshopot üzemeltetünk, és vállalkozásunk egy jól kimutatható fejlődési pályára állt, könnyen olyan helyzetben találhatjuk magunkat, amelyben a webáruház üzleti folyamatainak fejlesztése, az új piaci területek meghódítása annyira erőforrás igényes munkafolyamattá duzzad, hogy az ezeket kiszolgáló infrastruktúra működtetését, karbantartását, és a jelentősen megnövekedett igények kiszolgálását nem tudjuk professzionálisan önerőből ellátni.

 

Ilyenkor érdemes számba vennünk, hogy miért lehet érdemes megbízni ezzel egy külsős partnert.

Ugyanis a szolgáltatói szektor szakmai követelményei az utóbbi évtizedben jelentősen megváltoztak – a piac átalakulásának köszönhetően, aki szakmailag valóban a legtöbbet akarja kihozni magából, annak nemcsak elhivatottnak kell lennie, de menedzsmenti szemlélettel, koordinációs képességekkel is rendelkeznie kell.

Milyen jellemzőkre érdemes odafigyelnünk, hogy ha úgy döntünk, szeretnénk hatékonyságunkat célirányosan, egy szakértői team, vagyis egy professzionális szolgáltató bevonásával növelni?

Ha a fejlődés a cél, a fejlesztés kikerülhetetlen. Ennek érdekében tisztában kell lennünk saját kompetenciáinkkal, és a partnerrel szemben támasztott elvárásainkkal is.

Nézzük meg, mit szoktunk keresni ügyfélként a leendő szolgáltatónál!

 

Szakmai felkészültség

 

Természetesen egy jó hoszting szolgáltató legfontosabb tulajdonsága a magas szintű szaktudás.

Igazi értéket, és ütőképes szakmai tudást, a napi munka és tapasztalat, sok-sok éves problémamegoldó, tesztelő és fejlesztő gyakorlat adja.

 

Mindezek felett,

  • a szolgáltatást nyújtó csapat naprakész,
  • szakmájában otthonosan mozog,
  • képben van az újításokat illetően,
  • tudja, hogy az általuk kezelt rendszerekben milyen problémák fordulhatnak elő,
  • és hogyan lehet azokat a leggyorsabban, a legkisebb okozott kényelmetlenséggel és fennakadással megoldani.

 

Megfontolandó tehát, hogy rendszerünket a tudás és tapasztalat széles és speciális spektrumával rendelkező szakemberek egy csoportjára bízzuk, akik a nap 24 órájában rendelkezésre állnak, vagy egyéni rendszergazdánk egyedi tudására és idejére tudunk csak támaszkodni.

 

Kommunikáció, ügyfélközpontúság

 

A technikai tudás mellett, nagyon fontos a kommunikációs készség is.

A szolgáltatónak fel kell tudni mutatni olyan szakembert vagy szakembereket, akiknek az ügyfelekkel aktívan kommunikálniuk kell.

Vele beszélnek, ha a rendszerindító tervezéséről, optimális kialakításáról, installálásáról, majd később fejlesztésről, javításról van szó, ha kérdések akadnak vagy problémák lépnek fel.

Éppen ezért a szolgáltatónak, ha igazán sikeres akar lenni a szakmájában, tudnia kell tisztelettel és türelemmel bánnia minden egyes partnerrel. Azt kell, hogy érezze az ügyfél, hogy rendszere profi és gondos kezekben van, ahol a szolgáltatónak alapvető szempont a megbízható, gyors és magas szintű segítségnyújtás, válaszadás, együttgondolkodás.

Ennek része az is, hogy érthetően és világosan tudja kifejezni magát, úgy szakértővel, mint a szakmát kevésbé ismerővel történő egyeztetés során.

Sok esetben nem képzett informatikus van a vonal másik végén, így fontos, hogy el tudja magyarázni, át tudja adni a szakmai jellegű információt úgy, hogy azt a laikusok is megértsék, és ne úgy érezzék, hogy hozzá nem értőként kezelik őket.

Az előzőek után érdemes elgondolkodnunk, mennyire fontos számunkra, hogy türelmes, pontosan érthető és szolgáltatói attitűdre kiemelkedő hangsúlyt fektető szolgáltatót választunk.

 

Specializált tudástár, felelős csapat

 

Nagyobb rendszerek esetén elengedhetetlen, hogy ne csak egy ember foglalkozzon azok felügyeletével, karbantartásával, a probléma-elhárítással.

Át kell látnia a feladatokat, munkafolyamatokat, a felmerült probléma alapjait, mibenlétét, hogy aztán szakszerűen és hatékonyan össze tudja hangolni a csapat munkáját a lehető leggyorsabb és legszakszerűbb eredmény elérése érdekében.

A rendszergazdának tehát képesnek kell lennie arra, hogy munkatársakat irányítson, munkafolyamatot ellenőrizzen, abban folyamatosan együttműködjön, majd az elkészült munkát minőségében ellenőrizzen.

 

Mit válasszunk tehát?

Mi a jobb?

1) A rendszerünket egy állandóan tevékeny és speciális tudással rendelkező csapatra bízzuk?

2) Vagy bár lehet profi, de erősen limitált erőforrással, idővel és lehetőségekkel rendelkező egyéni szakértőkre, rendszerint hasonló költség-nagyságrenddel?

 

Proaktivitás

 

A szolgáltató – optimális esetben – nemcsak passzívan szemléli a gondjaira bízott rendszereket, hanem aktívan tesz azok jobbá tételéért.

Ha kell, megfelelő technikai változtatásokat és fejlesztéseket kezdeményez, hogy a korábban tapasztalt problémákkal még egyszer ne kelljen bajlódni, hogy elkerülhető legyen azok megismétlődése.

Ha pedig úgy látja, hogy az ügyfél igényeit jobban kiszolgáló megoldás is lehetséges, vagy egy másik típusú szolgáltatás volna megfelelő, ezt egyértelműen jelzi.

 

Saját igényeink és kompetenciánk felmérése

 

A példa kedvéért vegyünk alapul egy webáruházat, és ennek tükrében vizsgáljuk meg, a helyzetet!

Ahogy azt korábban említettük, nemcsak a szolgáltatóval szemben kell megfogalmaznunk elvárásainkat, de a siker érdekében, fontos, hogy tisztában legyünk saját előnyeinkkel, vagy épp hiányosságainkkal is!

Próbáljuk meg 6-8 mondatban leírni, hogy mi a tervünk a mostani oldalunkkal, és hogyan látjuk azt a következő 1 évben.

Ha ez megvan, igényeink pontos megfogalmazásához tegyük föl magunknak az alábbi kérdéseket:

  • Milyen megoldásra keresünk hosztingot (pl.: WordPress blog vagy eCommerce)?
  • Van-e meghatározott verzióigény bármilyen webtechnológiára (pl.: PHP verziószám)?
  • Szükség van-e speciális szoftverek futtatására, egyéb külső alkalmazásokra?
  • Kezdetben mekkora forgalomra számítunk? (A várható hálózati terhelés miatt.)
  • Melyek azok a külső szolgáltatások, technológiák amiket preferálunk vagy szeretnénk csatlakoztatni?
  • Mennyire fontos a kiszámítható, előre tervezhető IT budget?

 

Azzal is érdemes tisztában lennünk, hogy jelen erőforrásainkkal mit tudunk lefedni a megvalósítandó feladatokból.

Mire van cégen belüli megoldás, mi az amit „kintről” kell beszereznünk?

Amennyiben ezekre megfelelő választ tudunk adni, át kell gondolnunk, hogy a felszabaduló kapacitást, hogyan tudjuk befektetni, újrahasznosítani!

 

Számba kell vennünk azokat a pontokat is, amivel ügyfélként rendelkezünk:

  • Van hozzáférésünk a naprakész statisztikákhoz (amiből a szolgáltató esztimálhat, Google Analytics)
  • Ha már használunk valamilyen infrastruktúrát, az alapvető hálózati topológiával és specifikációval kerüljünk tisztába (ha eddig nem tettük volna meg)
  • Nem kell szakértőnek lennünk a témában, de jó, hogy ha tudjuk, mik a piaci trendek, és a fejlődési irányok
  • Ismerjük a menedzselt szolgáltatások, felhő szervizek alapjait, jellegét

 

Ezek az információk azért is fontosak, hogy csak olyan szolgáltatásokat rendeljünk meg, amikre valóban szükségünk van.

Amennyiben professzionális partnert keresünk terveink megvalósításához, lépjünk fel mi is profi ügyfélként.

Ha már a fenti pontokkal tisztában vagyunk, nézzük meg, hogy milyen hoszting típusokkal találkozhatunk, és melyik nyújtja a legjobb megoldást, hogy üzletünk új fejlődési szintre léphessen!

 

Hosztolás, menedzselt hosztolás,  menedzselt ecommerce hosztolás

 

Vizsgáljuk meg, mi a különbség a hagyományos hosting, a manage-elt hosting, és a speciális „eCommerce managed hosting” megoldások között!

 

Hosztolás (Hoszting)

 

A hoszting szolgáltatás olyan (szervereken futó) szolgáltatás, ami lehetőséget biztosít különféle tartalmak interneten történő megjelenítésére bárki számára.

A szolgáltatásnak különféle szintjei és fajtái vannak. A legelterjedtebb a webhosting (web tárterület), amely weboldalak üzemeltetésére szolgál. Kiegészítő szolgáltatásként gyakran e-mail cím üzemeltetés, illetve DNS szolgáltatás tartozik hozzá, amely a domain nevek üzemeltetéséhez kötődik.

Általában induló vállalkozások alap igényeit ki is elégíti, és többnyire „házon belül”, a helyi IT csapat látja el az ezzel kapcsolatos munkálatokat, hiszen általában egyetlen szerverről beszélünk, vagy egy nagyon egyszerű szolgáltatás igénybevételéről, amit egy speciális panelen keresztül érnek el.

Mivel nincsenek, vagy nem számítanak hirtelen forgalom- és ezáltal gyorsan megugró kapacitásigény-növekedésre, vagy, mert az alkalmazás nagyon egyszerű, ezért nem igényel speciális környezetet, finombeállításokat, így gyakran ugyanaz a szerver szolgálja ki a webshopot és az eseleges adatbázist is.

Ez az indulást követő időszakban még elégségesnek bizonyulhat, de később a megnövekedett piaci igények kiszolgálására nekünk is fejlődni kell.

 

Ez pedig állandó beruházásokat jelent: nemcsak a növekedő géppark megújítása (fizikai tárolás, fejlesztés, karbantartás), a meglévő szolgáltatás kiterjesztése, de ennek az üzembiztos működtetéséshez nélkülözhetetlen kompetenciáért is egyre többet kell majd fizetnünk (értelemszerűen a komplexebb rendszereket üzemeltető szakértelmet egyre magasabb áron szerezhetjük, és tarthatjuk csak meg).

Ezért kijelenthetjük, hogy közép-hosszú távon egy webáruház üzemeltetéséhez jellemzően nem megfelelő egy hagyományos webtárhely szolgáltatás.

A nagymértékben változó forgalom (pl. karácsonyi roham) által generált többletterhelést csak jelentős tartalékokkal rendelkező szerverek képesek biztonsággal kiszolgálni, ezt általában nem biztosítják a tárhely szolgáltatók.

Nincs kellemetlenebb annál, mint amikor az ünnepek környékén a megnövekedett terhelés miatt a szerver belassul, vagy a szolgáltató adatforgalmi korlátozást vezet be, jelentős veszteséget okozva ezzel a webshopot üzemeltető cégnek.

Jellemző, hogy a webshopok számára egyedi PHP beállítások, speciális konfiguráció szükséges, melyeket a hagyományos shared-hosting konstrukcióban a szolgáltatók nem képesek maradéktalanul kiszolgálni, vagy követni.

Az is gyakori, hogy az áruházat fejlesztő szakemberek számára szükséges a napi és közvetlen kapcsolattartás a szervert üzemeltető személyekkel, mely szintén nehézkes vagy megoldhatatlan tud lenni egy hagyományos tárhely szolgáltatás esetében.

Ennek kivédésére szolgálhat egy stratégiai döntés, hogy olyan cégekkel működjünk együtt, ahol egy kézben összpontosulnak a webshop-fejlesztéshez és annak hosztolásához szükséges kompetenciák!

 

Menedzselt hosztolás (magaged hosting)

 

A menedzselt hosztolás egy olyan IT modell és egyben szemlélet, amelyben a hosztingot nyújtó cég, mint szolgáltatást, bérbe adja a szervereket és az egyéb kapcsolódó hardveres, valamint emberi erőforrásokat, szakértelmet ügyfele számára.

Az igénybe vett eszközök, vagyis minden berendezés, és az ezeket üzemeltető, felügyelő, karbantartó szakértői csapat az ügyfél szék- és telephelyeitől eltérő földrajzi területen található, és a szolgáltató, vagy egy harmadik fél tulajdonában van.

Elsősorban abban különbözik a többi dedikált hosztingtól, hogy a szolgáltató kezeli a hardvert, az operációs rendszer(eke)t és az egyéb alkalmazásokat.

Az ügyfél általában adminisztratív hozzáférést kap, de rendszerint ritkán használja ki ezt a lehetőséget, ehelyett inkább eléri, és használja a bérelt rendszer erőforrásait egy webes felületen keresztül, továbbá igénybe veszi a 24/7/365-os support csapatot, ha valami problémával, vagy jövőbeni fejlesztési igénnyel kapcsolatban kérdése merül fel.

 

Jellemzően a tárhely szolgáltató felelős

  • a hardver üzembe helyezéséért, konfigurálásáért,
  • a szoftverek telepítéséért,
  • technikai támogatást nyújt,
  • felügyeli, menedzseli az erőforrásokat,
  • detektálja, és elhárítja az esetleges felmerülő problémákat,
  • valamint frissítéseket telepít.

 

Még egyszerűbben fogalmazva a „managed hosting” lefedi az ügyfél helyett, annak kényelmére az üzemeltetést és karbantartást. A klasszikus „hosting” megoldás szimplán a környezet és az erőforrások bérlése a szolgáltatótól.

 

Példa: A felhő szolgáltatások és a közüzemi fogyasztások, mondjuk a vízhasználat összehasonlítása. Az ügyfelek ebben az esetben is egy tőlük független, más tulajdonában lévő rendszerre csatlakoznak, amikor megnyitják a csapot.

Ez azt is feltételezi, hogy a működtetéshez szükséges folyamatokkal sem kell foglalkozniuk, hiszen nekik csupán egy a fontos: amikor szükségük van rá, folyjon a víz, legyen szolgáltatás.

Az elhasznált mennyiség után pedig díjat kötelesek fizetni. A menedzselt erőforrások használatakor ugyanez történik: az ügyfél használja a hosztoló cég tulajdonában lévő erőforrásokat.

 

Egy speciális területe ennek a szervizfajtának a felhő alapú (cloud) megoldások tárháza.

A fogyasztók egy bizonyos része sokszor nincs is tisztában, hogy tudtán, vagy akaratán kívül is adatai valamilyen felhő részét alkotják.

Erre az egyik legegyszerűbb példa az Apple termékeket vásárlók tömege: a telefont be sem üzemelhetjük az úgynevezett iCloud fiók létrehozása nélkül, ami kérdezés nélkül – ahogy azt neve is mutatja – azonnal szállítja profilunkat és a hozzá kapcsolódó adatokat a felhőbe.

Ezenfelül léteznek egyéb szolgáltatások is, amelyek szolgáltatótól függően már egy alapcsomag részét képezhetik, vagy extra szolgáltatásokként kerülnek felajánlásra.

 

Tipikusan ilyenek

  • a biztonsági mentések (backups),
  • a hálózati terhelés elosztása (load balancing)
  • és a súlyos, üzletfolytonosságot negatívan érintő hibák, összeomlások,
  • ide vehetjük még a „katasztrófa” utáni helyreállítást (disaster recovery),
  • valamint a biztonsággal kapcsolatos folyamatok, mint például a jogosulatlan behatolás figyelését (Intrusion Detection, azaz ID) és elosztott túlterheléssel járó támadás (DDoS) elleni védelmet.

 

Ahhoz, hogy elérjük vállalati céljainkat, egy mérhető skála alapján, a hosztoló cégnek nem pusztán professzionális technikai szolgáltatónak, hanem megbízható partnernek is kell lennie.

Ezért most elsősorban a PaaS és IaaS szolgáltókra gondolunk. Ezekbe a csoportokba tartoznak azok a cégek, akik megbízhatóbbá, kiszámíthatóbbá tehetik az üzletünket érintő mindennapos IT működésünket.

A korábbi Cloud Hosting-gal foglalkozó cikkünkben már definiáltuk a PaaS és IaaS szolgáltatókat.

Ezek a cégek hozzáférést biztosítanak a megosztott adatközpontokhoz, így nyújtva számunkra – függetlenül cégünk méretétől – a redundáns, megbízható működést.

Ezzel időt és pénzt takaríthatunk meg, mert nem kell az újabb és újabb hardveres fejlesztéseinket megvásárolni, ezeknek az eszközöknek a megfelelő tárolásáról, karbantartásáról gondoskodni, ezért szó szerint értendő, hogy csak fogyasztásaink után kell fizetnünk.

Ezek a szolgáltatások egyaránt költséghatékonyak a rövid távú projektek, de a jó skálázhatóság miatt, a hosszú távú üzleti elképzelések kiszolgálásához, on-demand típusú források igénybevételéhez is.

Például, néhány percen belül megduplázhatjuk a memória kapacitásunk mennyiségét, hogyha honlapunknak szüksége van extra erőforrásra a hirtelen megugrott látogatószám kiszolgálása érdekében.

Ügyfél oldalról az egyik visszafogó erő szokott lenni az adatbiztonságban való kételkedés.

Ez egyfelől technológiai, másfelől szemléleti kérdés. Egy részük még mindig nehezen tudja elfogadni, hogy üzletkritikus adataik egy másik fél számítógépén helyezkedjenek el.

Pedig az, hogy ragaszkodunk szervereink fizikai közelségéhez, egyáltalán nem garantálja a nagyobb biztonságot, sőt! Egy sértett, saját igazát kereső alkalmazott gyakran nagyobb károkat képes okozni, mint egy esetleges külső támadás.

Pontosan ezért a hoszting cégeknek több biztonsági szabványnak és elvárásnak kell megfelelnie, hogy elnyerje ügyfele bizalmát mivel az adatok nem megfelelő kezelésével saját reputációját, végső soron működését sodorja veszélybe.

 

Előnyök és hátrányok (nem menedzselt vs. menedzselt hosztolás)

 

Sok jellemzőt, tulajdonságot és példát hoztunk fel a két szolgáltatási gyakorlattal kapcsolatban.

A könnyebb átláthatóság kedvéért foglaljuk ezeket egybe, nézzük meg egymás mellett, melyek a lényegi különbségek a menedzselt, és a klasszikus hoszting között:

 

nem-menedzselt-hoszting-hu

 

menedzselt-hoszting-elonyok-hu

 

Akkor melyik megoldás a jobb?

 

A helyzet az, hogy rosszul tesszük fel már eleve a kérdést. Azt látjuk már, hogy mennyire és miben különböznek egymástól.

Az igazi kérdés az, hogy melyik illeszkedik jobban a megoldandó feladatokhoz, melyik tudja kiszolgálni az üzleti igényeinket?

Menedzselt hosztolást érdemes választani, ha:

  • kisebb vállalkozásban vagyunk, és szerényebb, limitált IT erőforrásokkal rendelkezünk, mind az emberi kompetenciák, mind a hardware terén
  • az IT budget-ünket következetesebbé, átláthatóvá kívánjuk tenni
  • nincs időnk, szakértelmünk a szerver konfigurációval bíbelődni
  • inkább az üzletfejlesztésre kívánunk fókuszálni a napi IT problémák megoldása helyett
  • hajlandók vagyunk kiszervezni az infrastruktúránkat, és más kezébe adni annak felügyeletét

Klasszikus hoszting mellett maradjunk, amennyiben:

  • mi, vagy a munkatársaink tapasztaltak a webszerverek üzemeltetésében
  • , és 1-2 informatikai szakembernél többel nem működünk együtt, vagy nem szeretnénk, illetve tudunk nagyobb csapattal együttműködni
  • van időnk és tudásunk a távoli erőforrásokat konfigurálni, karban tartani
  • ha idegen tőlünk, hogy egy megbízott hozzáférjen adatainkhoz, és bizalmasan kezelje azt

 

Voltaképpen, hogy mi előny és hátrány, azt nagyban a céges ügyvitelünk, vagy az ezt szabályozó környezet határozza meg!

 

Szolgáltatók

 

A fentiek fényében összeállíthattuk már, hogy milyen irányban tudunk lépéseket tenni, pontosabban melyik szerviz típus ad kielégítőbb választ a minket érő mindennapi IT kihívásokra.

A szekciónak megfelelően essen szó pár menedzselt hoszting szolgáltatóról a teljesség igénye nélkül, hiszen egy igencsak széles skáláról kell szűrnünk!

Akárcsak a piaci szereplők, úgy az árspektrum is nagy. Előző cikkünkben említettük, hogy menedzselt hoszting esetén milyen árazásra érdemes számítani.

A szolgáltatók már igen alacsony, havi 4-5 dolláros szinten kínálnak megoldásokat, mint például a SiteGround. Az ügyfelekért vívott harcban persze nem csupán a padlóáras fegyverkezés az egyetlen stratégia!

Sok esetben találunk pénzvisszafizetési garanciával működő cégeket, ahogy teszi ezt a HostGator is. A hozáadott értéket növeli, ha az ügyfél minél nagyobb biztonságban érezheti magát.

Ez nem csupán IT biztonsági kérdés, hanem egyben kényelmi faktor is. Igen gyakori, hogy az ügyfeleket az év minden napján, annak minden órájában elérhető támogatás fedi le, ehhez nem egyszer nagyobb call-center kiépítése is szükséges a hosztoló részéről.

Többek közt ezt hangsúlyozza ki az Integrated Computer Services, vagy épp az A2 Hosting. Ha pedig nagyobb infrastruktúrára van szükségünk, és ennek a finanszírozása nem jelent gondot, akkor költségesebb megoldásokban is gondolkodhatunk: pl. liquidweb vagy peer1.

Mindenképp tartsuk észben hogy – bár lehet a szolgáltatási leírások, és ez a modell jelenthet megoldást az elképzeléseinkre – az ilyen típusú hoszting és / vagy managed hosting cégek csak az infrastruktúrát kezelik, ezért vállalnak felelősséget, az alkalmazással kapcsolatos munkák, feladatok, rájuk már nem vonatkoznak!

Bevett szokás mára, hogy a legtöbb esetben live chat formában fel tudjuk tenni kérdéseinket a megfelelő személynek, amikor valamely MSP (Managed Service Provider) honlapját böngésszük.

Szinte minden esetben releváns válaszokat kapunk, ezért ha nem akarunk hosszasan lapozgatni a szolgáltatás leírások, SLA dokumentumok között, érdemes ily módon beszerezni az információkat.

Mivel közelítő árat is csak akkor fogunk megtudni, ha a projektünkkel kapcsolatban megfelelő számadatokkal láttuk el a partnert, ügyfélként elsősorban az adatbiztonságra, rendelkezésre állási időre kérdezzünk rá!

 

Tájékozódjunk a teljesebb kép érdekében

  • a vállalható hűségidőről,
  • az infrastruktúra skálázhatóságáról,
  • a jelenleg használt és jövőben bevezetni kívánt alkalmazásokról,
  • a támogatás és a tanácsadás menetéről!

 

Akármelyik menedzselt hoszting szolgáltató mellett döntünk, az ügyfél szempontjából mindenképp van egy kedvező tény, amit minden MSP-nél megtalálunk: az árazási modell.

A PaaS és IaaS szolgáltatók akár órára pontosan képesek költségeinket fogyasztás alapon meghatározni, legyen szó folyamatról, vagy hardverről. Ezek a hardverek lényegében egy-egy különálló, virtuális gépet jelentenek, amelyeken egy, vagy akár több száz alkalmazás is futtható egyszerre, itt tárolódhatnak adataink, és ezek a szolgáltatás legnagyobb anyagi kitettségű részei.

 

Menedzselt ecommerce Hoszting

 

A fentebb említett körülmények végett, előbb-utóbb szükségét érezzük majd annak, hogy webshopunkat egy, választott keretrendszerre optimalizált futási környezetbe helyezzük.

Ezért a hoszting szolgáltatók külön ki is emelik az eCommerce hosztolási lehetőségeiket, melyekben garantálni tudják a boltunk folyamatos üzembiztonságát és a megfelelő HW / SW támogatással a leghatékonyabb működést elérni.

Ez egy olyan szolgáltatási forma, mely akkor jön létre, ha a webáruházunk a szolgáltató által a keretrendszer igényeihez szabott futási környezetben van elhelyezve. Ez lehet bármilyen szerveren felhőben és privát környezetben, a lényeg, hogy a futtató környezet igényeihez legyen igazítva.

Mivel minden webshop keretrendszer egyedi tulajdonságokkal bír, nincs két egyforma menedzselt hoszting megoldási recept sem.

Ezért jelenik meg alapvető igényként, hogy a szolgáltató munkatársai ismerjék a kiválasztott rendszert, hiszen pont az ezzel való aprólékos háttérmunka az, ami alól tehermentesíteni kívánják az ügyfelet.

 

Ebben benne kell, hogy legyen

  • a rendszer karbantartása,
  • hardveres konfigurációk beállítása,
  • szoftverek telepítése, felügyelete (monitorozás),
  • frissítések,
  • patch-elések,
  • és az ügyfél kérdéseit, kéréseit, megválaszoló, illetve kielégítő technikai támogatás, segítségnyújtás.

 

Ehhez kiegészítő megoldásokként általában opcionálisan választhatók

  • a biztonságot és teljesítményt növelő egyéb szolgáltatások,
  • terhelés kiegyensúlyozása,
  • az automatikus skálálzás,
  • optimalizálás (load balancing),
  • az összeomlás utáni ambuláns helyreállítás (disaster recovery),
  • sebezhetőségi vizsgálatok,
  • performancia tesztek,
  • jövőbeni fejlesztéskre tett ajánlatokkal kapcsolatos konzultációk.

 

Minden webshop keretrendszernek meg vannak a maga igényei és az az IT környezet, amelyben a leghatékonyabban lehet azt működésre bírni.

Az ehhez szükséges szakértelemnek is szolgáltató birtokában kell lennie, így ügyfélként ez a teher nem a mi vállunkat nyomja majd. Ezeknek a finomhangolt eljárásoknak köszönhetően biztosak lehetünk benne, hogy webáruházunk mindig készen áll az ügyfelek kiszolgálására, és a lehető legjobb teljesítményt is nyújtja.

Nézzük meg, melyek azok a területek, ahol a webshopokra fókuszáló menedzselt hosztolás, mint szolgáltatási forma a gyakorlatban is a hasznunkra válik webáruházunk szemszögéből.

 

Preventív menedzsment

 

Az egyik legnagyobb előnye a szakemberek által kezelt erőforrásoknak, hogy az időben történő beavatkozásokkal segít megakadályozni fellépő problémákat.

Szoftver kompatibilitási ellenőrzések, a biztonsági vizsgálatok és a teljesítmény monitorozása segít a szolgáltatónak felismerni és kezelni a kisebb anomáliákat, mielőtt azok súlyos problémákká alakulnak, és nagymértékben rombolják a konverziós rátát, vele a webshop reputációját is.

 

Oldalbetöltési sebesség

 

A lassú betöltődés befolyásolja a keresőmotor rangsorolását, és könnyen elriasztja a potenciális ügyfeleket.

Míg néhány esetben a túlzott terhelést okozhatja a honlap helytelen konfigurációja, gyakran a szerver sebessége is gátat szab a zavartalan működésnek.

Azonban az eCommerce-re specializált szerver hoszting esetén a felelős csapat figyeli és észleli a teljesítménnyel kapcsolatos problémákat, valamint alkalmazza a napjainkban elterjedt különféle gyorsítótárazási technológiákat, így biztosítva hogy az webhely gyorsan töltődjön be, nem számít, hogy mekkora forgalommal kell megbirkóznia.

 

Elérhetőség

 

Egyszerű: ha webshop nem érhető el, nem generál forgalmat, elesünk a bevételtől.

A szolgáltatók garantálják, hogy az így üzemeltetett oldalak éves tekintetben 99.5% -os rendelkezésre állási aránnyal működnek. Ennél még nagyobb biztonság is elérhető, ha professzionális szolgáltatót választunk, ahol a megosztott erőforrások eleve redundánsak.

 

Biztonság

 

Az IT védelem mindkét fél számára kiemelten fontos. A menedzselt hoszting rendszerében a kétoldalú felelősségi határok pontos meghatározása a jellemző.

A szolgáltató pedig általában leveszi a terhet a vállunkról, ami a szerver(ek), szoftverek, használt alkalmazások konfigurációját, frissítését, hibajavítását jelenti.

A vírus- és a kibertámadások elleni védelem, annak naprakészen tartása sem az ügyfél gondja, ha a megfelelő szolgáltatót választjuk.

Mindezek tudatában érdemes sorra vennünk, hogy a vállalkozásunkkal kapcsolatos terveink mennyire állnak összhangban a jelenlegi infrastruktúránkkal, mennyire tudja elképzeléseinket támogatni, kiszolgálni a jövőben.

Ezért fontos az, hogy pontosan írjuk le magunk és a felhő szolgáltató partnerünk számára üzleti víziónkat, elvárásainkat, hogy a kiszolgáló a legjobb megoldást tudja kínálni!

 

Menedzselt Magento hosztolás a gyakorlatban

 

Amennyiben olyan lehetőség után kutatunk, ami kifejezetten a webáruházunkra lett tervezve, akkor a specializált tudásért és szakértelemért általában nagyobb összeget kell fizetnünk, mint az általános megoldásokért cserébe – de ez persze nemcsak a menedzselt szolgáltatások világában van így.

Ha például Magento webáruházunkat szeretnénk a leginkább megfelelő környezetbe helyezni – és eszerint válogatunk – jó pár szolgáltatóval fogunk találkozni, akiknek esettanulmányaik és referenciáik bizonyítják, szavatolják hozzáértésüket.

Találhatunk olyan hoszting céget, aki több eCommerce keretrendszer specialistájának hirdeti magát. Az MGT Commerce extrém gyors betöltési sebességgel szolgálja ki ügyfeleit, ha valakinek pedig nemcsak a gyorsaság, de a naprakész újítások is fontosak, annak érdemes megnézni a Nexcess nyújtotta lehetőségeket.

Ezekre a cégekre jellemző, hogy saját szerverparkkal is rendelkeznek, akárcsak a nagyobb felhőóriások (Amazon, Windows, Google). A magántulajdonban lévő infrastruktúra mellett olyan megoldások is próbálják meggyőzni a leendő ügyfeleket, mint a kifejezetten egy adott eCommerce típusra optimalizált VMI (Virtual Machine Image), amit kínál többek közt a Bitnami is.

Fontosak az akkreditált, vagy certifikációkkal megerősített kompetenciák.

A szolgáltatónak alapvető kérdés, hogy ismerje az általa kezelt, felügyelt környezetet, amiben az ügyfél adatait kezeli.

Az partner bizalmát nem csupán a versenyképes ár nyeri el, a cég erősíteni tud a pozícióján a használt technológiákhoz tartozó folyamatos képzéseken való részvétellel és az ott megszerezhető képesítésekkel.

Mi az AionHill-ben úgy látjuk el mindennapi feladatainkat, hogy csapatunkban több Magento Developer vizsgával rendelkező fejlesztő is dolgozik, az Amazon Web Services (AWS) cloud szervizeit pedig több éves gyakorlattal rendelkező és akkreditált rendszergazdáink felügyelik.

 

Menedzselt hosztolás felhő alapon

 

A menedzselt szervizek piacán erőteljes növekedésnek indultak az elmúlt években a felhő szolgáltatások.Arról korábban értekeztünk, hogy mit is jelent a gyakorlatban, ha valaki a „felhőbe” a migrálja adatait, és kizárólag innen látja el a napi rutinjait.

A lényeg, hogy az ügyfél számára fizikailag elérhetetlen erőforrásokat bocsátanak rendelkezésre – amivel akár teljes üzleti tevékenységét le tudja fedni – amit rendszerint egy webes felületen keresztül ér el fogyasztó.

Eddig az effajta IT stratégia csak a közepes és nagy vállalkozások privilégiuma volt, azonban a technológiák csiszolásával és a szemlélet terjedésével a kisebb vagy jó értelemben véve egyszerűbb felépítésű cégek számára is megfizethető közelségbe került vállalati felhő struktúra.

Ez nemcsak egy informatikai hóbort, nagyon markáns és erőteljes trenddé vált a „cloud computing”, a mamutvállalatok számítástechnikai mindennapjai – robusztus méretüknél fogva – pedig elképzelhetetlenek kiszervezett, vagy cloud technológiák nélkül.

A Cloudswave kutatása is azt jelzi, hogy emelkedő felhő-szolgáltatások folyamatos növekedésben vannak globálisan vizsgálva.

 

OnCloud vs. OnPremise (Off Cloud)

 

Ha a mai paci kínálatot vesszük górcső alá, ahogy a felhő (cloud), úgy a helyi, vagy házon belüli (on-premise) megoldások közt is találunk olyat, ami leginkább igazodik működési elveinkhez, gyakorlatainkhoz.

Az sem szokatlan, hogy az ügyfél mindkét szolgáltatásfajtából igénybe vesz elemeket, ezt nevezzük hibrid megoldásnak. De nézzük meg előbb, milyen előnyökkel vagy hátrányokkal szembesülhetünk a két szerviztípus választásakor.

Felhő-alapú megoldásokkal találkozunk nap mint nap, gyakran veszünk igénybe magánemberként is olyan szolgáltatásokat, melyekről nem is feltétlen tudjuk, hogy használatával a felhőben tevékenykedünk (pl.: Dropbox, Spotify stb).

Lassan minden szoftvernek elkészül egy cloud verziója, és azt halljuk szinte minden médiumban, hogy ez az informatikai fejlődés kikerülhetetlen trendje, minden cég előbb-utóbb a felhőben „végzi”. Ahhoz, hogy felelős döntést tudjunk hozni a felhő bevezetéséről vagy arról, hogy egy hibrid megoldásban milyen arányban érdemes alkalmazni a technológiákat, meg kell vizsgálnunk saját céljainkat, belső működésünket is.

 

„OnPremise” jellemzők:

Akkor használjuk a fenti jelzőt, ha az intézményi megoldások a hagyományos, „házon-belüli” módon vannak telepítve és üzemeltetve, helyi IT munkatársakkal, és cégen kívül csak általában a hálózatot szolgáltató partnerrel vannak szerződésben.

Ebben az esetben minden hardver és szoftver a vállalkozás tulajdonában van, ennek teljes anyagi, könyvelési vonzatával.

A teljes felelősség azok kezeléséért, karbantartásáért az intézmény saját maga felel, vagyis a teljes infrastruktúra a cég falain belül marad.

Bizonyos esetekben részfeladatokra megbízhatnak rendszer-integrátorokat, de a fizikai védettségről (pl.: az adatközpont vagy akár egy kis szerverterem megfelelő elhelyezése, az eszközök tárolása, a terem hűtése), az elektromos hálózat felügyelete, szintén a vállalkozás felelőssége. Még akkor is, ha távoli adatközpontokban bérlünk megosztott, vagy virtualizált erőforrásokat (VPS).

 

„OnCloud” jellemzők:

Akkor beszélhetünk ezekről a megoldásokról, ha az intézményünk munkatársai egy tőlünk független szolgáltatótól veszik igénybe a HW / SW erőforrásokat.Gyakorta az ezekkel a szolgáltatásokkal dolgozó egyéneknek nincs is tudomásuk az erőforrások fizikai hollétéről – és az esetek többségében ez számukra teljesen irreleváns is.

Az adatközpont, a szoftverek, az ezeket működtető tudás gyakorlatilag minden a partner tulajdonát képezi.

Általában kötött időtartamra szerződnek a vállalkozással egy adott projektre, de sok példa van arra is, hogy a szolgáltató és fogyasztó hosszú éveken át kitartanak egymás mellett.

Ezek a szolgáltatók általában több cég kéréseit fedik le.

Az is bevett szokás, hogy a szolgáltató egy harmadik fél infrastruktúráját bérli, és ennek a kezelését, konfigurációját oldja meg az ügyfél helyett.

A felelősség lehet megosztott vagy kizárólagosan a szolgáltatóé – ezt mindig a szerződési feltételek döntik el – de általánosan megállapítható, hogy a hosztoló azért kell felelősséget vállaljon, amit szolgáltatásként nyújt a partnere számára.

Ha az egy adatközpont, akkor felel a szerverekért, a telephely biztonságáért, a hálózatért. Ha egy szoftvert nyújt szolgáltatásként, akkor annak konfigurálásáért, támogatásáért, a cég ügymenetébe való integrálásáért szokás felelősséget vállalni.

 

Melyik megoldás a jobb?

 

Jelen cikkünkben többször kitértünk arra, hogy minden annak fényében kell vizsgálnunk, hogy mi az, ami ügyfélként a leghatékonyabban segíti a mi működésünket, fokozza hatékonyságunkat és ésszerűsíti, egyben átláthatóvá teszi az informatikai vonatkozású költségeinket.

Ehhez segítséget nyújt az alábbi táblázat, melyben megvizsgálunk bizonyos szempontokat, és feltüntetjük az adott jellemzőt illetően melyik megoldás előnyösebb:


menedzselt-hosztolas-melyikjobb-hu

 

OnPremise (Off Cloud) szolgáltatók, megoldások

 

Ezek a hoszting cégek méretüknél és szemléletüknél fogva jóval hajlamosabbak a hibrid megoldásokra is az ügyfélérdeket szem előtt tartva.

Általában kevésbé költséghatékonyabbak mamutméretű versenytársaiknál, ezt igyekeznek személyre szabottabb szolgáltatásokkal ellensúlyozni.

Ha nem is akkora számban, de rendelkeznek saját adatcentrumokkal, amelyekkel széles skálán tudják lefedni ügyfeleik számításkapacitási vagy tárhelyigényeit – általában globálisan 3-5 lokációról beszélünk.

A Zadara Storage például igen nagy hangsúlyt fektet a privát felhő nyújtotta privilégiumokra, mint VPSA Storage tömbökre és a ZIOS objektum alapú tárolási megoldásaira.

A cég a hitvallása szerint a felhő flexibilitását nyújtja anélkül, hogy ehhez ki kéne adni a kezünkből az irányítást, migrálásmentesen. Demo környezetben is ki lehet próbálni a szolgáltatásaikat.

Nagyon fontos számukra a gyors és stabil hozzáférhetőség a hibrid és privát vállalati felhőt pedig SAN és NAS tárolási lehetőségekkel is támogatják.

Ha ennél nagyobb fokú személyre szabottság szükséges, és hajlandóak vagyunk megfizetni a privát infrastruktúra exkluzivitását, akkor kiváló megoldást nyújthat a Verizon.

A privát felhő mellett a Verizon az adatbázisok kezelésében való jártasságát domborítja ki az Oracle felhő integrációjával. Az ügyfél igényeihez minél jobban próbál alkalmazkodni azáltal, hogy 30 percen belüli reagálási limitet szab meg bármilyen kérdésre, kérésre, és ügyfél-dedikált Service Delivery Manager-t jelöl ki partnere számára.

Mivel ez érezhetően megkíván fogyasztóként is egy viszonylag nagyobb szerkezeti felépítést (ahová Service Delivery Manager szükséges, azok tipikusan nem a 15-20 fős kis cégek), ezért széles körben támogatja az eltérő operációs rendszereket és különböző adatbázisokat.

 

OnCloud szolgáltatók és megoldások

 

Rengeteg szolgáltató és még több megoldás közül válogathatunk, ha online boltunkat, ügyvitelünket, adatainkat a felhőbe szeretnénk mozgatni.

Alább felsorolunk 3 nagyobb céget és néhány alapszolgáltatást is összevetünk, természetesen a teljesség igénye nélkül.Egy-egy óriás hosztoló teljes portfóliójának ismertetése tanulmány szintű cikksorozattá duzzadna, ezért röviden bepillantunk a Microsoft, az Amazon és a Rackspace felhőjébe.

Windows Azure

A Windows PaaS platformja, az Azure egyben kínálja és kezeli saját operációs rendszerét, ami igen hatékony, ha az alkalmazásunk nem igényel speciális megoldásokat.

Úgy tudunk fejlesztéseinkre  koncentrálni, hogy az OS frissítése, a patch-elések, javítások miatt nem nekünk kell aggódni.

 

A Windows Azure három fő megoldást kínál e téren:

  • „Web role”:Ez a Windows Azure által szállított operációs rendszer rendelkezik előtelepített IIS 7-tel (Internet Information Services) és lehetővé teszi olyan webtechnológiák használatát, mint az NET, PHP és a Node.js.
  • Worker role: Ez az OS képes tetszőleges kódok és szinte bármilyen applikáció futtatására, beleértve az Apache Tomcat webszervert vagy a Java Virtual Machines-t is, és természetesen együttműködik a fent említett Web role-lal.
  • Virtual Machine role: Mi, az ügyfél látjuk el OS-szel az erőforrást, méghozzá egy Windows Server 2008 R2 (Enterprise vagy Standard) VHD image feltöltésével. Ellentétben a Web és Worker role-okkal, ebben az esetben mi vagyunk felelősek az operációs rendszer karbantartásáért, frissítéséért. Az Azure-ban használhatunk szinte bármilyen nyelvet, keretrendszert vagy eszközt alkalmazásaink felépítéséhez. A funkciók és szolgáltatások az úgynevezett REST (Representational State Transfer) protokollon keresztül működhetnek. A Windows Azure kliens könyvtárak több programozási nyelv támogatása érdekében is rendelkezésünkre állnak, nyílt forráskódú licenccel. Ezek GitHub-on is tárolva vannak.

A Microsoft egy három hónapos ingyenes próba környezetet biztosít az Azure-ben, amely magában foglal egy kicsi kapacitású szervert, (Small Compute Instance) és olyan egyéb erőforrásokat, melyek elegendőek az IT személyzet részére, hogy teszteljék és megismerjék a Windows Azure-t.

Mint a többi felhő szolgáltató, a Microsoft is egy pay-as-you-go árrendszert használ, az igénybe vett eszközök óraalapú költségelszámolásával.

A Microsoft’s SLA-ja (Service Level Agreement), vagyis a szolgáltatási szintről szóló megállapodás értelmében, 99.95%-os elérhetőséget garantál, amennyiben minimum két szervert igénybe veszünk, egy role-on belül.

Az SQL Azure egy szintén jól skálázható, relációs, felhő alapú adatbázis szolgáltatás, ami nevéből adódóan is SQL Server technológiára épül, amit az Azure felhő vagy a saját, irodai alkalmazásaink is használhatnak.

Adatot is exportálhatunk belőle és támogatja a folyamatos szinkronizálást a helyi adatbázisainkkal.Fizethetünk pay-as-you-go rendszerben vagy hathónapos kötelezettségvállalással kedvezmény érdekében.

Mindkét esetben, megvásárolhatjuk ezt a szolgáltatást önállóan, vagy együtt más Windows Azure platform termékekkel.

A Microsoft felhőjében lehetőség nyílik strukturált vagy strukturálatlan adatok tárolására, amikhez hozzáférhetnek az Azure alkalmazások és más applikációk REST protokollon vagy API-kon keresztül.

Az Azure Drive segítségével felcsatolhatunk (mount) tárhelyet, amit virtuális HDD-ként kezel a rendszer, amiket mozgathatunk a privát és publikus felhőnk közt. A tárhely és virtuális meghajtó szolgáltatás is pay-as-you-go alapú.

Rackspace felhő alapú hoszting

 

A Rackspace Cloud Hosting infrastruktúra átveszi az operációs rendszer feletti ellenőrzést.

Automatikus OS frissítéseket is tartalmaz a szolgáltatásuk, amennyiben a Managed Service Level-re (Menedzselt Szolgáltatási Szint) fizetünk elő.

Ellentétben az AWS-sel és a legtöbb más IaaS szolgáltatóval, a Rackspace nem engedi feltölteni a saját meglévő virtuális gépünket, tehát választanunk kell a cég által támogatott Windows vagy Linux verziókból.

A Rackspace minden szerverhasználatot óránkénti díjban határoz meg. Ellentétben néhány más felhő hosztolóval, nem teszi lehetővé, hogy az óraalapú díjazást megállítsuk a szerverek felfüggesztésével.

Ha meg szeretnénk tartani egy ún. „tétlen” (idle) szervert úgy, hogy a használat nélküli időt ne számlázzák ki az adott időszakban, biztonsági másolatot kell készíteni a szerver image-ről (amiért külön díjak merülhetnek fel a Rackspace Cloud File szolgáltatása miatt), törölnünk kell a szervert a fiókunkból. Ezt az image-t tudjuk visszatölteni, ha később újra futtatni szeretnénk.

Tartsuk szem előtt, hogy a cég jelenleg nem kínál ingyenes próba környezetet, bár szabadon létrehozhatunk egy fiókot, amivel elérhető az adminisztrációs portál, ha rá szeretnénk jobban látni, hogy hogyan is működik ez a szolgáltatás.

Fizetnünk csak szerver indítása vagy más erőforrrások bekapcsolása után vagyunk kötelesek.Bár sok szempontból megoldást nyújthat a Rackspace kínálta lehetőség – főleg ha valakit nem zavar a nagyobb szolgáltatókhoz viszonyított kisebb flexibilitás – jövőbeni terveink megalkotásánál nem mehetünk el a tény mellett, hogy a Rackspace hivatalosan is felhagy a Magento webshop Managed Hosting-jával, habár infrastruktúra szinten tovább támogatja.

Mindenestre döntésével a teljes dolgozó állományának 6%-át érintette negatívan, és nagyjából 200 Magento típusú webshop hosztingja vált kérdésessé.

Az utóbbi években erős volt a versenytársak nyomása a cégen, az érezhetően szűkülő paci részesedésük miatt kerülhetett sor egy nagyszabású akvizícióra még 2017 februárjában. (Forrás: sdxcentral)

A Managed Service Level tartalmazza a szerverek felügyeletét, az operációs rendszer és alkalmazás-infrastruktúra réteg támogatását (beleértve az automatizált frissítéseket és javításokat), és technikai útmutatót is biztosít a felhő szerverek használatához. A Rackspace SLA szerint, az adatközpontjaik rendelkezésre állási aránya 100%, kivéve a tervezett karbantartásokat, amelyek legalább tíz munkanappal korábban bejelentett leállások, és nem haladják meg a 60 percet egy naptári hónapra vetítve.

Ennek eredményeként, a garantált rendelkezésre állás tényleg csaknem száz százalékos, lényegében 99,999%-ot garantálnak ügyfeleiknek e téren.

 

Amazon Web Services (AWS)

 

Az Amazon Elastic Compute Cloud (EC2) egy IaaS platform, a legfontosabb komponens az AWS kínálatában.

Ez biztosítja a masszív infrastruktúra kiépítésének alapját, szinte bármilyen operációs rendszert támogat, amit az alkalmazásaink megkívánnak.Mint ilyen, az Amazon EC2 segítségével rendkívül hatékonyan felügyelhető az operációs rendszer, de a patch-elés felelősségét ránk bízza.

Tetszés szerint importálhatunk támogatott virtuális gép image-eket a meglévő környezetbe (Windows Server 2003 R2 és a Windows Server 2008 R1 / R2, VMware ESX VMDK, Citrix Xen VHD, vagy Microsoft Hyper-V VHD).

Természetesen a Linux disztribúciók sem maradhatnak ki a sorból, hiszen gyakori a CentOS használata is.

Az Amazon EC2 is kínál előkonfigurált szervereket, melyeken népszerű adatbázis-kiszolgálók futnak (IBM DB2, MySQL stb.), erőforrás-gazdálkodási megoldásokat, webszervereket (Apache, IIS / ASP.NET), alkalmazás fejlesztői környezetet, különböző alkalmazások futtatására optimalizált és egyéb, mint például médiaszervereket.

A Free Tier lehetőséget ad arra, hogy létrehozzunk egy „mikro” Linux vagy Windows alapú szervert, valamint bekapcsoljunk egyéb hasznos erőforrásokat, alkalmazásokat, amivel elég széles betekintést nyerhetünk az AWS kínálta lehetőségekbe.

 

Az Amazon három fizetési metódust is ajánl:

  • On-Demand: abban az esetben, amikor az erőforrás használata után fizetünk óra- vagy havidíj-alapon, hűségidő nélkül.
  • Preserved: azokban az esetekben, amikor egy egyszeri díjat kérnek el tőlünk, ezért viszonylag nagy kedvezmény is jár 1‒3 éves hűségidő fejében, illetve akkor vesszük nagy hasznát, ha jól fel tudjuk mérni előre a szükséges számításikapacitás-igényünket.
  • Spot: egy különleges helyzet, amikor az ügyfél tesz ajánlatot a felhő erőforrásra. Ehhez tisztában kell lennünk saját IT szükségletünkkel, és össze kell vetnünk a jelen informatikai kiadásainkkal. Ebben segít nekünk a Spot Bid Advisor.

 

Az Amazon SLA szerint a cég 99,95 százalékos éves rendelkezésre állást vállal, de ehhez egy EC2 instance-ot legalább két példányban kell futtatnunk, két különböző „Availability Zone”-ban. (Az AWS „Elérhetőségi Zónái”-ról írtunk előző cikkünkben.)

Az Amazon Web Services is kínál adatbázis-szolgáltatásokat: az Amazon DynamoDB egy teljes testreszabható NoSQL adatbázis felhő szolgáltatás (free tier alatt bizonyos lehetőségek nem érhetőek el benne), míg az Amazon RDB szolgáltatás felhő-alapú relációs adatbázis megoldást nyújt, hasonló képességekkel, mint a MySQL vagy az OracleDB.

Az Amazon Elastic Block Storage (EBS), mint neve is mutatja blokk-szintű tároló köteteket hoz létre, amit minden esetben egy futó EC2-höz köt.

Minden EC2 szerverhez tartozik egy bizonyos méretű tárhely, de az üzembiztonsághoz szükséges redundanciát az EBS biztosítja. Akárcsak egy merevlemezt, formázhatjuk a blokkot, és mi állíthatjuk be a kívánt fájl rendszert is!

Létrehozható Snapshot („pillanatkép”) a kötetekről biztonsági mentés céljából.

Bár ezek tárolásáért külön kell fizetnünk, ezek a mentések lényegesen kevesebb helyet igényelnek, mint az eredeti kötet, több okból is: a tömörített, üres blokkok nem tárolódnak, és a létrejött Snapshot első verziója után, csak az új, illetve a módosított adatok kerülnek rögzítésre.

 

A felhő szolgáltató kiválasztása

 

Mielőtt döntenénk arról, hogy melyik szolgáltatóval szeretnénk együttműködni, hogy a legjobb megoldást kapjuk online üzleti elképzeléseinkre, ajánlott feltenni pár kérdést, de nem csupán a szolgáltató felé.

A végeredmény nagyban függ attól, hogy:

  • milyen szolgáltatás(ok)ra van szükségünk
  • hogyan kívánjuk használni, elérni ezeket az erőforrásokat
  • milyen mértékben kívánjuk növelni felhő-kitettségünket az on-site (helyi, irodai) IT környezethez képest
  • mekkora ellenőrzésre, kontrollra van szükségünk az OS felett (használt applikációk vagy fejlesztés szempontjából)
  • a szolgáltató rendelkezik-e aktuális biztonsági akkreditációkkal
  • jogi környezetünk előírja-e a céges adatok tárolására vonatkozó földrajzi környezetet
  • tájékozódtunk a jelenlegi és cloud IT költségek különbözetéről (CTO)

 

A Windows Azure jó választás olyan alkalmazás fejlesztők számára, akiknek nem kell Linux környezet futtatni (habár az Azure 2015 óta indíthatunk Linux szervereket is).

Szinte minden programozási nyelvet támogat, versenyképes áron. Ha az alkalmazásaink lehetővé teszik, hogy a Microsoft operációs rendszereken dolgozzunk, akkor nem kell többet aggódnunk OS javítások és frissítések miatt.

A Rackspace azoknak az ügyfeleknek válhat be, akiknek szempont, hogy a szolgáltatónál maradjon az operációs rendszer feletti ellenőrzés, együtt a menedzselt szolgáltatásokkal.Az IaaS és PaaS modell együtt nyújtja a legnagyobb kényelmet az ügyfél számára. Másrészt viszont, a Rackspace-ből hiányzik néhány szolgáltatás, a másik két hoszting cégnél megvan, valamint a kényelem megkéri az árát.

A három közül ő a legdrágább megoldás.

Az Amazon EC2 az egyik legerősebb felhő szolgáltató, ha szükségünk van az operációs rendszer feletti teljes ellenőrzésre, legyen az Windows vagy Linux szerver.Az Amazon Web Services kínálja a legtöbb fajta megoldást, szolgáltatást (összesen 72 felhő szervizből válogathatunk).

Emiatt nagyon jól skálázható a rendszer, és szélesebb körben tudjuk felhasználni az erőforrásokat, legyen szó számításkapacitás igényes alkalmazásokról, tárhelyről, adatbázisról vagy webshopról.Az előre konfigurált AMI-kal (Amazon Machine Image) pedig jól tudjuk üzleti elképzeléseinkhez igazítani a virtuális gépparkot.

 

Magento fejlesztő vállalkozásként, mi az AionHill-ben az AWS nyújtotta felhőbe visszük ügyfeleink webáruházait.

Nem csupán belföldi, de több külföldi partnerrel is dolgoztunk már együtt, akiknek sikeresen optimalizáltuk a környezetet webáruháza számára.

Volt, ahol jelentős (csaknem 400 dollár / hó) költségmegtakarítást értünk el az AWS infrastruktúra átfogó testreszabásával, és van olyan esettanulmányuk, ahol drasztikusan csökkentettük az oldal betöltési idejét.

Manapság a Magento motorja található meg a webes kereskedelemmel foglalkozó top 100 000 oldal 1/3-ánál a világon.

Míg a többi eCommerce megoldás is jelentős előrelépéseket ért el, a legjobbak közt is kiemelkedően teljesít a Magento.

A benne rejlő lehetőségek nemcsak egy sikeres integrált vásárlási platformmá tették, amely szinte minden szempontból kezeli az online üzleti igényeket, hanem a hálózati szakemberek számára egy folyamatos kihívás, ha a teljesítmény optimalizálásáról van szó.

Ahogy a felhő egyre nagyobb teret hódít, és kikerülhetetlen trenddé alakult az elmúlt 10 évben az üzemeltetési megoldások terén, a potenciálisan szóba kerülő szolgáltatókat érdemes versenyképességük alapján megvizsgálni.

Birtokában vannak-e a megfelelő készségeknek vagy ismereteknek? Milyen referenciákkal, szakembereik milyen képesítéssel rendelkeznek?

 

A felhő szolgáltatótól elvárható 6 fontos kompetencia

 

Amit egyfolytában hangoztatnak a szolgáltatói oldal képviselői, hogy a felhőbe való migrálással hathatósan és tartósan csökkenthetjük az IT alkalmazottaink terhelését, faraghatunk informatikai büdzsénken és több forrás juthat az üzlet fejlesztésére.

Ezért érdemes ügyfélként az ígéretek mögé tekinteni, és tisztában lenni a mi üzleti céljainkkal, de a pontos elvárásokat is megfogalmazni leendő szolgáltatónkkal szemben.Az új környezet, új kihívásokat jelent, és új képességeket követel meg a felektől.

Az alábbiakban felsorolunk 5 olyan képességet, melyek manapság elvárhatók egy versenyképes felhő szolgáltatótól:

1) Műszaki ismeretek

Míg a kiszolgáló csapat szükséges tudás típusa és annak mértéke attól függ, hogy mekkora és mennyire összetett a felhő projektünk, addig az internetalapú tudás a webes környezetben gyorsan futó alkalmazások felépítésére irányuló képesség marad az irányadó.

Érthető, hogy teljesen más szintű tudás szükséges egy tárhely szolgáltatás menedzseléséhez, esetleg archiváláshoz, és megint más szintű szakértelmet igényel egy virtuális magánfelhő konfigurálása, dedikált adatbázisszerverekkel.

A tudásbázis erősen kell hogy építsen a szerzett tapasztalatokra, de előtérbe kerülhet a virtualizáció terén szerzett ismeret. A nyílt forráskódú eszközöket és a nyelvekkel való tapasztalatokat is jól lehet hasznosítani.

 

2) Vállalati architektúra és üzleti igények elemzése

Elengedhetetlen ahhoz, hogy egy megfelelő ütemtervet tudjunk vázolni a bevezetéshez, hogy milyen szolgáltatásokra lesz szükségünk.

Ennek birtokában gördülékenyebb az együttműködés az ügyféllel, beszélik az üzleti nyelvet, és megtalálja a hangot az informatikai szakemberekkel is.

Ha megértjük az alapelveket a szolgáltatás-orientált architektúra hosszú távon tudja segíteni vállalatunk működését.

 

3) Projekt menedzsment ismeretek

Napjainkra már nélkülözhetetlenné váltak a PM ismeretek és szerepkörök egy IT projekt véghezvitelében, amelyeket elsősorban határozott, vezető egyéniségű emberek tölthetnek be.

Egy ilyen szakembernek jól kell átlátnia mindkét oldal helyzetét, kezelnie a különböző forrásokat az egész vállalkozásra kiterjedően, egyeztetni a célokat, felügyelni, hogy a kijelölt fejlesztési pontokat, lépéseket, vagyis a „mérföldköveket” az előre meghatározott módon és időben érik el.

Nagy felelősséggel járó területe ez a felhő migrációnak, hiszen a projekt manager-ek vannak „frontvonalban”, az ügyfél és a szolgáltató között.

Nagy erőfeszítésbe kerül az, hogy az IT projektek ne a határidőt meghaladva és túllépve a kalkulált anyagi keretet fejeződjenek be, mindkét fél kárára.

Azzal is számolnia kell, hogy az ügyfél könnyen eshet a túlköltekezés hibájába, mivel a felhőben viszonylag gyorsan lehet ki- és bekapcsolni az erőforrásokat, ezért könnyen ott találhatja magát a kliens, hogy többlet költséget generál a gyakori, átgondolatlan szolgáltatásmegrendelésekkel és extra erőforrások beüzemelésével.

 

4) Áttekinthető ügyfélkommunikáció

Elvárható, hogy egy szolgáltató minden kérdésben le tudja követni az ügyfél igényeit és megfeleő válaszokat adjon a felmerülő kérdésekre.

A felek közötti kommunikációt kétoldalúan követi (tehát mindenről van dokumentáció a későbbi vitás helyzeteket elkerülendő), és azonnal reagál, amikor a dolgok nem a tervek szerint haladnak.

Például, amikor a felhő szolgáltatás váratlanul leáll, vagy szokásostól eltérően alulteljesít. Ezeknek a szituációknak a rendezéséhez, és a vitás helyzetek diplomatikus és hatékony elrendezéséhez alapszükségletté vált a megfelelő szakemberek jelenléte (project owner-ek, dedikált manager-ek).

Ide sorolható még az áttekinthető, egyértelmű árképzés, és a szolgáltatási portfólió, csomagok egyértelmű leírása. Az ügyfelekkel szemben tanúsított nyílt és pontos kommunikáció közép-hosszú távon megtérülő befektetés.

 

5) Biztonság és megfelelés

A telepített felhő típusától, annak összetettségétől függetlenül kiemelten fontos az ügyféladatok védelme, azok bizalmas kezelése.

Ehhez kapcsolódnak azok a szabványok, tanúsítványok és rendelkezések ‒ mint például a Sarbanes-Oxley, HIPAA, és a számtalan adatkezelési törvény – amelyeknek folyamatosan meg kell felelnie a szolgáltatónak, de az ügyfélre is vonatkoznak szabályok.

Az AWS felhőjében ezt különösen komolyan veszik és erre vonatkozóan egy közös felelősségi modellt dolgoztak ki. Ennek értelmében az együttműködést szigorú feltételekhez szabják és védik saját, de egyben az ügyfél érdekeit is a felelősségi területek pontos elhatárolásával (SRM – Shared Responsibility Model)

 

11 kérdés, melyeket a szolgáltatónak teszünk fel

Korábbi cikkünkben kifejtettük, hogy mire érdemes felkészülnünk ügyfélként, ha találkozunk a felhő szolgáltató cég embereivel, milyen kérdéseket szegezhetnek nekünk.

Most fordítsuk meg a helyzetet és nézzük meg azokat a fontosabb témákat, és az ebből fakadó kérdéseket, melyeket az ügyfélnek érdemes feltennie egy tárgyalás során.

 

1) Hol lesz elhelyezve az adatom?
Manapság a felhő szolgáltatók számának terjedésével, olyan árverseny alakult ki ezen a piacon, ahol a túl drága megoldásra gyanakvóan nézhetünk, de ugyanez a helyzet a túl olcsó vagy piaci ár alatti ajánlatokkal.

Senki sem szeretné, ha üzletkritikus adatai egy alapvetően békés informatikus nyakában lógnának, egy flash drive-on…

Nos, ideális esetben adataink valamilyen megosztott vagy dedikált szerveren, egy adatközpontban kerülnek elhelyezésre, ami földrajzilag távol tőlünk, egy fizikailag óvott helyen található.

Hogy országhatáron belül vagy kívül esik, azt az üzletmenet, és a jogi környezet is szabályozza.

 

2) Milyen problémák merülhetnek fel az aktuálisan futó telepítés vagy a migráció során?
Ütközésekre lehet számítani, ha az előzetes egyeztetések alkalmával nem pontosítottuk a szoftveres környezet jellemzőit.Kompatibilitási kérdések az OS-től kezdve a kapacitásigény felmérésén át a használni kívánt webtechnológiák verziószámáig (pl.: PHP, cachelés).

A migrálás – mondjuk egy webshop esetében – értelemszerűen szolgáltatáskieséssel jár, ezért kérdezzünk rá a várható mérnöki munkaórák számára, és hogy munkaidőben vagy kevésbé látogatott napszakban hajtják-e végre a migrácót.

 

3) Önök a szolgáltatás viszonteladói vagy rendelkezésükre áll az infrastruktúra?
Mindjárt a cikk elején kitértünk rá, hogy a szolgáltatásként eladott erőforrások képezhetik a szolgáltató vagy akár harmadik fél tulajdonát.

Például a korábban említett Rackspace-nek saját adatközpontjai vannak több helyen is. Azonban ha Cloudreach, vagy Datapipe – illetve az AionHill – ül az asztal másik oldalán, akkor ezek a szolgáltatók AWS partnerként az Amazon felhő infrastruktúráját értékesítik tovább, IT szakembereik pedig ezeket a cloud eszközöket kezelik, és igazítják az ügyféligényekhez.

 

4) Milyen felhő szolgáltatásokat nyújtanak?
Nézzünk utána a fontosabb szolgáltatási típusoknak, használjuk a nagy felhő cégek költségkalkulátorát.

Mielőtt tárgyalásokba bocsátkozunk, tájékozódjunk arról, hogy a szolgáltató rendelkezik-e a megfelelő kompetenciákkal, szolgáltatási portfólióval.

Ehhez persze pontosan meg kell fogalmaznunk saját üzleti jövőképünket és elvárásainkat a felhőtől.

Egyeztessünk, hogy a kínált szolgáltatások megoldást nyújtanak-e a problémánkra?

 

5) Milyen árazási konstrukciót használnak? 
Csak azért kellene fizetnünk, amit valóban el is használunk. Ez a felhő alapú szolgáltatások egyik alapelve.

Ezért érdemes vigyáznunk az irreálisan nagy induló költségekkel (upfront).

Az esetek 80%-ában meg sem jelenik ez a tétel, hiszen ahogy korábban is említettük, gyakorlatilag minden szolgáltató a pay-as-you-go sémát követi, és erről havi számlát állít ki a hoszting vállalat.

Pontosan ez az egyik árazási metódus, ami jóval az ügyfél saját szerverparkjának üzemeltetési és fenntartási költsége alá tudja nyomni a felhőben generált fogyasztást.

Az upfront tétellel, egy esetleges rögzített futamidejű kötelezettség vállalás esetén találkozhatunk. Ilyenkor meglepődhetünk nagyobb induló kötségen, de ezzel érjük el általában fajlagosan a legnagyobb kedvezményt. A cloud erőforrások havi szinten a 2-3 USD-től akár a több tízezer USD-ig is terjedhetnek. Minden azon múlik, hogy cégünknek mekkora és milyen szoláltatásra van szüksége.

 

6) Mennyire biztonságos a szolgáltatott felhő? 
Nem is az a kérdés, hogy mennyire biztonságos, hanem hogy a szolgáltató mi mindent követ el a biztonság érdekében.

Rendelkezik-e a megfelelő tanúsítványokkal, engedélyekkel, vagy harmadik félként olyan szolgáltatásokat menedzsel, amelyek rendelkeznek a szükséges előírásokkal.

Az adatkezelés mellett, megfelelő figyelmet kell fordítani a tűzfal figyelésére, vírusvédelem biztosítására, jogosultsági szintek megadására, hozzáférésvezérlésre, titkosításra.

 

7) Mi történik, ha megsérül vagy elveszik az adatom? 
Az ezzel kapcsolatos kérdéses helyzetek elkerülésére kiválóan alkalmas a pontos SLA leírás.

Ebben a vállalásban többek között erre és az ehhez hasonló esetekre is ki szoktak térni. Tudnunk kell, hogy az adatainkat mi is elérjük, vagy teljességgel megbízzuk ezzel a szolgáltató embereit.

Ha a mi munkatársaink is hozzáférnek az állományokhoz, akkor az elérések naplózását is követni kell.

Győződjünk meg arról, hogy milyen módon kívánja a szolgáltató a biztonsági mentéseket ütemezni (napi, heti rendszerességű backup-ok).

Az archiválás milyen feltételekkel és gyakorisággal megy végbe? Nem kívánt összeomlás és adatvesztés esetén milyen gyorsan állítható vissza a rendszer (disaster recovery)?

 

8) Milyen ügyféltámogatási szolgáltatások vannak? 
Milyen hibabejelentési metódusok állnak rendelkezésre? Milyen óra, nap lefedettségben érem el az ügyfélszolgálatot?

Milyen időhatárok vonatkoznak a hibák elhárítására? Van-e VIP support, és ha igen, mi számít kritikus hibának, aminek az elhárítását azonnal el kell kezdeni, és mik esnek a „next-business day” kategóriája alá?

Milyen felületeken tudunk kapcsolatba lépni a szolgáltató munkatársaival, ha hibát észleltem? Meg kell tudni határozni az átlagos válaszadási időt is.

 

9) Könyen skálázható a rendszer, hogy le tudja követni az üzleti igényeket? 
Üzletünk növekedésével előbb-utóbb ki fogjuk nőni az aktuálisan használt infrastruktúrát.

Nőni fog a bemenő-kijövő adatforgalom, nagyobb adatbázissal kell dolgoznunk, nő a tárhelyigényünk, esetleg drasztikusan növekedik a termékszámunk és ezzel egyenesen arányosan oldalunk látogatóinak az aránya is.

A flexibilitás és skálázhatóság szavakat is meglehetősen gyakran halljuk a szolgáltatóktól. Járjunk utána, hogy az erőforrásbevonásoknak vagy az azok lekapcsolásának (fel-, illetve lefelé skálázásának) milyen időbeni és / vagy anyagi vonzatai vannak.

 

 

10) Milyen a szolgáltatáskiesési arány? 
Leállásról (Downtime) vagy más néven szolgáltatáskiesésről akkor beszélünk, amikor átmenetileg nem tudjuk elérni a szolgáltató felhőjét.

Ez rendkívül nagy anyagi kárt tud okozni.

Ezért olyan cégeket érdemes keresni, akik a legnagyobb elérhetőségi arányt garantálják az év napjaihoz képest.

Természetesen a fenti kérdésre a válasz az, hogy nincs kiesés. A lényeg, hogy az elérési arány minél közelebb legyen a 100%-hoz.

A cégek jó része általában nyilvánossá teszi a kiesések naplófájljait online. Ha mégsem találunk erről nyílt információt, kérdezzünk rá!

 

11) Hogyan érem majd el a felhőt? 
Fontos tisztázni, hogy a felhő erőforrásokat milyen úton lehet igénybe venni, azokat milyen hozzáféréssel érjük el.

A statikus tartalmak feltöltését milyen protokollon keresztül oldjuk meg?

Manapság az ügyfél egy bizonyos adminisztratív szintű hozzáférést kap, amit desktop-okról és igen gyakran minden smart eszközről el lehet érni.

 

Összegzés

A menedzselt hoszting világa nagyon összetett, és első látásra igen ijesztő lehet az ügyfelek számára.

Egy webshoptulajdonos nem valószínű, hogy rendelkezik azzal a tudással, amellyel az áruházát a felhőbe helyezheti, ezért van szükség specializálódott szolgáltatókra.

Ez az ismertető cikk azért íródott, hogy az alapfogalmak tisztázódjanak, és segítséget tudjunk nyújtani neked az első lépések megtételében.

Amennyiben nemzetközi piacokat is szeretnél elérni, szükség van arra, hogy a számítástechnikára más szemszögből nézd. A folyamatosan fejlődő technológiának köszönhetően ma már sokkal költséghatékonyabb és kapacitás-optimalizáltabb megoldások léteznek, mint akár csak pár évvel ezelőtt.

Az, hogy a webáruházadat menedzselt felhő-alapú környezetbe migrálod, az egyik legjobb üzleti döntésnek bizonyulhat.