Нецелевое использование платформы Pokupo
С момента публикации документации по api для платформы pokupo, мне не дает покоя мысль о том, чтобы перенести действующий интернет магазин одного из моих клиентов на рельсы этой системы.
Дело в том, что данный магазин создавался давно, когда ассортимент товаров был крайне ограничен и не требовалось какой-то серьезной системы управления. Я вносил данные через простенький веб-интерфейс, а потом просто синхронизировал базу данных.
Эта система долго и успешно работала, но в последнее время магазин начал набирать обороты, появились новые менеджеры по продажам, количество товаров начало расти, стали постоянно меняться описания этих товаров, а поскольку помимо этого, я занимаюсь и другими проектами, я стал элементарно не успевать, да и не айтишное это дело - строчить описания товаров, пусть этим занимаются менеджеры.
Но почему Pokupo? А почему бы и нет. По-умолчанию данная платформа обеспечивает практически весь функционал, который предлагают различные коммерческие системы. Один из моих знакомых перенес свой магазин на одну из таких систем и платит порядка 11 тыс. в год за лицензию, при этом данная cms еще и потребовала доработки напильником.
В pokupo уже реализован обмен с 1С, выгрузка товаров в YML(для Яндекс.Маркет) и все это бесплатно.
Переход на какой-нибудь opencart также меня не интересует. Я много работал с этой системой и она мне не нравится.
Еще один важный плюс Покупо - гибкость. Используя api я могу безболезненно перенести лишь часть магазина, а в случае каких-либо проблем вернуть все на место, что не так просто сделать меняя CMS целиком.
А как на счет безопасности, сохранности данных, масштабируемости? Эти вопросы пока открыты, но думаю разработчики в ближайшее время откроют нам свои секреты.
В общем, взвесив все плюсы и минусы, я решил попробовать.
Прежде всего я создал дополнительный магазин. Pokupo позволяет в одной учетке создавать неограниченное количество магазинов, но хотелось бы дополнительно иметь возможность создавать дополнительные учетки для управления магазином или делегировать управление другому аккаунту.
Далее я добавил категории, внес в базу несколько товаров, создал дополнительный класс товаров с нужными мне параметрами. Это необходимо было сделать потому, что клиент никак не определится с форматами цен. Они бывают в рублях и в валютах, содержат информацию о фасовке и размеры минимальных партий. В общем нужны простые текстовые строки, которых по-умолчанию в Pokupo нет.
И вот тут возникла небольшая загвоздка из за которой мне пришлось обратиться в техподдержку. В документации по api, я не нашел параметр запроса, который бы выдавал перечень дополнительных полей свежесозданного класса. Оказалось, что параметр был у меня перед носом, просто в терминологии путаница. В админке это называется классы товаров/параметры, а в документации "Вернуть информацию о типе товара".
В итоге техподдержка указала мне требуемый запрос:
https://seller.pokupo.ru/api/goods/8847/search/?category_info=yes&type_goods_info=yes&idCategories=179585
Однако он работает совсем не так как требуется. Чтобы получить верные данные, необходимо выполнить предыдущий запрос, но лишь с цель получения списка id товаров в указанной категории, а затем, в цикле, произвести другой вызов api
https://seller.pokupo.ru/api/goods/".id товара."/info/?type_goods_info=yes
Следующим шагом, стало формирование страницы с подробным описанием товара. Дело в том, что ссылки на оригинальном сайте используют определенные артикулы, мне необходимо их сохранить, но в покупо происходит обращения к товарам по артикулам этой системы, поэтому для получения товаров с артикулом заданным в поле num_goods, требуется произвести поиск товаров соответствующим запросом к api
https://seller.pokupo.ru/api/goods/8847/search/?num_goods=".$art."&typeSearch=all (в документации про num_goods не написано, но это работает).
Тут возникает еще одна загвоздка, результат поиска - множество товаров со схожими артикулами. Поэтому пришлось произвести дополнительную проверку.
Артикул берется из переменной $_SERVER["REQUEST_URI"], с помощью preg_replace вычленяется нужная строка. Полученный артикул сравнивается с параметрами num_goods из выборки, ну а дальше дело техники.
Таким образом один из разделов каталога интернет-магазина моего клиента переведен на работу с Pokupo. Пока это дело работает в режиме эксперимента, ну а дальше посмотрим.
Конечно не обошлось и без минусов. Во-первых загрузка каталога товаров через api Pokupo происходит медленней, чем через локальную базу (но это и ежу понятно). Во-вторых из-за того, что запрос /goods/search к api отображает неправильный набор параметров из дополнительных классов, приходится производить еще один лишний вызов, что также не добавляет скорости работы. Ну и в третьих, при добавлении товаров в каталог возникли некоторые нюансы, потребовавшие помощи разработчиков.
Но в целом, полет нормальный.
Предполагаю растянуть срок эксперимента примерно на месяц и, если не возникнет каких-нибудь непредвиденных трудностей, полностью переведу магазин моего клиента на платформу Pokupo.