Підводні камені інтеграції інтернет-магазину та 1С:Підприємство

1. Складне завдання – складні рішення

У самій задачі обміну в загальному випадку беруть участь дві сторони, які зазвичай називають бекенд або бекофіс (це Ваша облікова система) і фронтенд або вітрина (власне інтернет-магазин). Менш поширена, але швидко набирає популярності схема «один бекенд - кілька фронтендів». В обох схемах все зводиться до необхідності організації надійної двосторонньої передачі даних. На боці бекенда зазвичай правиться інформація про товар (найменування, характеристики, опис, ціни, залишки і т.д.) на боці фронтенду - структура товарного каталогу, SEO дані, динамічні розділи каталогу, блоки динамічної перелінковки, банери і т.д. Окремим пунктом є передача інформації про замовлення та їх статуси. Є ще питання маркетингу та обробки заявок клієнтів, та їх висвітлення виходить поза рамки цієї статті, т.к. зазвичай такий функціонал (CRM) реалізується або в бекенді, або інтеграцією фронтенду із зовнішнім CRM рішенням. Технологічно завдання зв'язування двох систем в електронній комерції досить складне, тому доречніше навіть говорити не про налаштування синхронізації між ними, а про їх інтеграцію. Вибір конкретної схеми та технологій інтеграції – дуже серйозне питання, що багато в чому визначає те, як далі розвиватиметься Ваш проект. Причин тому кілька: - обидві наші системи - і бекенд і фронтенд - складні і розвиваються, особливо динамічно розвивається фронтенд, потрібно ретельно продумувати їх взаємодію; від правильності вибору залежить обсяг і складність доопрацювання в подальшому «під себе»;
- обравши одного разу рішення щодо інтеграції систем, змінити його буде дуже складно;
- обсяги переданих даних постійно збільшуватимуться, зв'язка повинна тримати навантаження;

На окрему згадку заслуговує питання роботи з великим асортиментом. Практика показує, що хоч би якою була зручна «адмінка» сайту, масові зміни набагато легше, швидше і надійніше робити в бекенді, тобто. в 1С.

2. На простому імпорті та експорті далеко не поїдеш

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

3. Уніфікація та стандарти – не завжди панацея

В основі – той самий обмін файлами між двома системами. Використовується перетворення (імпорт та експорт) в один з різновидів формату XML, основними елементами зв'язування даних служать ID довідників та об'єктів бекенда і фронтенда. У 1С:Підприємство такий функціонал є вже давно. Для більшості інтернет-магазинів його підтримка реалізована у вигляді плагінів. XML – де-факто стандарт обміну даними. Практично для будь-якої CMS є інструменти, у тому числі бібліотеки для PHP, що дозволяють обробляти такі дані.
Ізольованість. Немає прямої взаємодії між бекендом та фронтендом. За великим рахунком вони «не знають» хто і як обробляє дані з іншого боку, працюючи лише з даними, загорнутими в структуру XML.

Недоліки:

Залежність від розробника. У застосуванні до конфігурацій 1С:Підприємство існуючі реалізації обміну з використанням XML прив'язані до певних рішень фронтенду (CMS).
Складність налаштування. XML формат – складний, в ньому потрібно розбиратися. Ресурсоемкость. Розбір структури XML, так само як і формування файлів створює значне навантаження на процесор, особливо це критично на боці фронтенда. Вже при невеликих обсягах даних таких операції доводиться ставити на виконання в неробочий час фронтенда.
Великі обсяги даних, що передаються. Сам формат організації даних XML має велику надмірність, т.к. крім самих даних містить велику кількість службової інформації. Обсяг службових даних може у кілька разів перевищувати обсяг корисної інформації.
Проблеми конвертації. Оскільки учасники обміну повністю ізольовані один від одного, потрібно ретельно стежити за відповідністю типів даних на обох сторонах. При змінах – вносити їх на обох сторонах одночасно.
Проблеми синхронізації. Будь-яка неузгодженість в ідентифікаторах даних (довідники, документи) автоматично призводить до появи задвоєних елементів. Чищення даних у таких випадках – складна ручна робота, часто нездійсненна в робочий час, оскільки вимагає повного доступу до бази даних. про нові властивості об'єктів іншої сторони. Внесення їх у схему обміну - тільки вручну, причому одночасно на обох сторонах. Це також означає, що перенести частину функціоналу з фронтенду в бекенд без доопрацювання конфігурації (наприклад, перенести роботу з даними SEO в бекенд) буде досить складно або навіть неможливо.

4. Інтегровані рішення – наше все

Один із варіантів подальшого розвитку перерахованих вище схем – зменшення ізольованості учасників обміну один від одного шляхом вбудовування в бекенд додаткової підсистеми. Такий принцип вже давно використовується у деяких прикладних рішеннях на платформі 1С. Функціонал конфігурації збільшується шляхом «прибудови» до неї окремої підсистеми. Основні дані дублюються всередину підсистеми з постійною синхронізацією надалі вже навколо них розгортається новий функціонал. Основна конфігурація залишається незачепленою, а набір даних, доступних до роботи, розширюється. Одночасно з'являються і нові елементи інтерфейсу.
У разі синхронізації з інтернет магазином такий принцип покладено в основу комплексного рішення UNIMODULE. У конфігурацію 1С:Підприємство додається підсистема, з одного боку, має доступ до всіх даних бекенда, а з іншого, що імпортує та зберігає всю інформацію з інтернет магазину. Важлива частина інформації – структура SQL таблиць. В результаті в програмному середовищі бекенда стають доступними всі дані разом з їх структурою і API - і 1С і інтернет-магазину. та розпакування даних у службові формати обміну типу XML відсутні. Навантаження на процесор в бекенд істотно нижче інших схем.
Оптимальний обсяг даних, що передаються. Низька надмірність, мінімум службової інформації - практично чисті SQL запити.
Доступність даних - все в одному місці. У бекенді повністю доступна вся інформація про нові властивості об'єктів іншої сторони. Це важко переоцінити у ситуаціях, коли потрібне розширення функціоналу бекенда, наприклад, використання зовнішніх обробок. Практично все можна створювати та налаштовувати в бекенді.
Проблеми конвертації відсутні. Додаткові перетворення даних - пряме перед передачею та зворотне при прийомі відсутні. При налаштуванні типи даних обох сторін видно, що невідповідність виявляється відразу.
Проблеми розсинхронізації відсутні. Ще один наслідок доступності даних в одному місці. Немає зіпсованого телефону.
Простота експлуатації. Формат обміну даними та пов'язані з цим складнощі повністю відходять на другий план, оскільки забезпечуються інтегрованою підсистемою. Інтерфейс підсистеми виконаний за ідеологією платформи 1С:Підприємство і легко освоюється. . При виході релізів із значними змінами (1С та/або CMS), потрібна технічна підтримка розробника. Початкове налаштування також має виконуватися кваліфікованим спеціалістом від розробника.

5. Підбиваємо підсумки

Технічно все зрозуміло - інтегроване рішення за правильної реалізації є оптимальним вибором. У той же час за рамками порівняння залишилися питання, що відіграють важливу, якщо не вирішальну роль при виборі програмного рішення: - скільки буде коштувати впровадження? - Скільки коштуватиме супровід? доробка?
- що буде з 1С? Наскільки сильно зміниться конфігурація? Питання закономірні, оскільки практика показує, що недороге і просте рішення в процесі експлуатації може сильно обмежувати можливості роботи, або вимагати постійної і недешевої доробки. Особливо важкий випадок – зняття з підтримки конфігурації 1С: Підприємство. Виправлення помилок у конфігурації, новий функціонал можуть стати для вас просто недоступними.
Безумовно, вартість впровадження комплексного рішення суттєво вища за вартість інших варіантів. Однак, якщо розробник ретельно продумав усі ці питання, то вартість володіння та розширення функціоналу такого рішення – мінімальні. Жодних неприємних сюрпризів. Конфігурація 1С з підтримки не знімається, оновлення підсистеми виходять при необхідності і надаються в основному безкоштовно, весь штатний функціонал платформи 1С не торкнуться, а лише розширено. Як Ви вже могли здогадатися, йдеться про наш програмний продукт “UNIMODULE”, де все це реалізовано :) Підтвердження всього вищесказаного – успішний досвід – понад 600 впроваджень з 2010 року.

Завдяки архітектурі нашого рішення, дійсно глибокої інтеграції як з 1С, так і з CMS, в UNIMODULE реалізовані вражаючі функціональні можливості, частина яких взагалі унікальна на ринку рішень із синхронізації та обміну даними. наступній статті.