30 мая Мы выступил с рядом докладов в различных секциях конференции СВАЛКА , который состоялся в Екатеринбурге.
Изначально нас просили затронуть холиварную тему «зачем 1С-Битрикс», блин :-), но мы решили ограничиться проблемами настройки ящиков при создании платформ, синхронизированных с системами товарного учета (далее СТУ).
Вот о чем был доклад. Артсофте чаще всего сталкиваются с проблемами интеграции интернет-магазина с 1С\Скала\СуперМАГ и системами онлайн-платежей.
Мы также внедряем системы отслеживания статуса заказов, но не ограничиваемся ими.
В пул интегрированных решений могут входить и более сложные системы, такие как онлайн-банкинг на стороне клиента, интеграция с биллинговыми системами и т.д.
Проблема
Мы Мы занимаемся исключительно заказной разработкой на Symfony(PHP) и .
NET, и к нам часто обращаются клиенты, уже имеющие разный опыт.
Когда мы посещаем клиентов, мы часто сталкиваемся с 3 вариантами безысходности.
- а) Клиент не имеет четко поставленной задачи и задает вопрос: «А что, если я попробуюЭ» В этом случае мы рекомендуем клиенту сначала поиграться с одной из коробочных версий, а потом уже смотреть пп.
- б) Клиент решает создать свой дизайн, обращается к решению нижнего ценового сегмента и в результате получает «велосипед».
И, казалось бы, все хорошо, заказчик доволен.
Он периодически выгружает товары на сайт и вводит заказы в 1С.
Но через некоторое время оказывается, что колеса у велосипеда квадратные, сиденье не регулируется, а селектор передач отсутствует вообще.
Без поддержки создателя своей системы клиент оказывается в тупике.
- в) Клиент выбрал «коробочное» решение.
Так исторически сложилось, что несмотря на наличие различных производителей решений СТУ, таких как Oracle, Scala, СуперМаг и т.д., в подавляющем большинстве случаев СТУ обращается к комплексу 1С:Предприятие во всех его различных конфигурациях.
Поэтому, когда речь идет об интеграции интернет-магазина с системой товарного учета или учетной системой, в первую очередь рассматриваются решения, обеспечивающие возможности интеграции с 1С «из коробки».
И вполне логично, что речь идет прежде всего об объединении «1С-Предприятие» и «1С-Битрикс».
Это решение действительно довольно просто реализовать, и на какое-то время дела обстоят намного лучше, чем в первом варианте.
Веб-приложение будет разрабатываться с учетом бизнес-требований заказчика.
Если система товарного учета или CMS не имеет инструментов синхронизации, либо эти инструменты несовместимы, необходима модификация одного или обоих звеньев, что может повлечь за собой значительные затраты для заказчика, как по времени, так и по стоимости.
Эти затраты могут даже превысить стоимость других работ, либо заставить заказчика перейти на другое решение (имеется в виду решение для товарного учета или магазина) Так или иначе, такое решение, «доработанное» или взятое прямо из коробки, со временем исчерпает пределы стандартного функционала.
Ящик будет переполнен.
Тупик.
Описанные выше сценарии, помимо проблем интеграции как таковых, могут иметь и «побочные эффекты» для заказчика.
Пример проблем, вызванных кривым интегрированием:
1. Дело «детсад.ру» Наш SEO-отдел продвигал сайт detsad.ru, разработанный другой компанией.Данный сайт представляет собой простой интернет-магазин с трехуровневой иерархией каталогов и настроенной синхронизацией с 1С-Бухгалтерией путем ручной загрузки CSV-файла через CMS. Путь к странице каталога (в данном случае представлена ссылка с максимальным уровнем вложенности) выглядит следующим образом: www.detsad.ru/catalogue/200/3598 , где последние две цифры — это категория и номер продукта соответственно.
Проблема была в том, что эти цифры соответствуют идентификаторам в 1С, которые имеют свойство меняться.
В результате синхронизации старые ссылки на товары стали некорректными и как следствие сайт потерял позиции в поисковых системах.
В результате мы переписали парсер.
2. Дело «Звезда» Вот еще один пример.
Допустим, мы с друзьями решили выпить пива.
Мы любим Хугарден и решили заказать коробочку.
Мы любим делать покупки в супермаркете «Звездный», но нам лень туда идти.
Поэтому мы решили заказать пиво в интернет-магазине «Звездный».
Оказавшись на главной странице интернет-магазина, выберите: «Пиво», «Сан Инбев», «СБ»,… что за черт? Что за «Сан Инбев»?! Что такое «СБ», «ЖБ», «ПБ»? Это железобетон? 
Я просто представляю, как захожу в магазин и смотрю на огромную вывеску: «Пиво».
Сворачиваю в отдел «Сан Инбев», ищу стойку «СБ», а на ней… Ну нет, я даже пива больше не хочу.
Я лучше пойду куплю питьевой воды.
Это не так уж и глубоко.
В результате клиент понимает, что ему необходимо новое решение, которое не только полностью учтет бизнес-логику, но и улучшится вместе с его бизнесом.
Исходя из нашего опыта, мы можем с большой долей вероятности предположить, что при интеграции STU и веб-интерфейса разработчик просто копирует структуру каталогов из STU. 
Результат – низкая конверсия.
Когда мы запускаем заказной интеграционный проект, в большинстве случаев приходится сталкиваться с тем, что компании, как правило, не имеют разработанной и реализованной ИТ-стратегии.
Правила и политика разработки, внедрения и использования информационных систем, принципы и методы интеграции не описаны.
Начиная работу над проектом, вам придется разработать эти документы с нуля и формализовать бизнес-процессы.
Работа над такими проектами обычно начинается с формализации проблемы, которую мы называем «моделью черного ящика».
Схема этой модели следующая: 
На входе обычно имеется задание на разработку, содержащее в общем виде требования заказчика, а также общие данные об используемых системах товарного учета (СТУ).
Разрабатываемое Web-приложение и STU представляют собой черные ящики, внутренняя структура которых если и известна, то обычно известна в самых общих чертах.
Первым этапом работы над проектом является декомпозиция Веб-приложения, которая позволяет понять требования к собственной архитектуре и на основе этих требований построить логику взаимодействия с СТУ.
Но почему бы сразу не начать реализацию с детального анализа и сразу прийти к индивидуальному решению? В большинстве случаев ответ прост. Предлагая свои услуги заказчику, компании по-разному оценивают необходимый объем работ. и когда предложения отличаются в цене до 30 раз (реальный случай из нашего опыта работы с B2B магазином shop.nag.ru) ), предложения из нижнего ценового сегмента выглядят наиболее привлекательными для покупателя, но в то же время в них есть подвох.
Являясь одним из ключевых факторов, низкая стоимость внедрения системы не означает, что мы сэкономили деньги, и при выборе решения мы должны оценивать в более широком аспекте, например, рассчитать стоимость владения интегрированным решением, а также он будет включать:
- Собственно, стоимость основных компонентов программного обеспечения
- Стоимость внедрения программных компонентов, если необходимо
- Стоимость внедрения интеграционного решения
- Затраты на последующую настройку интеграционного решения
Отсутствие какого-либо упоминания о стоимости поддержки в коммерческом предложении создает для заказчика радужную картину и все дело в том, что коробочное решение будет действительно недорогим в плане внедрения.
Интернет-магазин на Битрикс или VirtueMart с шаблонным дизайном можно развернуть за пару часов, не считая контента.
После этого загрузки настраиваются так же быстро.
Но что делать, если нужного информационного блока нет в системе или описание формата обмена данными не содержит информации о складских остатках? «Допилить» большие и, тем более, коммерческие CMS очень сложно.
И именно поэтому это очень дорого.
Модели интеграции:
Так как же можно «подружить» STU с веб-приложением? Чтобы ответить на этот вопрос, сначала рассмотрим возможные модели интеграции.
Западная модель
Обратимся к опыту наших западных коллег.Стоит отметить, что на западном рынке количество различных продуктов и решений гораздо больше, чем у нас, а предоставляемые возможности взаимодействия зачастую весьма фрагментированы.
Кроме того, многие системы требуют гораздо более сложной и глубокой интеграции, чем выгрузка товарных позиций из ERP-системы.
Для обеспечения гибкой и надежной интеграции в этих случаях применяется т. н.
Промежуточное программное обеспечение — промежуточный уровень, обеспечивающий обмен данными между разрозненными подсистемами, такими как электронная коммерция, ERP, веб-сервисы и т. д. Объединяя множество форматов и протоколов передачи данных, обеспечивая возможность преобразования одного формата в другой, промежуточное программное обеспечение также обеспечивает высокую степень надежность и гибкость интегрированной системы, поскольку изменение одного из ее компонентов повлечет лишь изменение правил взаимодействия с ней.
Иногда, говоря об интеграционном Middleware, вводят понятие интеграционной шины, обеспечивающей единый канал обмена данными для всех узлов системы, независимо от их происхождения и территориального расположения.
Типичная диаграмма взаимодействия выглядит следующим образом: 
Архитектура взаимодействия между Pervasive Data Integrator Middleware и приложениями.
Стрелками показаны направления передачи данных и протоколы, используемые для различных задач.
Перечислим самые популярные из них.
Технологии и протоколы веб-сервисов
- Протокол простого доступа к объектам (SOAP) является расширением XML-RPC и обеспечивает возможность обмена произвольными сообщениями в формате XML. Первоначально использовался для реализации удаленных вызовов процедур (RPC).
Позволяет веб-службе предоставлять повторно используемые компоненты.
Используется поверх текстовых протоколов, в основном HTML.
- Representational State Transfer (REST) — в этом случае данные передаются с использованием небольшого количества стандартных форматов — HTML, XML, JSON. Протокол сетевой передачи должен поддерживать кэширование и не должен хранить информацию о состоянии.
Обмен данными структурирован в форме запроса-ответа.
В некоторых случаях его можно использовать для передачи объектов SOAP.
- XML обычно используется для передачи сообщений и объектов.
Имеет иерархическую структуру и большую гибкость.
- Очереди сообщений — существует пул сообщений, они хранятся до тех пор, пока не будут обработаны.
- CommerceML — российский стандарт синхронизации с 1С:Бухгалтерия, активно продвигаемый 1С и другими мастодонтами, абсолютно глупый, поскольку не может быть международным и, как следствие, не поддерживается крупными ERP, однако заслуживает внимания за счет нативной реализации.
в 1С v8
Интернет и товарный учет в России
Но учитывая пока еще низкий уровень автоматизации бизнес-процессов, задача, с одной стороны, сужается, а с другой – усложняется.Во-первых, рынок веб-интеграции в России, по мнению экспертов, развит слабо, а значит, необходимого Middleware просто не существует. Западная продукция также зачастую нам не подходит из-за сложившейся в России традиции разработки, когда каждая компания стремится иметь свое решение.
Но с другой стороны, небольшое количество вендоров сужает круг возможных случаев и зачастую сводит задачу интеграции к необходимости интеграции системы товарного учета с интернет-витриной или интернет-магазином.
Взаимодействия веб-приложения и продуктовой системы мы разделили в зависимости от сложности решения на 3 уровня по направлениям обмена данными и наборам данных, передаваемых в обоих направлениях.
- Односторонняя передача товара из 1С и вывод его на веб-витрину сайта.
- Двусторонняя связь позиций и контрагентов от 1С с веб-витриной сайта и личным кабинетом
- Двусторонняя связь товаров, контрагентов и заказов из 1С с веб-витриной сайта и личным кабинетом
интерфейсный слой.
Этот слой позволяет загрузить необходимые для синхронизации данные в необходимом формате, соответствующем требованиям бизнес-логики.
При этом мы не используем раздутые XML-стандарты типа CommerceML, а адаптируем протоколы под нужды конкретной модели.
При проектировании взаимодействия между веб-приложением и технической спецификацией мы обычно тесно сотрудничаем со специалистами по этой конкретной технической спецификации.
Это позволяет нам получать данные в удобном для обработки формате и не ограничиваться встроенными возможностями экспорта данных STU. К STU подключается расширение (загрузка), предоставляющее данные для обработки на стороне веб-приложения.
В случае двустороннего обмена это расширение также берет на себя функции передачи данных на STU. Веб-приложение содержит тот же модуль, который анализирует и обновляет базу данных, а также запускает события, связанные с синхронизацией.
В случае двусторонней связи интерфейсный модуль веб-приложения отвечает за агрегирование и сериализацию экспортированных данных.
Хорошо, теперь STU и веб-приложение могут понимать друг друга.
Однако взаимодействие нужно как-то инициировать.
Сразу отметим вариант ручной инициализации.
Поскольку наша цель — максимально автоматизировать процесс взаимодействия, мы рассматриваем только методы автоматической инициации.
Ручной метод остается запасным вариантом в экстренных случаях, когда одна из служб выходит из строя.
Автоматический запуск синхронизации подразумевает, что при определенных четко определенных условиях одна сторона уровня интерфейса вызывает событие синхронизации, а другая сторона это событие обрабатывает. Сегодня мы используем два разных метода инициации синхронизации, в зависимости от доступных каналов передачи данных и технических возможностей STU.
- Загрузка в XML-файл и передача его по FTP
- Модель «инициатор-слушатель»
Веб-приложение периодически проверяет файлы, хранящиеся на сервере, на наличие обновлений и при обнаружении новой версии синхронизирует их.
Расширение интерфейса STU ведет себя аналогичным образом.
В модели инициатор-прослушиватель веб-приложение играет роль слушателя, а интерфейсный модуль STU отправляет запросы веб-приложению, в результате чего в веб-приложении инициируются действия по отправке или получению информации.
Данная модель не требует наличия какого-либо стороннего сервера, поскольку его функции выполняет веб-приложение, но требует наличия функций веб-клиента в интерфейсном модуле STU. Такие функции, например, имеются в 1С v8. Что касается разбора данных и обновления базы данных веб-приложения, то для каждого приложения такой модуль проектируется отдельно с учетом текущих и прогнозируемых потребностей бизнес-логики, а также требований к производительности и отказоустойчивости.
Спектр решений варьируется от простого синтаксического анализа XML и последующего последовательного ввода данных в таблицы до многопоточных транзакционных моделей с контролем целостности и триггерами на уровне модели.
В данном случае под моделью я подразумеваю уровень архитектуры MVC, используемый в проектах студии.
Кастомизация
Как видно из вышеизложенного, настройка интеграционного решения под бизнес-процессы заказчика начинается уже на этапе проектирования взаимодействия с СТУ.Однако это лишь малая часть.
Потребность в индивидуальном интеграционном решении становится более острой, когда речь идет о таких вещах, как:
- Интерактивность и тесные связи между компонентами пользовательского интерфейса как в серверной, так и в клиентской части.
Это особенно актуально для задач, выполняемых на стороне клиента и обменивающихся данными с сервером веб-приложений посредством запросов AJAX. Такие взаимодействия требуют большого количества различных представлений данных, которые сложно создать на основе коробочных решений.
- Представления данных, гибкие фильтры, настраиваемые форматы и контент для поиска.
- Возможности управления заказами не только от клиента, но и от оператора колл-центра.
При этом в последнем случае специфика работы требует настройки функциональности пользовательских интерфейсов оператора на максимальную производительность.
- Возможность введения простой иерархии и «псевдокатегорий».
Под псевдокатегориями мы понимаем те сущности, которые функционально соответствуют одному из разделов каталога, но не имеют отображения на сущность этого уровня в базе данных.
К псевдокатегориям относятся, например, «наши продукты» или «товары со скидкой».
- И многое другое.
У нас есть своя компонентная база, и мы можем делать все, что захотим.
Вот и все! "=" Теги: #dump-it #artsofte #конференция #1с #интернет-магазин 1с #1С-Битрикс #Разработка сайтов
-
Adobe Запрещает «Фотошопинг»
19 Oct, 24 -
Радио-Т №91
19 Oct, 24
