Проблема
На сегодня существует более трехсот различных движков для интернет-магазинов, с разным функционалом, возможностями, стоимостью, способом установки. Как правило, это набор скриптов, которые разворачиваются на (практически установка сайта), чаще всего PHP + MySQL.
В последнее время все большую нишу на рынке E-сommerce платформ занимают так называемые хостед платформы (hosted shopping carts). Это значит, что, зарегистрировавшись на сайте того же Shopify, в несколько кликов вы сможете получить триальный стор (store), который на самом Shopify. Триального периода да и лимитированного функционала, как правило, вполне достаточно для проверки возможностей карты. Кроме того, такое решение конечно же снимает головную боль, связанную с арендой собственного , установкой движка и всех необходимых карте РНР-модулей и т. д. Все уже развернуто, как говорится, плати и пользуйся.
В результате разные платформы — это разные способы достучаться к данным магазина. Если у open source карты («не хостед») можно получить доступ непосредственно к базе данных, то SaaS-решения такой возможности не дают. Альтернативными вариантами могут быть доступ через API запросы (и очень хорошо, если платформа позволяет получить все необходимые данные таким способом, потому что иногда разработчики попросту не добавляют все методы работы с той или иной сущностью) или экспорт/импорт данных с помощью файлов (CSV, XML, txt, dat, xls и другие форматы в зависимости от движка).
Последний метод поддерживается практически всеми платформами (хотя у каждой возможны свои ограничения) и упрощает миграцию между одинаковыми картами. Но когда нужно переехать с магазина на базе osCommerce, который существует и функционирует уже не первый год, на свежую версию Magento или BigCommerce, задача значительно усложняется.
Для разработчика, перед которым поставлена такая цель, есть два возможных пути ее решения:
- использовать готовый инструмент для автоматической миграции;
- если предыдущий вариант не может удовлетворить все требования — искать/разрабатывать собственное решение: модуль или отдельный скрипт, который хотя бы изменит формат файла, экспортированного со старой платформы для импорта в новую (если платформы поддерживают работу с файлами).
Конечно же, можно вручную вносить данные в новую платформу через админ-панель, но когда количество продуктов и/или пользователей измеряется трехзначными числами, такой вариант перестает быть вариантом :)
Поэтому рассмотрим 2 первых кейса.
Кастомная миграция
Такой способ переноса данных может быть длиннее и стоимость его, в сравнении с автоматической миграцией, также может быть большей.
Почему?
Все просто, потому что нужно нанять программиста, который бы работал над этой задачей. Само собой за работу человека, а не машины, вам придется заплатить больше. И даже если вы сами являетесь первоклассным программистом и вполне в состоянии написать нужный скрипт — это заберет ваше время, а оно, как известно, деньги. Тем более, если вы хороший программист.
Ещё один фактор, который стоит учесть, — это время, которое понадобиться на разработку решения. И если ваш бизнес-проект достаточно ургентный, то почти наверняка у вас этого времени не хватит.
С другой стороны, увеличенные стоимость и срок разработки, которые характеризуют данный подход, могут быть оправданными одним большим преимуществом — адаптацией под конкретные цели и требования. Однако здесь могут быть свои ограничения, но о них чуть позже.
Автоматические инструменты, как правило, поддерживают какое-то лимитированное количество платформ. Что, с одной стороны, несомненно является плюсом, поскольку такие миграции отшлифованы годами использования и тысячами миграций. Но в то же время это является и минусом, поскольку позволяет охватить только определенное общее для этих платформ множество данных и интерпретировать их таким образом, как это заложено в инструменте. Например, сущность налог (tax) в различных картах может настраиваться и использоваться совершенно по-разному, состоять из абсолютно разных элементов и данных. По-этому миграция пройдет так, как это заложено в инструменте. Используя кастомный инструмент такие вещи можно свести к минимуму, потому что он будет разрабатываться под конкретный случай.
Для того, чтобы кастомное решение было максимально эффективным, следует подробнее изучить платформы, с которыми нужно работать. Исследовать сущности и определить связи между ними, чтобы правильно их проработать. Следует помнить, что если платформы разные, одна из них может поддерживать сущность, которой нет у другой. Например, в Magento есть понятие product variants, а в OpenCart его нет. Значительно реже, но все же бывают случаи, когда сущность якобы поддерживается обеими платформами, но на каждой строится по-другому и при этом может иметь совсем другое назначение.
Особое внимание следует уделить способу доступа к данным, так как именно эта часть может стать “бутылочным горлышком” будущего решения. Если шопинг карта является «не хостед», то есть устанавливается набор скриптов с базой данных, то у вас есть физический доступ к этой базе, а следовательно — можно получить все необходимые данные точно так же, как и внести их в эту в базу. Главное понимать где и какая информация находится, что означает и как формируется. Кроме того, в таких картах вы имеете доступ к файлам: изображения товаров, downloadable данных для товаров и др.
В таком случае схема миграции данных будет выглядеть таким образом:
Есть 2 магазина на разных серверах. Скрипт миграции устанавливается на одном из серверов и используется прямое подключение (direct connect) к базе данных этого сервера. Чтобы подключиться к другому стору, можно использовать direct connect, но для этого нужно открыть доступ извне.
Если же сторы на одном сервере, то дополнительных доступов не требуется. Можно использовать те же, что использует сам стор для подключения к базе данных. Обычно их можно найти в конфигурационном файле стора (например, config.php или configuration.php в корневой директории магазина).
Пример класса для коннекта к базе данных на PHP:
class Db
{
private $_link = null;
private $_triesCount = 10;
public function connect($config)
{
while (!$this->_link) {
if (!$this->_triesCount--) {
break;
}
$this->_link = mysql_connect($config['dbHost'], $config['dbUser'], $config['dbPass']);
if (!$this->_link) {
sleep(5);
}
}
if (!$this->_link) {
die(mysql_error($this->_link));
}
mysql_select_db($config['dbName'], $this->_link);
}
public function query($sql)
{
$query = mysql_query($sql, $this->_link);
if (!$query) {
die(mysql_error($this->_link));
}
return $query;
}
public function cntRows($query)
{
return mysql_num_rows($query);
}
}
Процесс миграции состоит из следующих этапов:
- Вытягивание данных с сорс стора (source store): из базы данных; через АРI; из файлов.
- Приведение данных в формат таргета (target store): в структуру таблиц или файла таргет стора.
- Вставка данных на таргет стор: в базу данных, через АРI, в файлы.
Немного по-другому все с хостед шопинг картами. Прямой доступ к базе данных отсутствует, поскольку магазин установлен на серверах разработчика, а вам предоставляется только возможность управления им с админ-панели. Чтобы достучаться до данных, некоторые разработчики хостед шопинг карт (к сожалению, не все) предоставляют определенное АРI, которое включает в себя набор методов для работы с этими данными.
Правда, в зависимости от карты, этот набор может быть довольно скупым и не удовлетворять требования поставленной задачи. Это именно те ограничения, о которых упоминалось ранее. Так, например, Shopify несмотря на довольно неплохо реализованные и документированные методы, не позволяет создавать заказы клиентов. Можно только просмотреть информацию об имеющихся или изменить статус одному из них. А Miva Merchant вообще не имеет возможности работы через АРI. Еще одной особенностью АРI есть ограничение на количество запросов за промежуток времени. Если скрипт или программа превышает этот лимит, то последующие запросы могут вообще не выполняться в течение нескольких минут.
Практически каждая шопинг карта имеет экспорт/импорт данных в виде файлов. Если информации в таких файлах достаточно для успешной миграции, то и доступ к базе данных не требуется. Довольно часто структура экспортируемых картой файлов интуитивно более понятна, чем структура базы, и более полна, чем содержание ответов АРI запросов. Отсутствие прямого подключения к базе позволяет сделать инструмент более гибким: он будет заточен под определенный формат файлов и не будет зависеть от таких вещей, как права доступа к базе данных или ограничения на количество АРI запросов. Используя файлы как носители данных между шопинг картами, можно вообще не создавать какие-то собственные скрипты или программы. Достаточно лишь отредактировать эти файлы, приведя их в требуемый формат.
Несколько схем миграций с использованием файлов:
1. Преобразование одного формата файлов в другой:
2. Миграция из файла в базу:
3. Миграция из базы в файл:
Этапы таких миграций будут почти такими же, как и в предыдущих примерах, но могут быть дополнительные шаги:
- Экспорт данных из cорс стора в файлы.
- Вытягивание данных из файлов.
- Приведение данных в формат таргета: в структуру таблиц или файла таргет стора.
- Формирование файлов для таргет стора.
- Импорт сгенерированных файлов в таргет стор.
Кстати, если вариант, где нужно открывать доступ к серверу баз данных, неприемлем, то можно получить данные из базы в виде файлов. phpMyAdmin позволяет экспортировать содержимое таблиц в виде CSV, XML и других файлов.
Что касается необходимых для кастомного инструмента ресурсов, то это будет зависеть от объема данных, которые нужно перенести, и реализации самого скрипта. Для большей надежности и меньшей ресурсоемкости данные лучше переносить порциями, например, массивами по 100 сущностей.
В общем, если рассматривать вариант PHP скрипта, который будет работать на одном из серверов, то стоит учесть следующие вещи:
- скрипт создает дополнительную нагрузку на сервер, что может повлиять на работу сайтов или сторов, находящихся на этом же сервере;
- скрипту нужен определенный объем оперативной памяти, который напрямую зависит от реализации скрипта, в частности, от размера пачки данных, которая будет перенесена за одну итерацию;
- скрипт создает дополнительную нагрузку на дисковую систему при работе с базой данных или файлами;
- длительность процесса переноса данных будет зависеть от объема этих данных и может длиться от нескольких минут до нескольких часов, иногда даже дней.
Что касается языка программирования, который будет использован для создания кастомного решения, то жестких ограничений нет. Главное, чтобы он позволял реализовать нужный функционал, такой, как подключение к базе данных (не обязательно MySQL), выполнения HTTP-запросов, работа с файлами и изображениями. Поскольку значительная часть платформ написаны на PHP, то именно ее чаще всего и используют. Хотя та же Java также подойдет для решения поставленной задачи.
Кстати, есть компании, которые создают такие кастомные инструменты или скрипты. В частности TransPacific Software Pvt. Ltd. предлагает подготовить решение для миграций osCommerce to Magento, X-Cart to OpenCart, Zen Cart to OpenCart or Magento, Loaded Commerce (CRE Loaded) to Magento за период до 25 рабочих дней.
Автоматическая миграция
Среди готовых решений для переноса данных между шопинг картами можно выделить 2 группы: сервисы и приложения к картам. Последние созданы не для всех карт и более узконаправленными. Как правило, поддерживают только ту карту, для которой предназначены. Подобные приложения являются относительно недорогими (если не бесплатными), устанавливаясь на одной из шопинг карт, используют ресурсы , на котором работает карта.
Такое средство переноса данных можно было бы отнести к ручным инструментам, что было бы справедливо, учитывая их суть. Но также учитывая, что это все же готовые решения, то, по-моему мнению, место им в этой категории.
Автоматические сервисы, в свою очередь, охватывают большее множество шопинг карт. Перечень поддерживаемых опций включает наибольшее количество совместных сущностей для различных карт. Хотя если сущность будет уникальной для определенной карты, то не исключено, что при переносе данных между одинаковыми платформами она также будет мигрировать.
Конечно, перенести данные, сгенерированные кастомным модулем карты (например, специфические отчеты), не удастся. По крайней мере стандартный функционал сервиса не включает такого. Если вы все же решили использовать сервис и кастомные данные вам нужны, то всегда можно поинтересоваться у службы поддержки, возможно ли сделать дополнительную работу. Конечно это будет + к цене. Кстати о цене автоматической миграции: она обычно ниже, чем в случае с кастомной миграцией, поскольку требует минимум вмешательства человека в процесс.
Некоторые сервисы предлагают дополнительные опции для миграции, например, миграция SEO — данных, сохранения ID товаров, заказов и т.д. Стоимость этих опций добавляется к стоимости всей миграции.
В качестве примера рассмотрим сервис Cart2Cart, который поддерживает около 50 шопинг карт. Он позволяет перенести такие данные, как товары и их категории, производителей, списки клиентов и их заказы, налоги, а также имеет ряд дополнительных опций для каждого конкретного направления миграции.
Схема миграции выглядит следующим образом:
Для подключения к базе данных сайта сервис использует специальный Connection Bridge, предустановленный в корневую директорию стора.
Все миграции выполняются на Амазоновских серверах Elastic Cloud (EC2), что обеспечивает высокую скорость процесса и позволяет справиться с большими объемами данных. Таким образом все процессы происходят на выделенных серверах.
Для некоторых шопинг карт поддерживается миграция из файлов:
Связи между сущностями
В каждой шопинг карте можно выделить 3 основные сущности: товары (products), клиенты (customers), заказ (orders). Все другие так или иначе связаны с основными. При миграции сущностей важно учесть связи между ними, чтобы корректно восстановить эти данные на таргет сторе.
Ниже изображены схемы связей основных сущностей с другими. В зависимости от шопинг карты их перечень может меняться.
Сущность товар может включать такие сущности или быть связанной с ними:
- категории (categories);
- изображения (images);
- отзывы (reviews);
- опции (options), которые, в свою очередь, включают значения опций (option items).
Сущность пользователь связана с адресами и может содержать несколько адресов.
Сущность заказ связана со следующими сущностями:
- пользователь (customer);
- адрес оплаты (billing address);
- адрес доставки (shipping address);
- продукты (products);
- итог (total);
- история заказов (history).
Кстати, в заказе, как правило, дублируется информация о пользователях и продуктах. То есть, помимо сохранения ID клиента, который сделал заказ и ID заказанных продуктов, в базе данных в отдельных таблицах дублируется основная информация об этих сущностях. Это позволяет сохранить полную информацию о заказе, даже если аккаунт пользователя или продукты из каталога были полностью удалены.
Итог
Процесс миграции данных между E-commerce платформами может быть сложным или простым, долгим или быстрым. Все будет зависеть от выбранного пути, инструментов и ресурсов. Учитывая стремительное развитие отрасли (по прогнозам аналитиков треть оффлайн магазинов закроются до 2017 года), автоматические инструменты активно совершенствуются, предоставляя все большее множество услуг, поэтому написание кастомных скриптов для переноса данных отходит на второй план.
Автор: victor2832
