Оглавление
Возможности современного объектно-ориентированного программирования позволяют за считанные часы создавать вполне качественные MVP (minimum viable product). Для этого на этапе проектирования приложения используются разнообразные паттерны и/или включаются дополнительные библиотеки (гемы) с уже реализованным функционалом.
Отдел электронной коммерции JetRuby Agency продолжает делиться полезной информацией и интересными кейсами из собственной практики. Сегодня речь пойдет о создании, тестировании и использовании гемов. Мы раскроем эту тему на реальном примере создания гема для платформы Spree Commerce.
Создаем гем
или так:
- spree_fosdick — имя вашего гема, дано как пример;
- -T ключ пропускает генерацию Test::Unit, его можно заменить на —skip-test-unit (имеет равнозначное значение);
- —mountable создает движок с пространством имен;
- —full добавляет app и config папки в ваш гем;
- —dummy-path генерирует приложение для тестовых целей в папке, которая указана, как параметр ключа (как правило, следует использовать стандартные папки test/dummy или spec/dummy).
Готовим среду для тестирования
Создание и поддержка библиотек для разных движков — дело довольно трудоемкое. Здесь и мониторинг новых версий платформы, и подготовка совместимых релизов гема. Однако в действительности функционал (читай: бизнес-логика) не требует серьезных изменений. Достаточно подготовить минимальный набор функциональных и unit тестов. Еще заметим, что интеграционными тестами гем покрывается лишь в случае добавления новых визуальных элементов.
Итак, для тестирования нам понадобятся RSpec, FactoryGirl и Capybara (если будем проверять интеграцию). Плюс дополнительные инструменты для работы с Ffaker, Selenium-webdriver, Database cleaner и другие нужные нам гемы. В итоге в spree_fosdick.gemspec добавляется:
И еще кое-что мы добавим в Gemfile:
Ставим гемы:
Готовим Rakefile для удобства использования и поддержки гема:
Создаем spec_helper.rb и настраиваем его под текущие нужды тестирования:
Ну и напоследок конфигурируем движок lib/spree_fosdick/engine.rb:
Тестируем
Написание тестов полностью соответствует официальной документации Rspec и стайл гайдам. Стандартная работа с приложением на Ruby On Rails. Если все сделано верно, приступаем к запуску тестов. Для этого генерируем dummy_app:
И, собственно, запускаем тесты:
Если тесты “зеленые” — все в порядке. Техника тестового покрытия гемов успешно освоена. Можно начинать гордиться внесенным вкладом в развитие комьюнити Ruby on Rails в целом и Spree Commerce в частности.
Особенности интеграции с Fosdick Fulfillment
Гем создан и успешно протестирован. Переходим ко второй части статьи. Зачем он, собственно, нужен и как мы его используем? Настало время для небольшого лирического отступления.
В мире электронной коммерции одним из важнейших скрытых от пользователей элементов остается организация складского учета и взаимодействие с курьерскими службами. Современные ритейлеры уже перешли к полному разделению обязанностей в этой сфере. Существенно помогают организовать логистику и так называемые “упаковочные службы”. В их обязанности входит упаковка и передача товара в службу доставки. Причем все это происходит без участия менеджеров интернет-магазина — достаточно одного сигнала о поступившем заказе. Одной из известнейших упаковочных служб в США является Fosdick.
Почему мы выбрали именно ее? Дело в том, что Fosdick не имеет своей собственной REST API, а использует две апишки на сервисах customerstatus.com и unitycart.com.
В результате происходит разделение на два функциональных направления:
- unitycart.com — интерфейс для отправки готовых к доставке заказов;
- customerstatus.com — интерфейс для трекинга статуса доставки, мониторинга остатков и возвратов.
Процесс интеграции столкнулся с одной проблемой. Она заключается в том, что документация для двух API отсутствует в свободном доступе (нашей команде пришлось потратить не одну неделю на переговоры с руководством Fosdick Fulfillment). Кроме того, мы обнаружили явные нестыковки в синхронизации данных двух API между собой. Суть в следующем: синхронизация происходит от 24 до 48 часов после передачи информации (возможно в ручном режиме), причем уникальный регистрационный номер для каждой из API не соответствует друг другу (т.е. явной привязки нет).
Среди особенностей интеграции с Fosdick также стоит отметить наличие тайм-аутов для обращений к апишкам — две секунды между каждым запросом и ограничение на батч: до 60 айтемов за одно обращение к апишке.
Интеграция с агрегатором Fosdick была реализована согласно схеме:
Ядром архитектуры стал класс сервис “Processor”, принимающий входящие запросы от фоновых воркеров, распределяющий задачи между сервисами отправки и получающий данные от сервисов “Sender” и “Receiver”. Кроме того, именно он отвечает за организацию взаимодействия с базой данных приложения.
Описание архитектуры интеграции
Отправка
- Worker (процесс запущенный в фоновом режиме) собирает готовые к передаче агрегатору доставки заказы с частотой раз в 30 минут (интервал соответствует условиям отправки — “заказ оплачен”, “готов к отправке”) и передает их в процессор с условной командой “на отправку”.
- Processor преобразует заказы в XML формат, осуществляет последнюю валидацию и передает далее сервису “Sender”, который отправляет их POST запросом на unicart.com и распознает ответ. При наличии ошибки — она передается “Exception Logger”, который ее распознает и каталогизирует. Далее ответ возвращается в “Processor”, который, как мы помним, взаимодействует с базой данных
Синхронизация
- Воркеры, согласно расписанию, обращаются к процессору со списком отправленных агрегатору, но ещё не синхронизированных заказов.
- “Processor” делегирует запрос сервису “Receiver”, который опрашивает customerstatus.com о готовности деталей отправки по номерам заказов. В случае поступления валидных данных, они нормализуются и передаются обратно в “Processor”, обновляющий базу данных и оповещающий пользователя о том, что его посылка в пути. Статус отправленного заказа можно проследить по его трекинговому номеру. Возникшие ошибки, как и в первом случае, проходят через “Exception Logger”.
“Бизнес велью” кастомных интеграций
В последней части статьи мы расскажем о значимости кастомных интеграций. Зачем они нужны и какие проблемы позволяют решить.
Немалая часть владельцев интернет-магазинов, созданных на Spree Commerce, попали в кабалу к операционной системе Wombat. Веб-базированная ОС Wombat позволяет интегрировать магазины на Spree Commerce, Magento, Shopify, Bigcommerce, Hybris, Demandware с такими популярными сервисами как: Abacos, AfterShip, Amazon Marketplace, Amazon S3, Amazon SES, BigCommerce, Bronto, Desk.com, DotCom, Echo — Testing Integration, Exact Target, Fifth Gear, Fosdick, Highrise, Jirafe, MDS Fulfillment, MK Data Services, Magento, Mailchimp, Mandrill, NetSuite, NuORDER, Odoo, PCH International, Quickbooks Desktop, Quickbooks Online, Quiet Logistics, Salesforce, ShipStation, Shipwire, Shopify, Square, SugarCRM, Tender, Twilio, Unleashed, VTEX, Zendesk. Все это происходит всего в “два клика”.
Однако за простотой решения скрыты весьма увесистые подводные камни:
- Финансовая зависимость от предложенного тарифного плана.
- Непроработанность интеграционных модулей. Зачастую они просто не обеспечивают обратной связи;
- Нестабильность. На одном из проектов мы столкнулись с тем, что Wombat не работал в течение 13 дней, а служба поддержки даже не сообщала о случившейся оказии. В результате клиенты самостоятельно оповестили администратора магазина о недоставленном товаре.
Наша команда все чаще сталкивается с недовольными клиентами Wombat, желающими произвести интеграцию своих магазинов со сторонними сервисами.
Однако далеко не всегда клиентам нужен полный перечень возможных интеграций, а также все без исключения функции сторонних сервисов. В нашем случае ситуация немного другая. Кастомная интеграция со службой доставки — это уверенность в том, что ваши клиенты получат свой заказ, а вы сможете отследить каждый шаг своей посылки. Вплоть до ее доставки покупателю.
С точки зрения разработки и поддержки при кастомной интеграции данные в базе всегда будут консистентными. Соответственно риски неполадок системы по вине посредника между вами и целевым сервисом отсутствуют.
Команда JetRuby неустанно старается внести свой вклад в развитие open source community. В том числе речь идет о решениях на базе Spree Commerce. Что касается интегации с Fosdick, способ ее реализации можно найти в публичном доступе — на нашем аккаунте в GitHub. Безусловно, полный арсенал собственных решений и разработок мы не размещаем в открытых источниках. Не стоит забывать о понятии коммерческой тайны. Например, настраиваемые модули для интеграции с SAP B1 и С1 доступны только нашим клиентам.
Мы уверены в том, что возможности человека безграничны. Особенно, если этот человек — разработчик. В завершении хочется перефразировать классика: дайте нам точку опоры и мы обеспечим ее интеграцию с вашим интернет-магазином.
