Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

SAP Commerce Cloud: що вам треба знати про роботу з платформою

Привіт! Мене звати Юрій Парфенюк. В ІТ я більше 8 років, останні чотири з яких займаюся проектами в EPAM Lviv, пов’язаними з цифровою трансформацією бізнесів, а саме з SAP Commerce Cloud. У цій статті розповім детально про платформу, її переваги й недоліки, приклади застосування й поширені міфи.

Для чого потрібна SAP Commerce Cloud

Нікому не відкрию Америку, коли скажу, що світовий ринок електронної комерції активно зростає, і темпи його розвитку є одними з найвищих. Коли у 2009-2010 роках почався період діджиталізації, компанії-лідери на ринку роздрібної торгівлі зрозуміли, що якщо не вийдуть з продажами в онлайн, то їхній успіх буде під загрозою. У 2016-2017 роках відбувся чи не найбільший хайп на купівлю товарів та послуг через інтернет, але він не згасає, а продовжує зростати далі.

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

Якщо раніше кожен Java розробник писав власний фреймворк, то згодом з’явилися вже готові рішення, які значно спростили роботу в цьому напрямі. Зараз для швидкого виходу на онлайн-ринок компанії купують вже готову платформу для інтернет-магазину і підлаштовують її під свої конкретні потреби. Такі базові eCommerce задачі, як вікно замовлення, ціни, каталог продуктів, кошик, — вже передбачені платформою. Тому розробники працюють над вирішенням конкретних бізнес-задач та функціоналу і не пишуть ті самі речі для кожного замовника.

Для бізнесу із річним прибутком більше мільярда американських доларів на ринку існує декілька основних гравців та платформ для eCommerce рішень:

  • Oracle Commerce Cloud (ATG);
  • Salesforce Commerce Cloud (Demandware);
  • SAP Commerce Cloud (Hybris).

Останню у списку (але не останню за значенням) платформу компанія Forrester визнала лідером в сегменті платформ для комерції за 2018 Q3 рік. Причому вона лідер і для масового (b2c), і для корпоративного сегменту (b2b). Я багато працюю саме з SAP Commerce Cloud, тому на ній зупинюся детальніше, щоб пояснити плюси та мінуси у роботі з нею.

Платформа № 1 для великих компаній

Hybris на ринку ще з 1997 року. Проте «нове дихання» платформа отримала після того, як у 2013 році її купив SAP SE, змінивши спочатку назву на SAP Hybris, а в 2018 році вона отримала назву SAP Commerce Cloud.

Тепер це комплексна платформа електронної комерції, що дозволяє створити зручний інтернет-магазин зі зрозумілим інтерфейсом незалежно від того, наскільки складні в компанії продукти чи послуги, бізнес-процеси чи ланцюги постачання. SAP Commerce Cloud легко підтримує омніканальностість. Це означає, що підприємства мають можливість здійснювати продажі через різні канали, рішення для яких платформа містить з коробки. Наприклад: інтернет-магазин, інтеграція з POS (Point of Service) та соціальними мережами, відділ підтримки, мобільні SDK та відповідні сервіси. Дуже часто SAP Commerce Cloud використовують бізнеси, що вже мають інфраструктуру у вигляді ERP, CRM та інших систем для автоматизації діяльності та роботи з клієнтами. Вони обирають рішення від SAP тому, що вже «з коробки» існує велика кількість інтеграцій з такими системами, і час на реалізацію проекту зменшується в рази. Відповідно, компанії можуть швидко вийти на ринок з новими можливостями і освоїти digital-канали продажів.

Як я згадував, SAP Hybris працює з сегментами b2b та b2c. Більше того, існують й інші сегменти, де не так багато систем, які можуть запропонувати конкретні рішення. Наприклад, публічний сектор, урядові організації. SAP Commerce Cloud навіть для цих сфер може запропонувати сценарії, які дозволять швидко вийти на ринок для проведення публічних закупок чи для операцій у галузі місцевого туризму.

Написати самому?

Отже, якщо узагальнити, SAP Commerce Cloud — це налаштований, упакований і задокументований набір певних технологій. Для більшості типових завдань в e-Сommerce ця платформа має розроблені готові блоки, які потрібно лише трохи підлаштувати під конкретний бізнес. Звичайно, ви скажете, що можна розробити подібну платформу з нуля. І цілком погоджуся з вами. Проте постає питання, скільки це займе часу. Чи вдасться зберегти потрібну архітектуру, масштабованість, продуктивність, безпеку, розширюваність, надійність і багато іншого за півроку-рік? Як показує досвід, при теперішніх вимогах до якості, функціональності і особливо безпеки писати все «з нуля» виходить дуже дорого, довго і ризиковано.

Досвід роботи нашої команди з SAP Hybris я можу назвати абсолютно успішним. Наприклад, завдяки використанню платформи, ми запустили систему у внутрішній продакшн через три місяці після підписання контракту. Команда складалася з 20-30 людей. Є багато інших прикладів, де кількість спеціалістів в команді менша і терміни більші чи навпаки.

Архітектура та технології

SAP Commerce Cloud (Hybris) побудований на Java. Основний фреймворк — це Spring і вся його екосистема. Ти фактично працюєш із сетом технологій 95% всього Java-ринку проектів. Але маєш ще додаткові специфічні знання самої e-Commerce та платформи Hybris. Для себе в цьому бачу плюс: я і далі залишаюся Java-розробником і можу в будь-який момент переключитися на класичний Java Spring проект. Але у мене є ще й більш специфічні знання, які додають цінності на ринку, — знання SAP Hybris.

Давайте розглянемо платформу детальніше.

В основі SAP Commerce Cloud — платформа, яка є ядром всього продукту. Саме довкола неї вже будуються розширення та модулі. Платформа забезпечує базові технічні сервіси. Вони реалізовують відповідні базові сервіси. Наприклад, Configuration, ORM, Cache, L10n та ін. У свою чергу, додатки (extension) розширюють певні бізнес-можливості, такі як commerce (cart, PDP, order), search, CMS. Також містяться і додаткові фреймворки, яких немає «з коробки», але необхідні для замовника. Наприклад, інтеграція із зовнішньою системою ERP, яка має власний API та SDK для роботи з ним. SAP Commerce Cloud — модульна система, яка є гнучкою та легко піддається розширенню. Додаток (extension) — це фактично модуль, який інтегрується в загальну платформу і використовує її API.

Є певна кількість типів/шаблонів додатків чи розширень (extensions), але в загальному їх можна поділити на дві основні групи: базові (core) та веб-додатки (web extension).

Core — базовий тип модуля, він використовує API платформи та інших модулів.

WEB extension — фактично реалізовує web application, який базується на Servlet API, а отже цей тип додатків використовується для рівня представлення (presentation layer) у платформі (CMS, RESTful APIs та ін.).

Основним Application Framework є Spring Framework і фактично вся екосистема Spring. Для управління залежностями використовується Spring IoC контейнер, для WEB — Spring MVC, для інтеграції з іншими системами — Spring Integration.

Як Servlet контейнер використовується Apache Tomcat 8.5. SAP Commerce Cloud має власну ORM систему, яка надає можливість застосовувати більшість доступних на ринку систем управління базами даних, таких як: MySQL, PostgreSQL, Microsoft SQL Server, SAP 4/Hana, Oracle DB. Також можна використовувати продукти, які сумісні з відповідними вендорами, наприклад: PerconaDB, MariaDB та ін. А також хмарні DB: Amazon Aurora, Amazon RDS, Azure SQL Database тощо.

Для реалізації пошуку використовується Apache SOLR. Основні системи збірки (build tools) — Apache Ant та Gradle.

Хто такий SAP Commerce Cloud розробник

Враховуючи опис основних технологій, які використовуються в SAP Commerce Cloud, можна зробити висновок, що SAP Commerce Cloud Software Engineer — це фактично Java Software Engineer, який має досвід роботи з екосистемою Spring. Також важливі навички роботи з JavaScript та CSS.

Отже, як я писав раніше, розробник продовжує працювати зі стеком технологій, який використовується в більшості Java проектів, але здобуває додаткові знання, що додають йому вагомості на ринку.

Як це все працює на реальних проектах

Приклад #1. Глобальна компанія. Рітейл

EPAM розробляє e-Commerce рішення на основі SAP Commerce Cloud для американської компанії, яка є світовим лідером з продажу товарів для здоров’я, краси і дому. Платформа, над якою ми працюємо, дозволяє спростити ключові бізнес-процеси та покращити управління, виконання потоків комерційних даних, одночасно покращуючи користувацький досвід. Це один з найбільших наших проектів, який став основою для росту Hybris компетенції EPAM у Львові.

Ядро команди — це здебільшого Hybris-спеціалісти. Проте це не лише розробники, але й тестувальники та бізнес-аналітики. Для цього проекту ми розробляємо end-to-end solution, тому можна побачити, як відбувається процес продажу товару або послуги від початку і до кінця, виконуючи весь ланцюжок послідовних кроків — від реєстрації користувача до оформлення замовлення та доставки. Тобто ти бачиш цілісну систему, яка вирішує завдання цього глобального бізнесу та їхню специфіку Multi-level Marketing.

Як я раніше згадував, проекти на SAP Hybris платформах інтегруються з різними системами. Наприклад, у цьому проекті ми інтегрувалися з понад 80 різними системами, мікросервісами і з трьома різними провайдерами оплати.

Оскільки це глобальна компанія, то вона має відділення фактично у всьому світі. На рівні головного офісу в них є щось на зразок opensource — це певний набір, додатків який дозволяє швидко інтегруватися з екосистемою компанії, якою вони діляться зі всіма регіонами. А вже відповідно до специфіки платіжних систем, податкового законодавства і т. д., в кожному регіоні дописуються нові розширення. Зараз ми створюємо проекти для трьох країн північної Америки, і в кожній своя специфіка.

Сам проект не складається суто з Hybris частини. Адже є POS термінали, є мобільні додатки, і для того, щоб все працювало злагоджено, ми виставляємо Commerce API, яка фактично є RESTful сервісами. Також ми надаємо Headless CMS API для інших систем.

Приклад #2. Аеропорт

Один із відомих аеропортів почав активно робити цифрову трансформацію своїх процесів, щоб побудувати кращий клієнтський досвід, та, відповідно, отримувати більший прибуток. Проект для аеропорту — це marketplace акселератор, де аеропорт виступає посередником між вендорами та пасажирами.

За три місяці ми зробили величезний обсяг роботи, і вже відбувся реліз версії 0.5 — family release, як її називає замовник. Ми випустили одразу дві версії з повним функціоналом: десктоп і мобайл. Вони мають форму для реєстрації та особистий кабінет, landing-сторінки брендів, пошук та уніфікований процес оформлення замовлення з доставкою до місця посадки на літак і т. д.

Цей проект не такий великий, як попередній. Замовник намагається перевикористати основний функціонал, який є з коробки. Проте специфіка в тому, що вони хочуть побудувати Connected Airport концепцію. Коли всі сервіси, що є в аеропорту, людина може замовити, купити та отримати безпосередньо перед вильотом. Для цього і створена ось ця єдина платформа для всіх торгових представників, які інтегруються з системою, заливають свої пропозиції, продукти, ціни, акції і т. д. І людина може просто з одного місця зайти, знайти продукт чи послугу, подивитися деталі і придбати, те що потрібно.

Приклад #3. Платіжна система

Це досить маленький проект порівняно із попередніми, проте не менш цікавий. Фактично, це не розробка під конкретного замовника, а розробка розширення для платіжної системи, яка доступна в центрі додатків SAP для розширення SAP Commerce Cloud.

До нашого клієнта (платіжна система) приходять із запитом, чи він має готові плагіни для SAP Hybris, щоб інтегруватися з його системою. Ми розробили таке розширення, яке дозволяє вбудовувати платіжну систему нашого замовника в різні версії Hybris і відповідно здійснювати оплату за замовлення. Інтернет-магазини можуть використовувати out of the box рішення для інтеграції з платіжною системою та змінювати певні налаштування під свої потреби.

Цікаво те, що ми підтримували цей проект з версії Hybris 5.4-5.6-5.7-61.1 аж до 18.08. Під ці версії ми робили підтримку на b2c та b2b канали. Коли ми писали конкретний функціонал, його треба було перевірити на всіх цих версіях і написати так, щоб він був сумісний з усіма версіями.

Приклад #4. EPAM Spark

Це внутрішня розробка. По суті, це платформа-акселератор для використання певних готових розширень, які характерні для більшості проектів. Кожен інженер може використовувати його, щоб швидко втілити рішення на базі SAP Hybris на новому проекті з преінтегрованими системами оплати, розрахунку податків, доставки, логістики, з автоматичним розгортанням у хмарі, CI/CD, тестовим фреймворком і так далі.

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

Недоліки

SAP Commerce Cloud, звичайно, має багато своїх переваг порівняно з іншими e-Commerce платформами. Але у світі немає нічого ідеального, і тут теж є свої недоліки:

  1. Багато замовників шукають рішення, яке максимально зменшить їхні видатки на розробку, підтримку та операційне обслуговування. SAP Hybris залишається системою, яка не є SaaS, хоча активно рухається в цьому напрямку. Але, починаючи з травня 2019 року, SAP продає лише ліцензії, тоді як обслуговування здійснює лише сам SAP. Це означає, що більше не можна купити SAP Hybris і розгортати його у власний дата-центр чи AWS, Azure, GCP і т. д.
  2. Технології для розробки front-end достатньо застарілі (Bootstrap, jQuery і т. п.). Це створює проблеми з розробкою сучасних SPA чи PWA. Хоча необхідно згадати проект Spartacus, який, влаcне, є першим кроком компанії SAP у розробці нового інтерфейсу для SAP Commerce Cloud. Важко прогнозувати, як буде розвиватися проект, тому що в принципі складно щось прогнозувати у світі UI-технологій :)
  3. Важко назвати це недоліком платформи — це скоріше недолік комерційного програмного забезпечення — закритість документації та доступу до платформи. Тобто ви повинні мати доступ до сервісів компанії SAP, щоб отримати доступ до документації, платформи і т. д. Було б класно, якщо б платформа була доступна, наприклад, під GPL для розробників і платною для комерційного використання. Це надало б можливість отримати більше спеціалістів, а компанії SAP — зворотній зв’язок від community. Як результат, це зробило б її ще кращою. Варто зазначити, що перші дзвіночки ми можемо побачити в тому ж Spartacus. Також ми в EPAM активно розвиваємо community. Наприклад: hybrismart.com є найпопулярнішим публічним ресурсом про SAP Commerce Cloud.

Основні міфи

Ми часто чуємо певні упереджені думки про SAP Commerce Cloud. Проаналізувавши їх, ми сформували основні міфи, що існують в уяві розробників про платформу. Давайте спробуємо розібратись, чи це насправді так.

Міф 1. Несучасні технології та не новітні передові розробки

Як уже згадував раніше, платформа побудована на екосистемі Spring: Spring Framework (version 4.3 in 1808), Spring MVC, Spring Security, Spring Integration, Spring Session та ін. Використовує Apache Tomcat 8.5 як Servlet контейнер, Apache SOLR 7.5 для індексованого пошуку.

Системи збірки (Build tools): Apache Ant, Gradle.

Міф 2. Велика платформа, повільний процес розробки

Платформа «з коробки» підтримує багато функціоналу для різних задач з commerce домену. Саме тому збірка та старт вимагає більше часу, ніж середньостатистичні проекти. Наприклад: якщо ми говоримо про b2c набір можливостей, то збірка займатиме ~1.5-2 хв та старт 1-2 хв на станції з i5/i7 CPU, 16 Гб RAM, SSD.

Але для пришвидшення роботи ми в компанії використовуємо JRebel, який власне дозволяє не робити збірку та старт кожного разу, коли змінюється програмний код.

Міф 3. Специфічний набір технологій

Як я писав вище, у платформі використовується технологічний стек, який фактично є основним для більшості проектів. Тому немає ніяких проблем перейти з hybris на інший проект, який побудований на Spring-стеку. Але зважаючи на те, що платформа розрахована на специфічний домен, існує фреймворк платформи та правила (best practices), яких необхідно дотримуватись. Також для пришвидшення написання систем для роботи продукт-менеджерів та контент-менеджерів існує Cockpit framework, який дозволяє писати Web UI на Java. Він схожий за принципом на GWT. Цей фреймворк побудований на ZK framework, що не дуже часто використовується в проектах. Необхідно зазначити, що в останніх версіях платформи, Сockpit framework видалений, і на його місці використовується backoffice, який залишається специфічним саме для цієї платформи, але має кращу архітектуру та підходи.

Якщо підсумувати, Java розробник фактично не змінює основний стек, а навпаки додає специфічних знань платформи. У нас часто бувають випадки, коли замовник, окрім розробки основної системи на hybris, потребує ще додаткових сервісів для підключення існуючих застарілих систем, у яких немає API. У таких випадках ми розробляємо мікросервіс, який фактично виставляє API (наприклад RESTful) для платформи та інших систем. Ці сервіси розробляються hybris інженерами. Як, наприклад, Spring Boot сервіс.

Міф 4. Власна ORM система, мова запитів, ETL. Переважно робота з XML та конфігурацією замість програмування

SAP Commerce Could має власну ORM систему та мову запитів, які за підходами дуже схожі з JPA. Основне, що не подобається Java-розробникам, — це те, що опис сутностей (Items) здійснюється в XML-файлах. Вони в залежності від проекту можуть бути досить громіздкими. В результаті з XML-опису сутностей платформа згенерує Java класи — models. Наприклад: UserModel, ProductModel, CartModel. Відповідно, неможливо змінювати Java код згенерованих сутностей. Для роботи з моделями використовується ModelService, який фактично є аналогом EntitManager в JPA. Для мови запитів використовується також власний діалект. Він оперує на рівні сутностей — Flexible Search Query, яка дуже схожа з JPQL (Java Persistence Query Language). Можна сказати, що Item/Model == Entity, ModelService == EntityManager, FlexibleSearchQuery == JPQL.

Для DTO (Data Transfer Object) також існує підхід, який дозволяє генерувати Java Beans на основі опису в XML. Звичайно, ви можете писати власні Java Beans, не використовуючи запропонований підхід платформою. Дуже часто використовується наявна реалізація, і для додавання нових полів вам буде необхідно зробити так само, як і «з коробки», а отже описати ці поля в XML.

Сподіваюся, ця стаття допомогла зрозуміти, що це за «звір» SAP Commerce Cloud (Hybris) :) А для тих, хто хоче більше зануритися в тему, залишаю декілька корисних лінків:

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному2
LinkedIn

Схожі статті




22 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

На сьогодні напевон більша частина бізнесу працює на 1С. Мабудь процентів 70. Нажаль в Україні не створили гарного аналога. Вважаю SAP це готове рішення а не гнучкий фреймворк. Підганяти готове рішеня це не зовсім добре. Помиляюсь?

Ви напевне плутаєте SAP CRM тв SAP ERP з SAP Commerce Cloud

Salesforce — сила, SAP — могила

Мсьє крутить Salesforce Commerce Cloud?

Ну але в SAP розвинутіший B2B функціонал

В них справді затята боротьба зараз.

Звучит как типичный RAD-космодром швейцарский нож, которые так любит SAP — своеобразные абстракции поверх industry standard решений, монолит-first подход во всем(я так и не понял, где там микросервисы, если везде из описания синхронные http api интеграции), быстрое устаревание поддерживаемых технологий для разработки модулей, непонятный scaling-out подход.
Time to market ок, а что дальше — как скейлить core компоненты, как скейлить команды — что скажем если надо вести разработку параллельно 5 командами в core сервисах или сделать multi-tenancy и оптимизировать latency для юзеров работающих в us/asia, как сделать scale если в системе становится в 2х, 3х больше юзеров, как сделать pay as you go, если система в течении 80% времени суток имеет загрузку меньше 20%, как сделать побыстрому красивый ui , не по образу бутстрапа 8ми лейтней давности, как сделать ci/cd и как тестировать весь этот xml, jquery и flexible search query, как дебажить отдельные модуля без старта всего приложения, где compile time safety для всех этих конфигураций, как обеспечить версионируемость паблик контрактов и multiversioning в продакшине если надо для разных компонентов иметь различный delivery цикл или надо все релизить одним махом как в классике монолитов 2000-х?

Багацько запитань, але спробую відповісти.

я так и не понял, где там микросервисы, если везде из описания синхронные http api интеграции)

еммм тут щось не докінця зрозуміло де звязок. Можливо ви мали на увазі щось про реактивні системи?

что скажем если надо вести разработку параллельно 5 командами в core сервисах

я зараз на проекті де 7 хайбріс команд, UI команда іще декілька які з нами інтегруються. Не бачу проблеми в організації роботи, таке враження що раніше ніхто проекти не розробляв великими командами :)

или сделать multi-tenancy

є підтримамка з коробки, взагалі без проблем;

птимизировать latency для юзеров работающих в us/asia,

ну тут не питання до самої платформи, а швидше до її деплойменту і ці проблеми присутні у всіх системах. Але нащастя є вже готові рішення такі як Availability Zones, CDN, Web caches і т.д. Ми наприклад використовуємо на одному з проектів Akamai.

как сделать ci/cd и как тестировать весь этот xml, jquery и flexible search query

про це напевне треба написати окремо, але процес абсолютно не відрізняється від інших технологій.

как обеспечить версионируемость паблик контрактов и multiversioning в продакшине если надо для разных компонентов иметь различный delivery цикл или надо все релизить одним махом как в классике монолитов 2000-х

тут напевне все таки два питання: версійність інтеграційних контрактів та реліз цикли для різних компонент системи.
З коробки OCC API манеджить версійність за допомогою різних Spring MVC DispatcherServlet, тобто якщо ваша зміна справді порушує контракт, тоді ви просто додаєте новий мапінг на версію і котролер(и) який буде хендлити запити. Але насправді ви можете реалізувати підхід який вам більше підходить.
Нарахунок релізу — так зміни необхідно інтегрувати якомога швидше щоб «fail fast», і деплоїтись також разом. Використовується на проектах Blue/Green з Zero-downtime, для того щоб сесії в користувачів не завершувались — Spring Session з Redis.

еммм тут щось не докінця зрозуміло де звязок. Можливо ви мали на увазі щось про реактивні системи?

из описания звучит, что это просто система с поддержкой soa(распределенные компоненты что интегрируются по http). где там микросервисы?

я зараз на проекті де 7 хайбріс команд, UI команда іще декілька які з нами інтегруються. Не бачу проблеми в організації роботи, таке враження що раніше ніхто проекти не розробляв великими командами :)

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

є підтримамка з коробки, взагалі без проблем;

Это правда что надо развертывать полную копию и дублировать во всех tenant шередные данные что бы она работало?
answers.sap.com/...​for-hybris-marketing.html
Я бы не назвал это поддержкой из коробки multi tenancy

ну тут не питання до самої платформи, а швидше до її деплойменту і ці проблеми присутні у всіх системах. Але нащастя є вже готові рішення такі як Availability Zones, CDN, Web caches і т.д. Ми наприклад використовуємо на одному з проектів Akamai.

availability zones инструмент для отказоустойчивости, latency — никак.
CDN — то есть мне надо купить отдельно CDN и залить туда свой static контент, это ж к продукту не имеет никакого отношения? как насчет latency работы с read api — все данные на сайте?
Web caches — и как мне это поможет получить быстрее ответ для юзера в asia, который работает с us инстансом?

про це напевне треба написати окремо, але процес абсолютно не відрізняється від інших технологій.

да ладно, ci/cd — можно ли сделать с тем, что релизится как часть hybris платформы(например я меняю конфигурацию каких-то core компонентов или extensions) что бы я закомитив что-то в конфигурации в git тригернулся билд, прогонка unit/int тестов(если там кастомный код есть), диплой на среды и прогонка acceptance test и релиз в uat новой версии компонента hybris/вашего custom кода развернутого на hybris?

З коробки OCC API манеджить версійність за допомогою різних Spring MVC DispatcherServlet, тобто якщо ваша зміна справді порушує контракт, тоді ви просто додаєте новий мапінг на версію і котролер(и) який буде хендлити запити. Але насправді ви можете реалізувати підхід який вам більше підходить.

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

Основний фреймворк — це Spring і вся його екосистема. Ти фактично працюєш із сетом технологій 95% всього Java-ринку проектів.

Звідки інфа? По всім опитуванням, що бачив спрінг використовує тільки половина розробників.

Колись читав статтю про популярність Spring vs Java EE і там були такі цифри, але от зараз неможу знайти пруф лінк. Трохи пошукав і хіба знайшов щось схоже тут www.baeldung.com/java-in-2018 але це тільки ~80%. По інших ослідженнях справді десь приблизно половина. Та й останнє дослідження нашого ринку показує що 56% dou.ua/...​or-senior-java-developer Соррі за числа без пруфа.

WOW! Ти займаєся CCv2?

Це ви займаєтесьhttps://kyma-project.io/ ?
Слух але круто! Я там тобі ріквест в лінкеді кинув, будемо досвідом ділитись ;)

Хороший огляд платформи Hybris в статті, але, на мою думку, щоб зрозуміти, що це за «звір», просто треба з ним попрацювати :)
А що скажете про performance платформи? Які потужності серверів використовуєте для навантажених ecommerce b2c/b2b сайтів? І враховуючи, що хостинг в cloud на стороні SAP, що можете сказати про support SAP Hybris?

— Справді найкраще раз спробувати ніж 100 раз почути/прочитати :)
— Performance дуже відносне питання: все залежить від SLA(вимог) які ставиить замовник та власне рівня кастомізації(модифікації) під конкретні потреби. Наприклад в нас були вимоги: 7-8тис замовлень в годину, 10тис. активних користувачів, були навіть 50тис batch ордерів за 1 год. Також замовник проводив стрес тестування коли за 10хв одночасно логінилось ~15тис користувачів, мали перевіряти більше, але тестовий інстанс SSO на AWS лямбдах мав обмеження по кількості запитів. Найбільше втрат по швидкодії завдає зміна стану системи, наприклад просто пошук продуктів, є досить швидким так як відбувається в SOLR, а от додавання продукту в коризину, з мого досвіду, завжди несе за собою проблеми, так як змінюється стан корзини, відбувається повна рекалькуляція, яка за собою несе перевірку промовшенів, наявність, податки і т.д. А якщо ще врахувати, що щось було змінено під вимоги замовника, а в більшості випадків так і є, то саме корзина стає проблемним місцем.
— Якщо говорити про потужності серверів в SAP Commerce Cloud сервісі, ну тут швидше треба говорити з SAP. Я бачив дуже різні конфігурації hybris кластерів, були навіть такі де одна нода мала VM з 64 Гбайт RAM та CPU 32 core, але як на мене той сетап був недуже вдалий так як ресурси просто не використовувались. В більшості випадків налаштовуються кластера з різними layers(рівнями) та групами нод, які відповідають за конкретні задачі(storefront, backoffice, integration, cronjobs etc), кожна нода мала по 16Гбайт RAM з яких для JVM 12Гбайт(типу щось на зразок AWS c5.2xlarge) в кожній гропі по декілька нод для балансування навантаження та відмовостійкості. На проектах часто в нас K8s і відповідно є Scaling Up/Down як самого hybris кластера так і K8s кластера, що дозволяє ефектифгніше використовувати ресурси.
— SAP CCv2 вже набагато кращий ніж перша версію, яка фактично була повністю мануальна і тікет процесався днями. В новій версії SAP автоматизував більшість процесів, але «нюаси» всеодно присутні, сподівають вони швидко імпрувнуться :)

Дякую за відповідь. За K8s кластера не знав в Hybris. Це я так розумію вже SAP CCv2? І от доречі про CCv2 мало інформації, тому цікаво було почути ваш фідбек.

https://medium.com/@marko.ullgren/two-clouds-in-practice-a-comparison-of-sap-commerce-cloud-v1-and-v2-592077658e01
Вот фидбек от юзеров нашёл. Красивенький дешборд для ресурсов, мануальные 1,5 часовые залипающие билды(как видим все devops friendly) и 30 мини на развертывание локально и никаких оптимизаций — все апи намертво вшито в платформу, взяли контейнеры чтоб продавать но зачем они понять так и не смогли и какой же RPO/RTO у этой системы боюсь спросить. Никакого autoscale и это 2019 год на дворе и SAP как обычно продаёт это как flexible и fast clod-friendly решение для крупных проектов. Но уже радует что никакой SAP HANA — это большой шаг для них.

Я з ним працюю, можу підтвердити: CCv2 — шлак

Ні я писав про замовника який деплоїться на AWS. SAP CCv2 зараз на базі Azure, в них також контейнери, але не впевнений що K8s. Насправді багато чого в них скрито і ви докінця так і незнаєте що і як.

Підписатись на коментарі