Sap commerce что это

SAP Commerce

Закажите бесплатную консультацию

Интегрируйте каналы взаимодействия с клиентом в единую систему, персонализируйте коммерческие предложения и повысьте продажи

С КАКИМИ ПРОБЛЕМАМИ СТАЛКИВАЮТСЯ КОМПАНИИ?

Компании часто используют несколько систем для взаимодействия клиентами. Данные из приложений слабо интегрированы, и возникают потери информации и ошибки.

Сотрудники отделов маркетинга и продаж не владеют полной информацией о клиентах на каждом этапе покупки и не могут сформировать правильный предложения.

Организациям сложно упорядочить управление заказами, контентом в каталогам товаров и быстро внедрять новые продукты.

ЧТО ТАКОЕ SAP COMMERCE?

SAP Commerce (бывш. SAP Hybris) ─ платформа для B2B, B2C, которая централизует управление электронной коммерцией, взаимодействие с клиентами онлайн и офлайн: сайты, коллцентры, мобильные приложения, социальные сети и печатные м атериалы.

Решение помогает экономить время и ресурсы, оптимизирует работу отделов маркетинга и продаж, помогает персонализировать взаимодействие с покупателями, визуализировать результаты и определить эффективность маркетинговых каналов.

КАКИЕ ВЫГОДЫ ПОЛУЧАЕТ КОМПАНИЯ?

КАКИЕ ФУНКЦИИ ДОСТУПНЫ ПОЛЬЗОВАТЕЛЯМ?

Многоканальные продажи

Решение интегрирует каналы продаж и повышает качество взаимодействия с потребителями.

В SAP Commerce встроен удобный поиск, интерфейс платформы адаптируется к любым устройствам.

Решение автоматически интегрирует и настраивает сервисы для оплаты и расчет налогов при оформлении заказов.

Персонализация предложений

SAP Commerce упрощает сегментацию пользователей, ремаркетинг и расположение товаров на сайте.

В режиме реального времени компании получают ценную информацию о поведении и действиях пользователей, снижают количество отказов при оформлении заказа. Решение помогает располагать товары на сайте в порядке, который повысит конверсии.

Информация о продукте

Решение помогает настроить показы товаров для разных групп пользователей с наиболее интересными для них деталями в описании.

SAP Commerce анализирует каталоги, повышает качество информации о товарах с помощью встроенных функций валидации, упрощает добавление товаров на сайт благодаря возможности массовой загрузки и редактирования.

Заказы

Решение дает клиентам возможность совершать покупки по всем каналам в любое время, упрощает возврат товара, гарантирует прозрачность запасов: покупатели знают, есть ли товар в наличии и сколько осталось на складе.

Поддерживает модели B2B и B2C.

Настройка платформы

SAP Commerce помогает настроить платформу под собственные требования и увеличивать конверсии.

Решение упрощает редактирование сайта, помогает согласованно управлять несколько онлайн-магазинами, улучшает эффективность службы сопровождения за счет интегрированной базы знаний.

ПРЕИМУЩЕСТВА SAP COMMERCE

КАКИЕ СЕРВИСЫ ПРЕДЛАГАЕМ ПРЕДПРИЯТИЯМ?

Разработка и внедрение

Внедряем решение SAP Commerce, другие решения SAP C/4HANA, проектируем, создаем, внедряем и поддерживаем системы управления бизнес-процессами на базе:

Локализация и тиражирование

Дорабатываем модули и исправляем решения, которые были установлены на предприятии ранее, адаптируем решения к требованиям бизнеса и законодательства страны заказчика.

Модернизация и обновления

Переносим корпоративные приложения заказчика на более новые версии, мигрируем корпоративные приложения с R/3 на SAP ERP и с SAP ERP на S/4HANA. Проводим техническую оценку систем заказчика, оцениваем бюджеты и сроки с учетом анализа рисков и предлагаем варианты миграции на SAP S/4HANA.

Поддержка и развитие

Поддерживаем и развиваем SAP Commerce и другие внедренные решения SAP.

Консультируем и предоставляем права доступа к информационным ресурсам SAP. Поддерживаем запуск систем и обновлений версий SAP. Контролируем качество использования лицензий SAP.

Источник

SAP Commerce — новое слово в электронной коммерции

Создавайте масштабные онлайн-магазины, мгновенно реагирующие на изменения потребностей и поведения покупателей

Платформа для электронной коммерции SAP гарантирует уникальный клиентский опыт (customer experience)

SAP Commerce (ранее: SAP Hybris Commerce) — платформа для электронной коммерции, упрощающая создание e-commerce-проектов и адаптивных веб-сайтов интернет-магазинов.

Как привлечь максимум клиентов по всему миру и предоставить им качественный сервис и удобное взаимодействие? Использовать гибкое решение и его функциональные возможности, чтобы на его базе создать площадку для онлайн-продаж.

Благодаря SAP Commerce представители рынка электронной коммерции укрепляют лояльность клиентов и добиваются новых успехов в бизнесе.

Существует две версии решения — облачная ( SAP Commerce Cloud ) и локальная ( on-premise ).

SAP Commerce — отличный способ вывести электронную коммерцию на новый уровень

Причины, по которым стоит выбрать SAP Commerce для вашего бизнеса:

Многообразие способов для вывода новых продуктов на рынок

Поддержка B2C-, B2B2C- и B2B-моделей

Ориентация на определенную отрасль бизнеса

Встроенные функции для конкретных сфер (медиа, туризм, финансы и др.)

Широкие возможности интеграции

Интеграция SAP Commerce с другими решениями SAP и различными платежными системами

Гибкость и удобный User Interface

Легко настраиваемые функции и возможность расширения SAP Commerce

Поддержка мобильных устройств

Совершение покупок и адаптация дизайна магазинов под любые мобильные устройства

SEO-модуль для успешного продвижения интернет-магазинов в поисковых системах

Эксперты LeverX знают, как увеличить доход компании с помощью решения для электронной коммерции SAP Commerce

Благодаря функциям программного обеспечения SAP Commerce организации получают масштабные интернет-магазины с привлекательными возможностями для покупателей, включая программы лояльностей.

Требовательных клиентов полностью удовлетворяет качество обслуживания. Значит, доход компаний, сделавших свой выбор в пользу SAP Commerce, постоянно растет, а высокий уровень Customer Service удерживает текущих и привлекает новых покупателей.

Команда LeverX поможет вам с созданием интернет-магазинов на базе SAP Commerce, интеграцией SAP Commerce с решениями SAP или сторонними системами, поддержкой и обновлением уже внедренных решений до последних версий.

Воспользуйтесь возможностями SAP Commerce Cloud и экспертизой команды LeverX для увеличения онлайн-продаж!

Источник

Кому рецепты для электронной коммерции? Для SAP Commerce и не только

Моё хобби ― автоматизация онлайн-ритейла. Уже много лет даже в свои выходные я не вылезаю из этого «болота». Да, наверное, это звучит дико и даже смешно. Как можно увлекаться таким скучным делом? — скажут одни. Что там увлекаться, это просто какая-то частная тема для уважающего себя архитектора ПО! — скажут другие.

Действительно, на первый взгляд, это, как говорится, недиссертабельная тема. Фактически, это сборная солянка из разных тем, тем или иным образом притащенных в e-commerce. И в итоге оказалась ровно тем, что я люблю: интеграция технологий.

И вот с 2016 я веду техноблог, hybrismart.com. Такая «хабра» в миниатюре, только на английском и с фокусом на близкую мне тему — разработку на SAP Commerce. У нас тут сформировалась небольшая компания из нескольких десятков тысяч авторов, но в блог пока что пишет только часть из них. Ну, хорошо, пишут пока немногие. Десяток. Но мы стараемся. В блоге уже накопилось под две сотни статей, преимущественно больших и очень больших на самые разные темы, тем или иным боком относящиеся к ecom. В существенной части это всё-таки персональный блог, поэтому отдуваюсь тут я, а не наша пиар-служба. Но это от души, правда.

Как легко догадаться из названия, hybrismart — про хайбрис (что это такое?). И почти все, кто его находит, знают о хайбрисе не понаслышке. Ну и наоборот: наверное, каждый разработчик на hybris хотя бы раз в блог заходил (конечно, не по доброй воли, нам гугл помогает!). Теперь вот и вы зашли. И чтобы вы там не потерялись, хочу провести небольшую экскурсию. Задавайте, пожалуйста, вопросы в самом конце.

ЖАЖДА ПОИСКА

Кто-то скажет, что где e-commerce, там шопинг карт, а где шопинг карт, там — e-commerce. Но эту шопинг-карт ещё нужно найти. Как и товары. И тут возникает тема, в которой число самодельных «велосипедов» зашкаливает: поиск по товарам.

Пожалуй, это самый «жирный» топик на моем блоге. В хайбрисе за поиск отвечает Apache Solr, один из двух крупных и повсеместно известных опенсорсных движков (вместе с ElasticSearch). Но как вы понимаете, специфики хайбриса в статьях про поиск — минимум. Просто потому, что у всех примерно одни и те же проблемы.

Вместе с Тимофеем Клюбиным мы сделали гигантский обзор текстового поиска на иероглифических языках, описали типичные сложности у компьютеров с этими значками и способы их решения в Solr. Также вы узнаете про различные культурные и языковые особенности и специфику оформления фасетного поиска в Японии и Китае.

Тимофей кроме хайбриса и всяких айтишних штук давно изучает японский. Мне хотелось бы написать тут «а я — китайский», но увы. У меня труд родился в процессе глубокого изучения темы, вызванного нуждой по работе и желанием раз и навсегда закрыть вопросы, которые меня мучали, а Тимофей просто занимался любимым делом.

Поиск на японском и китайском поднимает проблемы, о которых вы даже не догадывались. Например, всмотритесь в подсказки гугла по слову «とうきょうえ» (tōkyōe), на которое гугл дает «東京駅» (tōkyōeki) (станция Токио). В данном случае оба слова являются разным написанием одного и того же, и поисковая система это знает. У японцев свои знаки пунктуации, два алфавита, сложная система с числительными, важен контекст. Все это мы описываем в деталях.

А эта работа относится к фасетному поиску. Осторожно, там очень много букв, но есть удобное содержание с ссылками. Было бы концептуально сделать фасетный поиск по статье по фасетному поиску, но я вовремя себя остановил.

В статье предпринята попытка систематизировать знания и опыт в этой области и организовать эти знания в виде одной большой «простыни» с фактами, ссылками, и best practices. Наверное, она должна быть полезна тем, кто по роду работы связан с пользовательскими интерфейсами.

Несмотря на то, что фасеты — самая часто используемая концепция в екоммерс (после шоппинг карт), и всегда есть большой соблазн изобрести какое-нибудь колесо. Судя по тому, что мы видим на сайтах, очень многие этим пользуются, получая в результате много несостыковок и противоречий. Я постарался их собрать вместе с решениями, которые считаются общепринятыми.

Поскольку «поиски» сейчас пошли умные, и часто лучше пользователя знают, что он хотел найти, а устройства маленькие и неудобные, большое внимание уделяется Search Suggestions — способу сформулировать желаемый поисковый запрос за меньшее время, за минимальное число нажатий клавиш, кликов мыши или «тапов» по экрану.

В статье я делаю обзор темы, «лучших практик» и частых ошибок. Статья родилась, когда я проектировал систему умного автокомплита для одной крупной biotech-компании, делающего удобнее поиск по антителам и реагентам. «Умный автокомплит» предлагал завершение текущего слова в одно нажатие, опираясь на уже введённые слова, определённые правила сочетаемости и статистику запросов. Ближайший аналог из лингвистики — после ввода глагола с больше вероятностью идёет существительное, чем другой глагол.

Некоторые материалы представлены на блоге не в виде статей, а в виде видеороликов. Всего их там штук 40 наберется. К сожалению, такой формат пока ещё не прижился. Здесь я рассказываю про Search Analytics — механизм сбора и обработки статистики, имеющей отношение к действиям покупателей с вовлечением поиска по товарам. Я придумал этот механизм для большого продуктового магазина в Европе и перепроверил его ещё раз для той самой biotech-компании из предыдущего примера. Вкратце, идея сводится к тому, что действия покупателей могут много рассказать про то, как работает поиск, и где у него слабые места. Например, статистика показывает, что некоторые товары ищут часто, но кладут в корзину редко (высокая цена? Устаревшие модели?), а другие — кладут часто, но довольно плохо ищут (подсказки?), а за третьими готовы прокликивать несколько страниц результатов поиска (какие-то нерелевантные товары вылезают вперед?). В общем, это такой Google Analytics, но — для поиска.

Иметь свой блог удобно тем, что туда можно выгружать идеи и эксперименты и высвобождать мозги под что-нибудь более актуальное и новое. В этой статье я описал концепцию «многострочного поиска» для B2B-сайтов, которая когда-то в свое время была актуальна.

Идея в том, что часто удобно искать на сайте, скопипастив целую группу артикулов или названий товаров в поле для поиска, чем делать это одной строчкой за раз.

В этой статье я описываю поиск похожих товаров — по цвету или форме. Это довольно «классическая» тема, но на практике, по непонятной мне причине, редко реализуемая. Я сделал прототип и описал матчасть. Практически все статьи подобного характера сопровождаются видео, как работает прототип с SAP Commerce, и эта — не исключение. Для интеграции с Apache Solr я использовал Lire (https://github.com/dermotte/lire).

Если в прошлой статье мы искали похожие товары по цвету и размеру, то тут показываются похожие по чёрт знает чему. Система рассчитывает и упорядочивает товары по принципу похожести индексируемого контента — описаний товаров, названий, характеристик. Тем больше сходства, тем ближе товары будут в таких «кластерах» друг к другу. Для пользователя же мы можем вывести товары, находящиеся поблизости в таком «пространстве похожестей», которые, скорее всего, окажутся товарами-заменителями.

Здесь я тоже описываю интересный эксперимент и прототип: система выставляет фасеты самостоятельно, основываясь на введённом поисковом запросе. Например, если вы ищите что-то запросом «красное платьишко 39 размера», то вам надо показывать не товары, у которых все эти слова есть в описании или названии, а товары, отфильтрованные по тегу «красный», «платье» и «размер 39». Для русского языка понадобятся ещё танцы с бубнами, а с английским все работает уже сейчас. Внутри есть демка, показывающая разницу между тем, как работает дефолтный поиск и он же, но с моей логикой поверх. Называется, почувствуйте разницу. Однако, нужно отметить, что такой подход всё ещё блещет сайд-эффектами, и нужно очень тщательно настраивать систему, чтобы она удовлетворяла всех или почти всех.

Есть известная проблема в SOLR (и это не только с хайбрисом), что многословные синонимы работают очень криво. С однословными ещё кое-как работает, но тоже со своими сложностями. В блоге описано решение, позволяющее обойти эти проблемы и сделать поиск умнее. При отстутствии однозначности система перебирает разные варианты замен и выбирает наиболее «выигрышную» замену.

На блоге есть ещё пара десятков статей на тему поиска. А на этом прекрасном месте тема поиска уступает теме расчёта акций и скидок и прочей лояльности.

АКЦИИ ПО ПРАВИЛАМ

«Купи два пуховика по цене трёх и получи один в подарок!». Что только маркетологи не придумают, чтобы программисты не скучали. Делаешь полгода совершенный «движок» акций, который умеет вообще всё и ещё немножко, и тут приходит менеджер с очередной идеей, из-за которой нужно переписывать половину! В хайбрисе тоже было два поколения таких «движков». Разработчики решили не изобретать велосипед и использовали JBoss Drools, довольно мощную систему управления бизнес-правилами, которая интегрирована в хайбрис для темы акционных механик, темы узкой, но разнообразной в своей узости.

Если в двух словах, то Drools — это среда выполнения бизнес-правил. Механизм обрабатывает так называемые «факты» — входные данные, — и выдаёт результат в результате обработки правил и фактов. В хайбрисе для Drools сделали интерактивный редактор правил «в терминах e-commerce», а также представили API для расширения.

Если какое-то правило срабатывает, то накладывается скидка. Правила применяются к корзине. Мой эксперимент, в описанной статье, показывает, что правила могут применяться не к корзине, но к комбинации корзины и текущего товара. То есть ты ещё на кнопку «купить» не нажал, а уже видишь, какие райские сады и великолепные дворцы сейчас будут добавлены в корзину как подарок. Предполагается, что это должно сделать пользователя счастливее и увеличить продажи.

Так вот, этот самый Drools интегрирован в платформу. А она — монолит. Монолит — это когда весь код растёт из одного места. И вот когда пользователь тыкает иконочку на шопинг карт, на сервере миллионы маленьких гномиков начинают создавать контекст для Drools, потом заполнять его «фактами», куда входят товары, категории, свойства пользователя и всякое ещё разное, от чего может зависеть акция. И происходит это на той ноде в кластере, куда принесло пользователя лоад-балансером. И если там вдруг в это время перебои с процессорными ресурсами или памятью, то пользователь будет страдать. Затем, пользователю вручают скидку или подарок, а сервер всё это хозяйство подчищает. До следующего раза, когда оно опять начнёт создаваться. В статье я описываю свой эксперимент в вынесении Drools в отдельный кластер и вынос этапа этого конфигурирования Drools из запроса. Кроме того, что это повышает производительность, это ещё позволяет делать довольно сложные акции, где участвует, например, миллионы «фактов».

В этом примере я показываю, как можно устроить рекомендательную систему на основе правил, используя уже готовый механизм на основе Drools. В моём прототипе рекомендательной системы рекомендации можно создавать интерактивно, конструируя логику связей аксессуаров с товарами или похожих товаров между собой. Например, анчоусы к пиву, ментос — к коле, берёзовый сок — к буратино, мыло — к верёвке, розетку и фай-фай роутер — к чаю и кофе. Рекомендации — это всегда хорошо, когда они со смыслом.

Ну раз я уже построил этот кластер, я не мог его не домучить и построить на его основе штуку, которая обрабатывала бы события на лету, накладывая на них на том же лету правила. Мне удалось разобраться и подключить Drools Fusion + Drools Server последней версии к hybris. Эта штука правильно называется Complex Event Processing. Смысл в том, что если у вас есть поток каких-либо данных для обработки в реальном времени, Drools Fusion позволяет делать это быстро и гибко. Например, в случае e-commerceтаких данных много. Самые простые — это клики и переходы.

Я записал и публикнул демку, из которой понятно, как это работает. Логи выгружаются куда-то в хранилище, а оттуда попадают в drools fusion для обработки. На языке drools пишутся правила, которые вытягивают из логов какие-то новые знания. В моей демке это просто идентификация фотограф/не фотограф по характеру посещённых страниц и кликов. Например, пользователь уже просмотрел тучу моделей и мы делаем вывод, что он любит моделей. Или долго водит мышью по фотографии любимого штатива, из чего мы делаем вывод, что он любит не только модели, но и штативы. Результат правил возвращается обратно в хайбрис и как-нибудь там может использоваться. Баннер показать или цены чуть-чуть понизить на фототехнику.

Основная особенность всего этого, что обрабатывается поток событий в реальном времени. В моём примере — это нахождение как минимум пяти страниц одной тематической группы за последние 30 секунд для одного пользователя.

Второй важный пункт в том, что такая система очень масштабируема, ведь каждый сервер работает независимо. В то время ещё была жива встроенной в хайбрис персонализация. Её потом заменили на платный сервис. Она была жутко тормозная, и поэтому её мало кто использовал. Здесь же нагружаются серверы, софт которых не стоит ничего: он бесплатен. А в хайбрис потом пропихиваются уже готовые решения, которые нужно там тупо визуализировать.

Drools также можно использовать для автоматизации сложных форм, и в своём эксперименте я показываю, как это может быть достигнуто. В этом эксперименте я демонстрирую как можно реализовать многостраничную, многоэтапную форму, у которой состав и конфигурация полей и шагов меняется в зависимости от введённой информации в другие поля. Такая логика довольно сложно реализуется в стандартных подходах к формам, и её программирование значительно облегчается, когда для описания правил используется Drools.

Чтобы плавно закончить тему с Drools и начать тему про всякое разное в e-commerce и хайбрисе, я представлю ещё подробный обзор акционных механик.

Замечаете, почти все темы не совсем и про хайбрис. Там везде он каким-то боком есть, но в целом e-commerce— это не вещь в себе. Всё связано со всем.

Конечно, на сайте есть ещё десятки материалов, которые довольно сложно понять тем, кто вообще не разбирался с хайбрисом.

Например, в этой статье я описываю проблему объединения корзин после аутентификации. Это когда вы положили пятьдесят разных уточек в корзину, а потом авторизовались, а магазин туда подмешал выбранных с прошлого раза 50 зайчиков. Есть разные стратегии по тому, как разделять уточек и зайчиков в этом примере, и я их разбираю. Стратегии разбираю, не зайчиков.

Эта вот тема, наверное, полезна лишь для разбирающихся в хайбрисе. Привожу ее тут как пример статьи «для своих». Их меньшинство, но они занимают свою важную нишу.

В хайбрисе есть специальный формат для импорта и экспорта данных. Называется Impex и со стороны очень похож на обычный CSV. Там есть очень простой язык разметки, показывающий, что вот этот блок ниже — товары, а вот тот блок ещё — категории к ним. В целом, довольно удобно, но не тогда, когда у тебя двадцать почти одинаковых сайтов на разных языках, и каждый раз, когда добавляешь какой-нибудь интерфейсный компонент на все двадцать, нужно без ошибок скопипастить одно и то же двадцать раз и потом это поддерживать. У меня был такой проект, и я предложил решение с макросами на JSON, которые помогали создать импекс из импекса-с-макросами. Там не обычные макросы, а с циклами и параметрами.

Если вы ничего не поняли, то это нормально. У нас ещё и шутки есть, которые никто вне тусовки не понимает. Хотя они все грустные, не будем про это. У нас же серьёзная статья.

Я когда-то работал руководителем разработки в Chronopay, и с тех пор тема электронных платежей висела надо мной тёмной тяжёлой тучей, пока я её не приземлил вот в эту статью и освободил мозги под новые челенджи. Там собрано самое необходимое для понимания вопросов интеграции с платёжными шлюзами и сервисами, бест практисес и типичные недосмотры, которых нужно избегать (или использовать, если вы злой покупатель).

А ещё раньше, во времена зачёток и пейджеров, я работал дизайнером и верстальщиком (впрочем, в коломенском педуниверситете и пейджинговой компании Мобилтелеком я тоже работал. Да, я уже старый). Не тем верстальщиком, который HTML, а тем, который про книжки и журналы, а иногда даже православные газеты, телепрограммы и ноты. И, конечно, я не мог обойти стороной тему Postscript и PDF, которые пугают очень многих из-за туманных и плохо документированных внутренностей. В статье я показываю, что не так страшен чёрт, и делаю обзор инструментов под генерацию PDF.

В этой статье я описываю прототип авторизации по USB-ключикам, и последние (на момент статьи) продвиги в этом направлении на рынке, типа беспарольной авторизации, поддерживаемой браузерами. Удалось интегрировать с хайбрисом Yubikey, описываю как оно получалось (и получилось).

Очередной эксперимент: использование размеченных областей на карте Google для различных целей в e-commerce: поиска оптимального склада, поиска доступных магазинов для самовывоза или лучшего доставщика, а может и самого факта возможности продать товар или услугу покупателю из этой зоны.

Работает это так: покупатель вводит адрес, а система его определяет в одну или несколько крупных зон. Различные компоненты системы зависят уже от этих крупных зон, а не от мелких компонентов адреса, таких как почтовый индекс.

Заодно разобрался с разработкой на Google AppEngine. Дело в том, что определение многоугольника (зоны), в который входит точка на карте (где покупатель), для ситуации «много зон сложной формы» потенциально может быть довольно «тяжелой» вычислительной задачей. И если есть возможность, ее лучше сразу делать на кластере, который может легко масштабироваться, а лучше еще и сам. И вот этот кейс отличный для Google AppEngine, где задействован Google DataStore для хранения параметров многоугольников, и Google Memcache для хранения кэша.

В этих статьях я рассказываю про механизм умного кэширования частей страниц. Каждая из частей имеет составной ключ, говорящий о том, от чего она зависит. Например, для кэширования списка адресов доставки интернет-магазина (пример у меня есть в видео) составным ключом может быть идентификатор пользователя — тогда для разных пользователей будут использоваться разные кэши.

Механизм особо эффективен, если «тяжелый» функционал (в смысле использования памяти и процессора) вынесен из контроллеров страниц в компоненты, т.к. для кэширования контроллеров страниц описанная методика подходит не идеально.

Чтобы лучше понять идею, проще всего посмотреть на скриншоты шаблонов в середине статьи.

А тут много про миграцию данных: best practices, инструменты, архитектура моей самописной тулзы. Хоть тут и есть в названии слово «Hybris», но как и в прочих, эта статья не на 100% про хайбрис, не очень «гиковая», так что, надеюсь, будет понятна и интересна всем, кто знает, что такое «миграция данных в веб-проекте».

Также на блоге есть довольно подробно разобранные темы с чат-ботами (Facebook, Skype, кастом), вынесение хранения сессий за пределы хайбриса в отдельный сервис, разбор всего, что касается аутентификации и логин-форм, разбор особенностей реализации тревел-сервисов (заказ билетов, отели) — часть 1 и часть 2, а также собранные best practices по интеграции по product availability с внешними системами, и какие сложности этот процесс имеет, и много-много чего еще.

Какие еще темы вы бы хотели видеть разобранными подобным образом? По концепции блога они должны иметь отношение к ecommerce. Буду рад любым отзывам и предложениям.

Источник