В предишната статия описах процеса на импортиране на продукти в Magento 2 по обичайния начин — чрез модели и репозитории. Обичайният подход предлага доста ниска скорост на обработка на данни. На лаптопа ми излизаше около един продукт в секунда. В това продължение разглеждам алтернативен начин за импортиране на продукт — директно записване в базата, заобикаляйки стандартните механизми на Magento 2 (модели, фабрики, репозитории). Последователността на стъпките, осигуряващи импортиране на продукти, може да бъде адаптирана към всеки програмен език, способен да работи с MySQL.

Отказ от отговорност: В Magento има готова функционалност за импортиране на данни и, вероятно, ще ви е достатъчно. Но ако нуждаете от по-пълен контрол на процеса на импортиране, който не се ограничава до подготовка на CSV файл за това, което е — добре дошли под кат.

Кодът, получен след написването на двете статии, може да бъде видян в Magento модула „flancer32/mage2_ext_demo_import“. Ето някои ограничения, които спазвах, за да опростя кода на демонстрационния модул:

• Продуктите само се създават, не се актуализират.
• Едно хранилище
• Импортират се само имената на категориите, без тяхната структура
• Структурите на данните съответстват на версия 2.3

JSON за импортиране на отделен продукт:

{
  "sku": "MVA20D-UBV-3",
  "name": "Запушалка за пломбиране VA47-29 IEK",
  "desc": "Осигуряване на достъп до устройствата ...",
  "desc_short": "Запушалката за пломбиране VA47-29 IEK е предназначена за ...",
  "price": 5.00,
  "qty": 25,
  "categories": ["Категория 1", "Категория 2"],
  "image_path": "mva20d_ubv_3.png"
}

Преглед на основните етапи на импортиране

• регистрация на самия продукт
• връзка между продукта и уебсайта
• основни атрибути на продукта (EAV)
• инвентарни данни (количество продукт на склад)
• медии (снимки)
• връзка с категориите в каталога

Регистрация на продукта

Основната информация за продукта се намира в catalog_product_entity:

СЪЗДАЙТЕ ТАБЛИЦА `catalog_product_entity` (
  `entity_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Идентификатор на единицата',
  `attribute_set_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Идентификатор на набора атрибути',
  `type_id` varchar(32) NOT NULL DEFAULT 'simple' COMMENT 'Идентификатор на типа',
  `sku` varchar(64) DEFAULT NULL COMMENT 'SKU',
  `has_options` smallint(6) NOT NULL DEFAULT '0' COMMENT 'Има опции',
  `required_options` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Задължителни опции',
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Време на създаване',
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'Време на актуализиране',
  PRIMARY KEY (`entity_id`),
  KEY `CATALOG_PRODUCT_ENTITY_ATTRIBUTE_SET_ID` (`attribute_set_id`),
  KEY `CATALOG_PRODUCT_ENTITY_SKU` (`sku`)
)

Минимална необходима информация за създаване на запис в регистъра на продуктите:

• attribute_set_id
• sku

допълнително:

• type_id — ако не посочим, ще бъде използвано ‘simple’

За директно записване в базата използвам DB адаптера на самата Magento:

function create($sku, $typeId, $attrSetId)
{
    \/** @var MagentoFrameworkAppResourceConnection $this->resource *\/ 
    \/** @var MagentoFrameworkDBAdapterPdoMysql $conn *\/ 
    $conn = $this->resource->getConnection();
    $table = $this->resource->getTableName('catalog_product_entity');
    $bind = [
        'sku' => $sku,
        'type_id' => $typeId,
        'attribute_set_id' => $attrSetId
    ];
    $conn->insert($table, $bind);
    $result = $conn->lastInsertId($table);
    return $result;
}

След регистрацията на продукта в catalog_product_entity той става видим в админ панела, в решетката с продукти (Catalog / Products).

Връзка на продукта с уебсайта

Връзката на продукта с сайта определя в кои магазини и на какви витрини продуктът ще бъде достъпен на предната част.

function linkToWebsite($prodId, $websiteId)
{
    \/** @var MagentoFrameworkAppResourceConnection $this->resource *\/ 
    \/** @var MagentoFrameworkDBAdapterPdoMysql $conn *\/ 
    $conn = $this->resource->getConnection();
    $table = $this->resource->getTableName('catalog_product_website');
    $bind = [
        'product_id' => $prodId,
        'website_id' => $websiteId
    ];
    $conn->insert($table, $bind);
}

Основни атрибути на продукта

При новорегистриран продукт все още няма нито име, нито описание. Всичко това става чрез EAV атрибути. Ето списък на основните атрибути на продукта, които са необходими, за да се показва продуктът достатъчно коректно на предната част:

• name
• price
• description
• short_description
• status
• tax_class_id
• url_key
• visibility

Отделен атрибут към продукта се добавя по следния начин (опуснати са детайлите за получаване на идентификатора и типа атрибут по неговия код):

публична функция create($prodId, $attrCode, $attrValue)
{
    $attrId = /* определете ID на атрибута по кода на атрибута *
    $attrType = /* определете типа на атрибута [datetime|decimal|int|text|varchar] по кода на атрибута *02
    ако ($attrId) {
        /** @var MagentoFrameworkAppResourceConnection $this->resource *02
        /** @var MagentoFrameworkDBAdapterPdoMysql $conn *02
        $conn = $this->resource->getConnection();
        $tblName = 'catalog_product_entity_' . $attrType;
        $table = $this->resource->getTableName($tblName);
        $bind = [
            'attribute_id' => $attrId,
            'entity_id' => $prodId,
            02/* поставете всички атрибути в основния магазин с id=0 (админ) *02
            'store_id' => 0,
            'value' => $attrValue
        ];
        $conn->insert($table, $bind);
    }
}

Чрез кода на атрибута определяме неговия id и тип данни (datetime, decimal, int, text, varchar), след което в съответната таблица записваме данни за административния магазин (store_id = 0).

След добавянето на гореспоменатите атрибути към продукта, се получава следната картина в админския панел:

Данни за инвентара

С версии 2.3 в Magento паралелно съществуват два набора таблици, осигуряващи съхранение на инвентарна информация (количеството на продукта):

• cataloginventory_*: стара структура;
• inventory_*: нова структура (MSI — Мулти Източник Инвентар);

Данните за инвентара трябва да бъдат добавяни и в двете структури, тъй като новата структура все още не е напълно независима от старата (много е вероятно, че за по подразбиране склада в новата структура се използва таблицата cataloginventory_stock_status в качеството на inventory_stock_1).

cataloginventory_

При разгръщането на Magneto 2.3, първоначално имаме 2 записа в store_website, което съответства на два сайта — административен и основен клиентски:

website_id|code |name        |sort_order|default_group_id|is_default|
----------|-----|------------|----------|----------------|----------|
         0|admin|Админ       |         0|               0|         0|
         1|base |Основен сайт|         0|               1|         1|

В таблицата cataloginventory_stock имаме само един запис:

stock_id|website_id|stock_name|
--------|----------|----------|
       1|         0|По подразбиране   |

Т.е., в старата структура имаме само един „склад“ (stock) и той е свързан с административния сайт. Добавянето на нови източници/склади в MSI (новата структура) не води до появата на нови записи в cataloginventory_stock.

Данните за инвентар на продуктите в старата структура първоначално се записват в таблиците:

• cataloginventory_stock_item
• cataloginventory_stock_status

cataloginventory_stock_item

function createOldItem($prodId, $qty)
{
    $isQtyDecimal = (((int)$qty) != $qty);
    $isInStock = ($qty > 0);
    /** @var MagentoFrameworkAppResourceConnection $this->resource */
    /** @var MagentoFrameworkDBAdapterPdoMysql $conn */
    $conn = $this->resource->getConnection();
    $table = $this->resource->getTableName('cataloginventory_stock_item');
    $bind = [
        'product_id' => $prodId,
        /* we use one only stock in 'cataloginventory' structure by default */
        'stock_id' => 1,
        'qty' => $qty,
        'is_qty_decimal' => $isQtyDecimal,
        'is_in_stock' => $isInStock,
        /* default stock is bound to admin website (see `cataloginventory_stock`) */
        'website_id' => 0
    ];
    $conn->insert($table, $bind);
}

cataloginventory_stock_status

function createOldStatus($prodId, $qty)
{
    $isInStock = ($qty > 0);
    /** @var MagentoFrameworkAppResourceConnection $this->resource */
    /** @var MagentoFrameworkDBAdapterPdoMysql $conn */
    $conn = $this->resource->getConnection();
    $table = $this->resource->getTableName('cataloginventory_stock_status');
    $bind = [
        'product_id' => $prodId,
        /* we use one only stock in 'cataloginventory' structure by default */
        'stock_id' => 1, 
        'qty' => $qty,
        'stock_status' => MagentoCatalogInventoryApiDataStockStatusInterface::STATUS_IN_STOCK,
        /* default stock is bound to admin website (see `cataloginventory_stock`) */
        'website_id' => 0 
    ];
    $conn->insert($table, $bind);
}

инвентаризация_

Първоначално новата структура за съхранение на инвентарни данни съдържа 1 „източник» (inventory_source):

source_code|name          |enabled|description   |latitude|longitude|country_id|...|
-----------|--------------|-------|--------------|--------|---------|----------|...|
default    |Default Source|      1|Default Source|0.000000| 0.000000|US        |...|

и един „склад» (inventory_stock):

stock_id|name         |
--------|-------------|
       1|Default Stock|

«Източник» представлява физическо хранилище за продукти (записът съдържа физически координати и пощенски адрес). „Склад» представлява логично обединение на няколко „източника“ (inventory_source_stock_link)

link_id|stock_id|source_code|priority|
-------|--------|-----------|--------|
      1|       1|default    |       1|

на ниво, при което се осъществява свързване с канала на продажба (inventory_stock_sales_channel)

type   |code|stock_id|
-------|----|--------|
website|base|       1|

Съдейки по структурата на данните, се предвиждат различни типове канали за продажба, но по подразбиране се използва само връзка „stock«-«website» (връзката с уебсайт се осъществява чрез кода на уебсайта — base).

Един „склад» може да бъде свързан с много „източници«, а един „източник» — с много „склади» (отношение „много към много“). Изключения правят default източниците „източник» и „склад«. Те не могат да бъдат пренастроени към други същности (ограничение на ниво код — възниква грешка „Can not save link related to Default Source or Default Stock“). По-подробно за структурата на MSI в Magento 2 можете да прочетете в статията „Система за управление на склад с използване на CQRS и Event Sourcing. Проектиране«.

Ще използвам конфигурацията по подразбиране и ще добавя цялата инвентарна информация в източника по подразбиране, който е активиран в канала на продажбите, свързан с уебсайта с код base (съответства на клиентската част на магазина — вижте store_website):

function createNewItem($sku, $qty)
{
    \/** @var MagentoFrameworkAppResourceConnection $this->resource *\/ 
    \/** @var MagentoFrameworkDBAdapterPdoMysql $conn *\/ 
    $conn = $this->resource->getConnection();
    $table = $this->resource->getTableName('inventory_source_item');
    $bind = [
        'source_code' => 'default',
        'sku' => $sku,
        'quantity' => $qty,
        'status' => MagentoInventoryApiApiDataSourceItemInterface::STATUS_IN_STOCK
    ];
    $conn->insert($table, $bind);
}

След добавянето на инвентарни данни към продукта в админ панела, получаваме следната картина:

Медия

При "ръчно" добавяне на изображения към продукта през админ панела, съответната информация се записва в следните таблици:

• catalog_product_entity_media_gallery: медийният регистър (изображения и видео файлове);
• catalog_product_entity_media_gallery_value: свързване на медии с продукти и витрини (локализация);
• catalog_product_entity_media_gallery_value_to_entity: свързване на медии само с продукти (предполагаемо, медийната съдържание по подразбиране за продукта);
• catalog_product_entity_varchar: тук се запазват ролите, в които се използва изображението;

а самите изображения се запазват в директория ./pub/media/catalog/product/x/y/, където x и y — първите две букви от името на файла с изображението. Например, файл image.png трябва да бъде запазен като ./pub/media/catalog/product/i/m/image.png, за да може платформата да го използва като изображение при описанието на продуктите от каталога.

catalog_product_entity_media_gallery

Регистрираме разположения медиа файл в ./pub/media/catalog/product/ медия файл (самият процес на разполагане на файла в тази статия не е разгледан):

function createMediaGallery($imgPathPrefixed)
{
    $attrId = \/** get attribute ID by attribute code 'media_gallery' *\/ 
    \/** @var MagentoFrameworkAppResourceConnection $this->resource *\/ 
    \/** @var MagentoFrameworkDBAdapterPdoMysql $conn *\/ 
    $conn = $this->resource->getConnection();
    $table = $this->resource->getTableName('catalog_product_entity_media_gallery');
    $bind = [
        'attribute_id' => $attrId,
        'value' => $imgPathPrefixed,
        \/* 'image' or 'video' *\/ 
        'media_type' => 'image',
        'disabled' => false
    ];
    $conn->insert($table, $bind);
    $result = $conn->lastInsertId($table);
    return $result;
}

При регистрация на нов медиа файл, му се присвоява идентификатор.

catalog_product_entity_media_gallery_value

Свързваме регистрирания медиа файл с отговарящия продукт за витрина по подразбиране:

function createGalleryValue($mediaId, $prodId)
{
    \/** @var MagentoFrameworkAppResourceConnection $this->resource *\/ 
    \/** @var MagentoFrameworkDBAdapterPdoMysql $conn *\/ 
    $conn = $this->resource->getConnection();
    $table = $this->resource->getTableName('catalog_product_entity_media_gallery_value');
    $bind = [
        'value_id' => $mediaId,
        \/* use admin store view by default *\/ 
        'store_id' => 0,
        'entity_id' => $prodId,
        'label' => null,
        \/* we have one only image *\/ 
        'position' => 1,
        'disabled' => false
    ];
    $conn->insert($table, $bind);
}

catalog_product_entity_media_gallery_value_to_entity

Свързваме регистрирания медиен файл с съответния продукт без привръзка към конкретен магазин. Не е ясно къде точно се използват тези данни и защо не може да се обръща към данните от предишната таблица, но тази таблица съществува и данни в нея се записват при добавяне на снимка към продукта. Затова е така.

function createGalleryValueToEntity($mediaId, $prodId)
{
    \/** @var MagentoFrameworkAppResourceConnection $this->resource *\/ 
    \/** @var MagentoFrameworkDBAdapterPdoMysql $conn *\/ 
    $conn = $this->resource->getConnection();
    $table = $this->resource->getTableName('catalog_product_entity_media_gallery_value_to_entity');
    $bind = [
        'value_id' => $mediaId,
        'entity_id' => $prodId
    ];
    $conn->insert($table, $bind);
}

catalog_product_entity_varchar

Медийните файлове могат да се използват с различни роли (кодът на съответния атрибут е в скобите):

• Base (image)
• Small Image (small_image)
• Thumbnail (thumbnail)
• Swatch Image (swatch_image)

Привързването на ролите към медиения файл става точно в catalog_product_entity_varchar. Кодът за свързване е аналогичен на кода в раздел "Основни атрибути на продукта«.

След добавяне на изображение към продукта в админката изглежда ето така:

Категории

Основните таблици, в които се съдържат данните за категориите:

• catalog_category_entity: регистър на категориите;
• catalog_category_product: връзка между продукти и категории;
• catalog_category_entity_*: стойности на EAV-атрибути;

В началото, в празно Magento приложение, в регистъра на категориите има 2 категории (съкратил съм имената на колоните: crt — created_at, upd — updated_at):

entity_id|attribute_set_id|parent_id|crt|upd|path|position|level|children_count|
---------|----------------|---------|---|---|----|--------|-----|--------------|
        1|               3|        0|...|...|1   |       0|    0|             1|
        2|               3|        1|...|...|1\/2 |       1|    1|             0|

Категорията с id=1 е коренът на целия Magento каталог и не е достъпна нито в админката, нито на фронта. Категорията с id=2 (Default Category) е коренова категория за основния магазин на основния сайт (Main Website Store), създаван при разгръщане на приложението (вж. Admin / Stores / All Stores). Самата коренова категория на магазина също не е достъпна на фронта, само нейните подкатегории.

Тъй като темата на тази статия все пак е внос на данни за продукти, няма да използвам пряко записване в базата при създаването на категории, а ще се възползвам от класовете, предоставяни от самата Magento (модели и репозитории). Прякото записване в базата се използва само за свързване на вносимия продукт с категорията (съотнесението на категорията става по нейното име, при съотнесение се извлича id на категорията):

function create($prodId, $catId)
{
    \/** @var MagentoFrameworkAppResourceConnection $this->resource *\/ 
    \/** @var MagentoFrameworkDBAdapterPdoMysql $conn *\/ 
    $conn = $this->resource->getConnection();
    $table = $this->resource->getTableName('catalog_category_product');
    $bind = [
        'category_id' => $catId,
        'product_id' => $prodId,
    ];
    $conn->insert($table, $bind);
}

След добавянето на връзката на продукта с категориите «Категория 1» и «Категория 2» детайлите на продукта в админ панела изглеждат приблизително така:

Допълнителни действия

След завършване на импорта на данни е необходимо да се изпълнят следните допълнителни действия:

• индексиране на данни: повикване в конзолата .\/bin\/magento indexer:reindex;
• регенериране на URL адреси за продукти\/категории: може да се използва разширение «elgentos\/regenerate-catalog-urls«

Продуктите в админ панела след изпълнение на допълнителните действия:

и на фронта:

Резюме

Същият набор от продукти (10 броя), който и в предишната статия, се внася поне с порядък по-бързо (1 секунда срещу 10). За по-точна оценка на скоростта е необходимо по-голямо количество продукти — няколко стотин, а по-добре хиляди. Все пак, дори при такъв малък размер на входните данни, може да се направи извод, че използването на инструментариума, предоставян от Magento (модели и репозитории), значително (подчертавам — значително!) ускорява разработката на необходимия функционал, но в същото време значително (подчертавам — значително!) намалява скоростта на попадане на данни в базата.

В крайна сметка водата се оказа мокра и това не е никакво откритие. Въпреки това, сега имам код, с който да експериментирам и, възможно, да направя по-интересни изводи.

Източник: habr.com