30 мая мы выступили с рядом докладов в разных секциях конференции DUMP, которая прошла в Екатеринбурге. Изначально нас попросили затронуть холиварную тему «почему 1С-битрикс», говно :-), но мы решили ограничиться проблемами кастомизации коробок при создании площадок синхронизированных с системами товарного учета (далее СТУ)
Итак, вот о чем был доклад.
Artsofte чаще всего сталкивается с задачами интеграции интернет-магазина с 1С\Scala\SuperMAG и интернет-системами оплаты. Также мы внедряем системы слежения за статусом заказа, но не ограничиваемся ими. В пул интегрируемых решений могут также входить более сложные системы, такие как онлайн-банкинг на стороне заказчика, интеграция с биллинговыми системами и т.д…
Мы занимаемся исключительно кастомными разработками на Symfony(PHP) и .NET, и зачастую к нам обращаются клиенты, уже имеющие разного рода опыт.
Но что, если в качестве одного из звеньев используется альтернативное решение: CMS или кастомная система с одной стороны и альтернативное ПО товарного учета сдругой стороны?
В этом случае дела обстоят не так радужно. В случае, если система товарного учета или CMS не имеют инструментов синхронизации, либо эти инструменты несовместимы, необходима доработка одного или обоих звеньев, которая может обернуться для заказчика существенными затратами как по времени, так и по стоимости. Эти затраты могут даже превышать стоимость остальных работ, либо вынудить заказчика перейти на другое решение (имеется в виду решение для товарного учета или магазина)
Так или иначе, «доточенное» или взятое прямо «из коробки», такое решение, в конце концов исчерпает свои лимиты стандартного функционала. Коробка будет переполнена. Тупик.
Описанные выше сценарии, помимо проблем интеграции как таковой, могут иметь и «побочные эффекты» для заказчика.
Наше seo-подразделение занималось продвижением сайта detsad.ru, разработанного другой компанией. Данный сайт представляет собой несложный интернет-магазин с трехуровневой иерархией каталога и настроенной синхронизацией с 1С-Бухгалтерия, путем ручной прогрузки CSV файла через CMS.
Путь к странице каталога (в данном случае представлена ссылка с максимальным уровнем вложенности) выглядит так: www.detsad.ru/catalogue/200/3598, где последние два числа – номер категории и товара соответственно.
Проблема заключалась в том, что эти числа соответствуют идентификаторам в 1С, которые имели свойство меняться. В результате синхронизации старые ссылки на товары становились неверны и, как следствие, сайт терял позиции в поисковых системах. В результате мы переписали парсер.
Вот еще один пример. Допустим, мы с друзьями решили выпить пива. Мы любим Хугарден, и решили заказать ящик. Мы любим покупать в универсаме «Звездный», но ехать до него нам лень. Поэтому мы решили заказать пиво в Интернет-магазине «Звездный». Оказавшись на главной странице интернет-магазина, выбираем: «Пиво», «Сан Инбев», «СБ»,… что за хрень? Какой еще «Сан Инбев»?! Что за «СБ», «ЖБ», «ПБ»? Железобетонное что ли?
Я прямо представляю себе, как я захожу в магазин и смотрю на огромную вывеску: «Пиво». Заворачиваю в секцию «Сан инбев», ищу стеллаж «СБ», а на нем… Да ну нет, уже и пива расхотелось. Пойду лучше воды питьевой куплю. До нее не так глубоко.
В результате клиент понимает, что ему требуется новое решение, которое будет не только в полной мере учитывать бизнес-логику, но и совершенствоваться вместе с его бизнесом.
Основываясь на нашем опыте, мы можем с высокой степенью вероятности предположить, что в ходе интеграции СТУ и Web-фронтенда, разработчик просто копирует структуру каталога из СТУ.
Результат – низкая конверсия.
Когда мы начинаем проект кастомной интеграции, в большинстве случаев нам приходится сталкиваться с тем, что у компаний, как правило, нет разработанной и выполняемой ИТ-стратегии. Не описаны правила и политики разработки, внедрения, использования информационных систем, принципы и способы интеграции. Начиная работу над проектом, приходится разрабатывать эти документы с нуля, формализовать бизнес-процессы. Работа над такими проектами обычно начинается с формализации задачи, называемой нами «Моделью черных ящиков».
Схема этой модели такова:
На входе обычно имеется задание на разработку, содержащее требования заказчика в общем виде, а так же общие данные об используемых системах товарного учета (СТУ). Разрабатываемое Web-приложение и СТУ представляют собой черные ящики, внутреннее устройство которых если и известно, то как правило в самых общих чертах. Первым этапом работы над проектом является декомпозиция Web-приложения, позволяющая понять требования к его собственной архитектуре, и на основе этих требований выстроить логику взаимдействия с СТУ.
Но почему же сразу не начать внедрение с подробного анализа и не прийти сразу к кастомному решению?
В большинстве случаев ответ прост. Предлагая заказчику свои услуги компании по разному оценивают необходимый объем работ, и когда предложения отличаются по цене до 30-ти раз (реальный случай из нашей практики с B2B-магазином shop.nag.ru), предложения из нижнего ценового сегмента выглядят наиболее привлекательными для заказчика, но в то же время кроют в себе подвох.
Являясь одним из ключевых факторов, низкая стоимость внедрения системы вовсе не означает, что мы сэкономили, и при выборе решения мы должны производить оценку в более широком аспекте, например рассчитать стоимость владения интегрированным решением, а она включит в себя:
Последний пункт зачастую становится основой бюджета проекта.
Отсутствие в коммерческом предложении упоминания о стоимости сопровождения создает радужную картину для заказчика и Все дело в том, что действительно недорогим в плане внедрения будет коробочное решение.
Интернет-магазин на Битрикс или VirtueMart с шаблонным дизайном разворачивается за пару часов, не считая наполнения. После этого так же быстро настриваются выгрузки. Но что делать, если нужного информационного блока нет в системе или описание формата обмена данными не содержит информации об остатках на складах? «Допиливать» большие и, особенно, коммерческие CMS очень непросто. А потому и стоит это очень дорого.
Так как же все-таки «подружить» СТУ с Веб-приложением? Чтобы ответить на этот вопрос сначала рассмотрим возможные модели интеграции.
Обратимся к опыту наших западных коллег. Стоит отметить, что на западном рынке количество различных продуктов и решений куда более велико, чем у нас, а предоставляемые возможности взаимодействия зачастую весьма разрозненны. Кроме того, многие системы требуют куда более сложной и глубокой интеграции, чем выгрузка товарных позиций из ERP-системы. Для обеспечения гибкой и надежной интеграции в этих случаях применяется т.н. Middleware, промежуточный слой, обеспечивающий обмен данными между разрозненными подсистемами, такими как eCommerce, ERP, Web-службами и т.д. Объединяя многие форматы и протоколы передачи данных, предоставляя возможности преобразования одних форматов в другие, middleware также обеспечивает высокую степень надежности и гибкости интегрированной системы, поскольку изменение одного ее компонента повлечет за собой лишь изменение правил взаимодействия с ним. Иногда, говоря об интеграционном Middleware, вводят понятие интеграционной шины, предоставляющей единый канал обмена данными для всех узлов системы независимо от их происхождения и территориального расположения.
Типичная схема взаимодействия выглядит, как показано на схеме ниже:
Архитектура взаимодействия Pervasive Data Integrator Middleware с приложениями.
Стрелками показаны направления передачи данных и используемые протоколы для различных задач. Перечислим самые популярные из них.
Передача данных по этим протоколам обеспечивается как правило транспорты HTTP/S и FTP/S
Имея необходимый инструментарий, зачастую оказывается достаточным описать структуры данных и выбрать наиболее подходящий протокол обмена.
Но у нас в виду по прежнему невысокого уровня автоматизации бизнес-процессов задача с одной стороны сужается, а с другой стороны усложняется. Во-первых рынок Веб-интеграции в России по оценкам экспертов мало развит, а значит необходимого Middleware попросту нет. Западные же продукты нам тоже зачастую не подходят в связи со сложившейся в России традицией разработки, когда каждая компания стремится иметь собственное решение. Но с другой стороны небольшое количество вендоров сужает набор возможных кейсов и зачастую сводит задачу интеграции к необходимости интегрировать систему товарного учета с Интернет-витриной или Интернет-магазином. Мы поделили взаимодействия Web-приложения и товарной системы в зависимости от сложности решения, на 3 уровня по направлениям обмена данными и наборам данных, передаваемых в ту и другую стороны.
Подробнее о них здесь
Для обеспечения взаимодействий на всех трех уровнях мы используем т.н. интерфейсный слой. Этот слой позволяет выгрузить необходимые для синхронизации данные в необходимом формате, отвечающем требованиям бизнес-логики. При этом мы не используем раздутые XML-стандарты вроде CommerceML, а адаптируем протоколы под нужды конкретной модели.
При проектировании взаимодействий веб-приложения и СТУ мы как правило работаем в тесной связи со специалистами по данной СТУ.
Это позволяет нам получать данные в удобном для обработки формате и не ограничивать себя встроенными возможностями экспорта данных СТУ. К СТУ подключается расширение (выгрузка), предоставляющее данные для обработки на стороне Веб-приложения.
В случае двухстороннего обмена, это расширение также берет на себя функции передачи данных в СТУ. Веб-приложение содержит такой же модуль, выполняющий разбор и обновление БД, а так же инициирующий связанные с синхронизацией события.
В случае двухсторонней связи интерфейсный модуль Веб-приложения отвечает за аггрегацию и сериализацию экспортируемых данных. Ок, теперь СТУ и Веб-приложение могут понмать друг друга. Однако взаимодействия нужно как-то инициировать. Мы сразу отметем вариант ручной инициации. Поскольку наша задача — максимально автоматизировать процесс взаимодействия – мы рассматриваем только автоматические способы инициации.
Ручной же способ остается в качестве запасного варианта в экстренных случаях, когда один из сервисов дает сбой. Автоматическая инициация синхронизации подразумевает, что при некоторых вполне определенных условиях одна из сторон интерфейсного слоя возбуждает событие синхронизации, а вторая сторона обрабатывает это событие.
На сегодняшний день мы применяем два различных способа инициации синхронизации в зависимости от доступных каналов передачи данных и технических возможностей СТУ.
Выгрузка в XML-файл подразумевает, что данные сохраняются в виде файла формата XML в определенном месте на FTP-сервере. Веб-приложение периодически проверяет хранящиеся на сервере файлы на предмет обновлений и в случае обнаружения новой версии выполняет синхронизацию. Аналогичным образом ведет себя и интерфейсное расширение СТУ.
В модели инициатор-слушатель Веб-приложение выполняет роль слушателя, а интерфейсный модуль СТУ посылает запросы Веб-приложению, в результате которых в Веб-приложении инициируются действия по отправке или получению информации. Эта модель не требует наличия какого-либо стороннего сервера, так как его функции выполняет Веб-приложение, но требует наличие в интерфейсном модуле СТУ функций Веб-клиента. Такие функции, например, есть в 1C v8.
Что касается разбора данных и обновления БД Веб-приложения, то для каждого приложения такой модуль проектируется отдельно с учетом текущих и прогнозируемых потребностей бизнес-логики, а так же требований к производительности и отказоустойчивости. Спектр решений варьируется от простого разбора XML и последующего последовательного занесения данных в таблицы до многопоточных транзакционных моделей с контролем целостности и триггерами уровня модели. В данном случае под моделью я имею в виду уровень архитектуры MVC, применяемый в проектах студии.
Как видно из вышесказанного, кастомизация интеграционного решения под бизнес-процессы заказчика начинается уже на этапе проектирования взаимодействий с СТУ. Однако это лишь малая часть. Более остро необходимость кастомного интеграцинного решения начинает ощущаться, когда речь заходит о таких вещах как:
Разрабатывая кастомный продукт мы практически не ограничены в наших решениях, поскольку мы не накладываем на себя ни архитектурных рамок, ни инструментальных. У нас есть собственная компонентая база, и мы можем делать все, что угодно.
Ну и все! =)
Итак, вот о чем был доклад.
Artsofte чаще всего сталкивается с задачами интеграции интернет-магазина с 1С\Scala\SuperMAG и интернет-системами оплаты. Также мы внедряем системы слежения за статусом заказа, но не ограничиваемся ими. В пул интегрируемых решений могут также входить более сложные системы, такие как онлайн-банкинг на стороне заказчика, интеграция с биллинговыми системами и т.д…
Проблема
Мы занимаемся исключительно кастомными разработками на Symfony(PHP) и .NET, и зачастую к нам обращаются клиенты, уже имеющие разного рода опыт.
Приходя к клиентам, мы часто сталкиваемся с 3 вариантами безысходности.
- а) Клиент не имеет четко сформулированной задачи и задается вопросом: «А что, если попробовать?» В этом случае мы рекомендуем клиенту сначала поиграть с одной из коробочных версий, а там см. п.п.
- б) Клиент принимает решение о создании собственной разработки, обращается к решению нижнего ценового сегмента, и в итоге получает «велосипед». И, казалось бы, все хорошо, заказчик доволен. Он периодически выгружает товары на сайт, забивает в 1С заказы. Но через некоторое время оказывается, что колеса у велосипеда квадратные, сиденье не регулируется, а переключатель скоростей не предусмотрен в принципе. Оказавшись без поддержки создателя своей системы, клиент оказывается в тупиковом положении.
- в) Клиент выбрал «коробочное» решение. Так уж исторически сложилось, что несмотря на присутствие различных вендоров решений СТУ, таких как Oracle, Scala, СуперМаг и т.д., в подавляющем большинстве случаев под СТУ понимается комплекс 1С: Предприятие во всевозможных его конфигурациях. Поэтому когда заходит речь об интеграции Интернет-магазина с системой товарного учета или бухгалтерской системой, рассматриваются в первую очередь решения, предоставляющие возможности интеграции с 1С «из коробки». И вполне логично, что речь заходит в первую очередь о связке 1С-Предприятие и 1С-Битрикс. Это решение действительно достаточно простое для внедрения, и некоторое время дела обстоят значительно лучше, нежели в первом варианте. Веб-приложение будет развиватья вместе с требованиями бизнеса заказчика.
Но что, если в качестве одного из звеньев используется альтернативное решение: CMS или кастомная система с одной стороны и альтернативное ПО товарного учета сдругой стороны?
В этом случае дела обстоят не так радужно. В случае, если система товарного учета или CMS не имеют инструментов синхронизации, либо эти инструменты несовместимы, необходима доработка одного или обоих звеньев, которая может обернуться для заказчика существенными затратами как по времени, так и по стоимости. Эти затраты могут даже превышать стоимость остальных работ, либо вынудить заказчика перейти на другое решение (имеется в виду решение для товарного учета или магазина)
Так или иначе, «доточенное» или взятое прямо «из коробки», такое решение, в конце концов исчерпает свои лимиты стандартного функционала. Коробка будет переполнена. Тупик.
Описанные выше сценарии, помимо проблем интеграции как таковой, могут иметь и «побочные эффекты» для заказчика.
Пример проблем, вызванных кривой интеграцией:
1. Кейс «detsad.ru»
Наше seo-подразделение занималось продвижением сайта detsad.ru, разработанного другой компанией. Данный сайт представляет собой несложный интернет-магазин с трехуровневой иерархией каталога и настроенной синхронизацией с 1С-Бухгалтерия, путем ручной прогрузки CSV файла через CMS.
Путь к странице каталога (в данном случае представлена ссылка с максимальным уровнем вложенности) выглядит так: www.detsad.ru/catalogue/200/3598, где последние два числа – номер категории и товара соответственно.
Проблема заключалась в том, что эти числа соответствуют идентификаторам в 1С, которые имели свойство меняться. В результате синхронизации старые ссылки на товары становились неверны и, как следствие, сайт терял позиции в поисковых системах. В результате мы переписали парсер.
2. Кейс «Звездный»
Вот еще один пример. Допустим, мы с друзьями решили выпить пива. Мы любим Хугарден, и решили заказать ящик. Мы любим покупать в универсаме «Звездный», но ехать до него нам лень. Поэтому мы решили заказать пиво в Интернет-магазине «Звездный». Оказавшись на главной странице интернет-магазина, выбираем: «Пиво», «Сан Инбев», «СБ»,… что за хрень? Какой еще «Сан Инбев»?! Что за «СБ», «ЖБ», «ПБ»? Железобетонное что ли?
Я прямо представляю себе, как я захожу в магазин и смотрю на огромную вывеску: «Пиво». Заворачиваю в секцию «Сан инбев», ищу стеллаж «СБ», а на нем… Да ну нет, уже и пива расхотелось. Пойду лучше воды питьевой куплю. До нее не так глубоко.
В результате клиент понимает, что ему требуется новое решение, которое будет не только в полной мере учитывать бизнес-логику, но и совершенствоваться вместе с его бизнесом.
Основываясь на нашем опыте, мы можем с высокой степенью вероятности предположить, что в ходе интеграции СТУ и Web-фронтенда, разработчик просто копирует структуру каталога из СТУ.
Результат – низкая конверсия.
Когда мы начинаем проект кастомной интеграции, в большинстве случаев нам приходится сталкиваться с тем, что у компаний, как правило, нет разработанной и выполняемой ИТ-стратегии. Не описаны правила и политики разработки, внедрения, использования информационных систем, принципы и способы интеграции. Начиная работу над проектом, приходится разрабатывать эти документы с нуля, формализовать бизнес-процессы. Работа над такими проектами обычно начинается с формализации задачи, называемой нами «Моделью черных ящиков».
Схема этой модели такова:
На входе обычно имеется задание на разработку, содержащее требования заказчика в общем виде, а так же общие данные об используемых системах товарного учета (СТУ). Разрабатываемое Web-приложение и СТУ представляют собой черные ящики, внутреннее устройство которых если и известно, то как правило в самых общих чертах. Первым этапом работы над проектом является декомпозиция Web-приложения, позволяющая понять требования к его собственной архитектуре, и на основе этих требований выстроить логику взаимдействия с СТУ.
Но почему же сразу не начать внедрение с подробного анализа и не прийти сразу к кастомному решению?
В большинстве случаев ответ прост. Предлагая заказчику свои услуги компании по разному оценивают необходимый объем работ, и когда предложения отличаются по цене до 30-ти раз (реальный случай из нашей практики с B2B-магазином shop.nag.ru), предложения из нижнего ценового сегмента выглядят наиболее привлекательными для заказчика, но в то же время кроют в себе подвох.
Являясь одним из ключевых факторов, низкая стоимость внедрения системы вовсе не означает, что мы сэкономили, и при выборе решения мы должны производить оценку в более широком аспекте, например рассчитать стоимость владения интегрированным решением, а она включит в себя:
- Собственно, стоимость основных программных компонентов
- Стоимость внедрения программных компонентов, если требуется таковое
- Стоимость внедрения интеграционного решения
- Затраты на последующую кастомизацию интеграционного решения
Последний пункт зачастую становится основой бюджета проекта.
Отсутствие в коммерческом предложении упоминания о стоимости сопровождения создает радужную картину для заказчика и Все дело в том, что действительно недорогим в плане внедрения будет коробочное решение.
Интернет-магазин на Битрикс или VirtueMart с шаблонным дизайном разворачивается за пару часов, не считая наполнения. После этого так же быстро настриваются выгрузки. Но что делать, если нужного информационного блока нет в системе или описание формата обмена данными не содержит информации об остатках на складах? «Допиливать» большие и, особенно, коммерческие CMS очень непросто. А потому и стоит это очень дорого.
Модели интеграции:
Так как же все-таки «подружить» СТУ с Веб-приложением? Чтобы ответить на этот вопрос сначала рассмотрим возможные модели интеграции.
Западная модель
Обратимся к опыту наших западных коллег. Стоит отметить, что на западном рынке количество различных продуктов и решений куда более велико, чем у нас, а предоставляемые возможности взаимодействия зачастую весьма разрозненны. Кроме того, многие системы требуют куда более сложной и глубокой интеграции, чем выгрузка товарных позиций из ERP-системы. Для обеспечения гибкой и надежной интеграции в этих случаях применяется т.н. Middleware, промежуточный слой, обеспечивающий обмен данными между разрозненными подсистемами, такими как eCommerce, ERP, Web-службами и т.д. Объединяя многие форматы и протоколы передачи данных, предоставляя возможности преобразования одних форматов в другие, middleware также обеспечивает высокую степень надежности и гибкости интегрированной системы, поскольку изменение одного ее компонента повлечет за собой лишь изменение правил взаимодействия с ним. Иногда, говоря об интеграционном Middleware, вводят понятие интеграционной шины, предоставляющей единый канал обмена данными для всех узлов системы независимо от их происхождения и территориального расположения.
Типичная схема взаимодействия выглядит, как показано на схеме ниже:
Архитектура взаимодействия Pervasive Data Integrator Middleware с приложениями.
Стрелками показаны направления передачи данных и используемые протоколы для различных задач. Перечислим самые популярные из них.
Технологии и протоколы Web-служб
- Simple Object Access Protocol (SOAP) — представляет собой расширение XML-RPC и предоставляет возможность обмена произвольными сообщениями в формате XML. Изначально использовался для реализации удаленного вызова процедур (RPC). Позволяет Веб-службе предоставлять повторно используемые компоненты. Используется поверх текстовых протоколов, в основном HTML
- Representational State Transfer (REST) — в данном случае данные передаются с использованием небольшого количества стандартных форматов – HTML, XML, JSON. Сетевой протокол передачи должен поддерживать кеширование, не должен сохранять информацию о состоянии. Обмен данными строится в виде запрос-ответ. В некоторых случаях может приеняться для передачи SOAP-объектов
- XML- как правило используется для передачи сообщений и объектов. Обладает иерархической структурой и большой гибкостью
- Очереди сообщений — Есть пул сообщений, они хранятся до момента обработки.
- CommerceML — русский стандарт для синхронизации с 1С: Бухгалтерия, активно продвигаемый 1С и прочими мастодонтами, абсолютно тупой поскольку не может быть международным и, как следствие не поддерживается крупными ERP, однако, заслуживающий внимание ввиду нативной реализации в 1С v8
Передача данных по этим протоколам обеспечивается как правило транспорты HTTP/S и FTP/S
Имея необходимый инструментарий, зачастую оказывается достаточным описать структуры данных и выбрать наиболее подходящий протокол обмена.
Web и товарный учет в России
Но у нас в виду по прежнему невысокого уровня автоматизации бизнес-процессов задача с одной стороны сужается, а с другой стороны усложняется. Во-первых рынок Веб-интеграции в России по оценкам экспертов мало развит, а значит необходимого Middleware попросту нет. Западные же продукты нам тоже зачастую не подходят в связи со сложившейся в России традицией разработки, когда каждая компания стремится иметь собственное решение. Но с другой стороны небольшое количество вендоров сужает набор возможных кейсов и зачастую сводит задачу интеграции к необходимости интегрировать систему товарного учета с Интернет-витриной или Интернет-магазином. Мы поделили взаимодействия Web-приложения и товарной системы в зависимости от сложности решения, на 3 уровня по направлениям обмена данными и наборам данных, передаваемых в ту и другую стороны.
- Односторонняя связь номенклатуры из 1С и вывод ее на веб-витрину сайта
- Двухсторонняя связь номенклатуры и контрагентов из 1С с web-витриной сайта и личным кабинетом
- Двухсторонняя связь номенклатуры, контрагентов и заказов из 1С с web-витриной сайта и личным кабинетом
Подробнее о них здесь
Для обеспечения взаимодействий на всех трех уровнях мы используем т.н. интерфейсный слой. Этот слой позволяет выгрузить необходимые для синхронизации данные в необходимом формате, отвечающем требованиям бизнес-логики. При этом мы не используем раздутые XML-стандарты вроде CommerceML, а адаптируем протоколы под нужды конкретной модели.
При проектировании взаимодействий веб-приложения и СТУ мы как правило работаем в тесной связи со специалистами по данной СТУ.
Это позволяет нам получать данные в удобном для обработки формате и не ограничивать себя встроенными возможностями экспорта данных СТУ. К СТУ подключается расширение (выгрузка), предоставляющее данные для обработки на стороне Веб-приложения.
В случае двухстороннего обмена, это расширение также берет на себя функции передачи данных в СТУ. Веб-приложение содержит такой же модуль, выполняющий разбор и обновление БД, а так же инициирующий связанные с синхронизацией события.
В случае двухсторонней связи интерфейсный модуль Веб-приложения отвечает за аггрегацию и сериализацию экспортируемых данных. Ок, теперь СТУ и Веб-приложение могут понмать друг друга. Однако взаимодействия нужно как-то инициировать. Мы сразу отметем вариант ручной инициации. Поскольку наша задача — максимально автоматизировать процесс взаимодействия – мы рассматриваем только автоматические способы инициации.
Ручной же способ остается в качестве запасного варианта в экстренных случаях, когда один из сервисов дает сбой. Автоматическая инициация синхронизации подразумевает, что при некоторых вполне определенных условиях одна из сторон интерфейсного слоя возбуждает событие синхронизации, а вторая сторона обрабатывает это событие.
На сегодняшний день мы применяем два различных способа инициации синхронизации в зависимости от доступных каналов передачи данных и технических возможностей СТУ.
- Выгрузка в XML-файл, и его передача по протоколу FTP
- Модель «Инициатор-слушатель»
Выгрузка в XML-файл подразумевает, что данные сохраняются в виде файла формата XML в определенном месте на FTP-сервере. Веб-приложение периодически проверяет хранящиеся на сервере файлы на предмет обновлений и в случае обнаружения новой версии выполняет синхронизацию. Аналогичным образом ведет себя и интерфейсное расширение СТУ.
В модели инициатор-слушатель Веб-приложение выполняет роль слушателя, а интерфейсный модуль СТУ посылает запросы Веб-приложению, в результате которых в Веб-приложении инициируются действия по отправке или получению информации. Эта модель не требует наличия какого-либо стороннего сервера, так как его функции выполняет Веб-приложение, но требует наличие в интерфейсном модуле СТУ функций Веб-клиента. Такие функции, например, есть в 1C v8.
Что касается разбора данных и обновления БД Веб-приложения, то для каждого приложения такой модуль проектируется отдельно с учетом текущих и прогнозируемых потребностей бизнес-логики, а так же требований к производительности и отказоустойчивости. Спектр решений варьируется от простого разбора XML и последующего последовательного занесения данных в таблицы до многопоточных транзакционных моделей с контролем целостности и триггерами уровня модели. В данном случае под моделью я имею в виду уровень архитектуры MVC, применяемый в проектах студии.
Кастомизация
Как видно из вышесказанного, кастомизация интеграционного решения под бизнес-процессы заказчика начинается уже на этапе проектирования взаимодействий с СТУ. Однако это лишь малая часть. Более остро необходимость кастомного интеграцинного решения начинает ощущаться, когда речь заходит о таких вещах как:
- Интерактивность и тесные связи между компонентами интерфейса пользователя как в серверной, так и в клиентской части. Особенно это касается задач, выполняемых на стороне клиента и обменивающихся с сервером Веб-приложения посредством AJAX-запросов. Такие взаимодействия требуют получения большого количества различных представлений данных, которые трудно сформировать на основе коробочных решений.
- Представления данных, гибкие фильтры, гибко настраиваемые форматы и содержание выдачи поиска
- Возможности по управлению заказом со стороны не только клиента, но и оператора колл-центра. Причем в последнем случае специфика работы требует, чтобы функциональность пользовательских интерфейсов оператора была настроена на максимальную продуктивность.
- Возможности введения простой иерархии и «псевдокатегорий». Под псевдокатегориями мы подразумеваем такие сущности, которые функционально соответствуют одному из разделов каталога, однако не имеют сопоставления с сущностью этого уровня в БД. К псевдокатегориям можно отнести такие, как «наши товары» или «товары со скидкой»
- И много чего еще.
Разрабатывая кастомный продукт мы практически не ограничены в наших решениях, поскольку мы не накладываем на себя ни архитектурных рамок, ни инструментальных. У нас есть собственная компонентая база, и мы можем делать все, что угодно.
Ну и все! =)
