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

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

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

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

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

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

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

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

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

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

CREATE TABLE `catalog_product_entity` (
  `entity_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Entity Id',
  `attribute_set_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Attribute Set ID',
  `type_id` varchar(32) NOT NULL DEFAULT 'simple' COMMENT 'Type ID',
  `sku` varchar(64) DEFAULT NULL COMMENT 'SKU',
  `has_options` smallint(6) NOT NULL DEFAULT '0' COMMENT 'Has Options',
  `required_options` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Required Options',
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Creation Time',
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'Update Time',
  PRIMARY KEY (`entity_id`),
  KEY `CATALOG_PRODUCT_ENTITY_ATTRIBUTE_SET_ID` (`attribute_set_id`),
  KEY `CATALOG_PRODUCT_ENTITY_SKU` (`sku`)
)

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

• идентификатор набора атрибутов
• sku

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

• идентификатор на типа — ако не посочим, ще се използва ‘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 той става видим в админ панела, в грида на продуктите (Каталог / Продукти).

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

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

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-атрибути. Ето списък с основните атрибути на продукта, които са необходими за правилното показване на продукта на фронта:

• име
• price
• описание
• кратко_описание
• статус
• идентификатор на данъчния клас
• url ключ
• видимост

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

public function create($prodId, $attrCode, $attrValue)
{
    $attrId = \/* get attribute ID by attribute code *\/ 
    $attrType = \/* get attribute type [datetime|decimal|int|text|varchar] by attribute code *\/ 
    if ($attrId) {
        \/** @var MagentoFrameworkAppResourceConnection $this->resource *\/ 
        \/** @var MagentoFrameworkDBAdapterPdoMysql $conn *\/ 
        $conn = $this->resource->getConnection();
        $tblName = 'catalog_product_entity_' . $attrType;
        $table = $this->resource->getTableName($tblName);
        $bind = [
            'attribute_id' => $attrId,
            'entity_id' => $prodId,
            \/* put all attributes to default store view with id=0 (admin) *\/ 
            'store_id' => 0,
            'value' => $attrValue
        ];
        $conn->insert($table, $bind);
    }
}

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

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

Инвентарни данни

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

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

Трябва да добавяте инвентарни данни и в двете структури, тъй като новата структура все още не е напълно независима от старата (много е вероятно, че за default склада в новата структура е използвана таблица 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) и той е свързан с административния сайт. Добавянето на нови sources/stocks в 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,
        /* в 'cataloginventory' структура използваме само един склад по подразбиране */
        'stock_id' => 1,
        'qty' => $qty,
        'is_qty_decimal' => $isQtyDecimal,
        'is_in_stock' => $isInStock,
        /* по подразбиране складът е свързан с административния сайт (вижте `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,
        /* в 'cataloginventory' структура използваме само един склад по подразбиране */
        'stock_id' => 1, 
        'qty' => $qty,
        'stock_status' => MagentoCatalogInventoryApiDataStockStatusInterface::STATUS_IN_STOCK,
        /* по подразбиране складът е свързан с административния сайт (вижте `cataloginventory_stock`) */
        'website_id' => 0 
    ];
    $conn->insert($table, $bind);
}

inventory_

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

source_code|name          |enabled|description   |latitude|longitude|country_id|...|
-----------|--------------|-------|--------------|--------|---------|----------|...|
default    |Основен източник|      1|Основен източник|0.000000| 0.000000|САЩ      |...|

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

stock_id|name         |
--------|-------------|
       1|По подразбиране |

«Източник» е физическо хранилище за продукти (записите съдържат физически координати и пощенски адрес). «Склад» е логично обединение на няколко «източника» (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).

Един «склад» може да бъде свързан с няколко «източника«, а един «източник» — с няколко «склада» (отношение «много-до-много»). Изключения са дефолтните «източник» и «склад«. Те не могат да бъдат пренастроени към други същности (ограничение на ниво код — излиза грешка «Може да се запази връзка, свързана с Дефолтен Източник или Дефолтен Склад«). По-подробно за структурата на MSI в Magento 2 можете да прочетете в статията «Система за управление на склада с използване на CQRS и Event Sourcing. Проектиране«.

Ще използвам конфигурацията по подразбиране и ще добавя цялата информация за инвентара в източника default, който е ангажиран в канала за продажба, свързан с уебсайта с код base (съответства на клиентската част на магазина — вижte. 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: медийн register (изображения и видео файлове);
• 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 = /* получаване на идентификатор на атрибут по код на атрибута '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' или 'video' */
        'media_type' => 'image',
        'disabled' => false
    ];
    $conn->insert($table, $bind);
    $result = $conn->lastInsertId($table);
    return $result;
}

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

catalog_product_entity_media_gallery_value

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

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,
        /* използваме администраторска витрина по подразбиране */
        'store_id' => 0,
        'entity_id' => $prodId,
        'label' => null,
        /* имаме само едно изображение */
        '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

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

• Основен (изображение)
• Малко изображение (small_image)
• Т thumbnail (thumbnail)
• Swatch изображение (swatch_image)

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

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

Категории

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

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

Първоначално, в празно Magento приложение в регистра на категориите има 2 категории (съкратил съм имената на колоните: crt — created_at, ъпдейт — 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 (Основна категория) е кореновата категория за основния магазин на основния сайт (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