Проект Адаптер
Фактически, это перепост моей же новости с нашего сайта. Читать можно и там, и тут. Но тут наверное лучше, ибо можно вопросы задавать. Можно и не задавать. Когда, наконец, запустим отдельный блог VSV, тогда и отпадет необходимость в дублировании.
Ну, а назову материал как-нибудь по-научному... Скажем, использование принципа наследования при построении иерархических каталогов.
Адаптер - программный механизм, который обеспечивает синхронизацию сайта с внутренней учетной системой предприятия.
Это не из Википедии, это мы сами придумали.
Собственно, базовый функционал Адаптера был разработан нами еще в 2005 году.
Заказчик: НПК Контакт.
Задача формулировалась следующим образом. Есть учетная система предприятия (не 1С). Из нее нужно получить бизнес-данные, обработать их определенным образом, дополнить маркетинговыми данными и транслировать на сайт. Кроме того, нужно организовать и обратный процесс - трансляцию в учетную систему данных из внешнего мира (курсы валют, данные пользователей и т.д.).
К сказанному можно добавить, что структура каталога товаров для клиентов должна отличаться от структуры каталога в учетной системе. Что сайтов, на самом деле, не один, а, как минимум, три. Что рабочие места операторов могут быть удаленными. Что требования по безопасности - высокие. Что обработанные данные должны использоваться не только на сайте, но и для рассылок, для генерации xls-прайсов, для печати…
В общем-то, задачи вполне типовые, за исключением возни с меняющейся структурой и маркетинговыми данными. Под «маркетинговыми данными» здесь следует понимать не только описания товаров, групп товаров, картинки, но и набор технических характеристик товаров. А товаров много (несколько тысяч), они разнотипные и часто меняются. Основная проблема здесь в том, что характеристики принтера, монитора и, скажем, коммуникационной панели совершенно разные и не могут быть сведены к какому-либо типовому набору. Или даже к набору типовых наборов.
Лирическое отступление
Вот Битрикс, например, предлагает решать эту задачу «тупо и тотально»: либо создать «наборы типовых наборов» характеристик, либо единую матрицу всех возможных характеристик и показывать пользователю только те из них, которые заполнены. Ну, либо комбинировать эти варианты. Все это замечательно, но только тогда, когда у вас есть Идеальный Сервер, Идеальный Пользователь и Идеальный Оператор. Такое ощущение, что у Битрикса все они есть. Хорошо наверное Битриксу в такой компании, завидуем.
Задачу мы решили, используя принцип наследования. Для любого уровня иерархии каталога можно задать набор полей характеристик, каковой будет наследоваться всеми узлами по структуре. На более низком уровне структуры нельзя переопределить поля, заданные на более высоком уровне, но можно, при необходимости, подавить их вывод, и задать новые правила, которые, в свою очередь, будут наследоваться детьми узла. Ну, и надо ли говорить, что набор полей, их тип и правила отображения задаются операторами через веб-интерфейсы (с полным набором плюсов такого подхода - логирование всех действий пользователя, разграничение прав, удаленная работа).
Решение получилось компактным, красивым и даже универсальным. Вообще говоря, все равно, что мы имеем на входе - каталог товаров или структуру сотрудников компании - на выходе мы получим набор объектов с индивидуальным набором полей и правил.
На сегодняшний день нам не известна ни одна промышленная CMS, обладающая сопоставимой функциональностью.
В итоге мы получим вот такую вот красивую страничку. Обратите внимание: страница насквозь динамична, все эти ассоциированные ссылки, характеристики и описания полностью зависят от положения отображаемого объекта в иерархии каталога.
Со структурой проще. Мы просто поддерживаем два варианта структуры - родной и представление для клиента. Если бы надо было поддерживать 5, поддерживали бы 5, но пока и двух достаточно.
Вот. На самом деле, это была присказка. А сказка - это Адаптер версии 2.0, о завершении разработки которого мы, собственно, и рапортуем.
Список изменений:
Программирование: Константин Медведев
Руководство проектом: Сергей Василец.
Вот такая вот яркая, но недолгая сказка. Собственно, и все. Система протестирована, запущена, работает. Мы пошли за йогуртом.
Ну, а назову материал как-нибудь по-научному... Скажем, использование принципа наследования при построении иерархических каталогов.
Адаптер - программный механизм, который обеспечивает синхронизацию сайта с внутренней учетной системой предприятия.
Это не из Википедии, это мы сами придумали.
Собственно, базовый функционал Адаптера был разработан нами еще в 2005 году.
Заказчик: НПК Контакт.
Задача формулировалась следующим образом. Есть учетная система предприятия (не 1С). Из нее нужно получить бизнес-данные, обработать их определенным образом, дополнить маркетинговыми данными и транслировать на сайт. Кроме того, нужно организовать и обратный процесс - трансляцию в учетную систему данных из внешнего мира (курсы валют, данные пользователей и т.д.).
К сказанному можно добавить, что структура каталога товаров для клиентов должна отличаться от структуры каталога в учетной системе. Что сайтов, на самом деле, не один, а, как минимум, три. Что рабочие места операторов могут быть удаленными. Что требования по безопасности - высокие. Что обработанные данные должны использоваться не только на сайте, но и для рассылок, для генерации xls-прайсов, для печати…
В общем-то, задачи вполне типовые, за исключением возни с меняющейся структурой и маркетинговыми данными. Под «маркетинговыми данными» здесь следует понимать не только описания товаров, групп товаров, картинки, но и набор технических характеристик товаров. А товаров много (несколько тысяч), они разнотипные и часто меняются. Основная проблема здесь в том, что характеристики принтера, монитора и, скажем, коммуникационной панели совершенно разные и не могут быть сведены к какому-либо типовому набору. Или даже к набору типовых наборов.
Лирическое отступление
Вот Битрикс, например, предлагает решать эту задачу «тупо и тотально»: либо создать «наборы типовых наборов» характеристик, либо единую матрицу всех возможных характеристик и показывать пользователю только те из них, которые заполнены. Ну, либо комбинировать эти варианты. Все это замечательно, но только тогда, когда у вас есть Идеальный Сервер, Идеальный Пользователь и Идеальный Оператор. Такое ощущение, что у Битрикса все они есть. Хорошо наверное Битриксу в такой компании, завидуем.
Задачу мы решили, используя принцип наследования. Для любого уровня иерархии каталога можно задать набор полей характеристик, каковой будет наследоваться всеми узлами по структуре. На более низком уровне структуры нельзя переопределить поля, заданные на более высоком уровне, но можно, при необходимости, подавить их вывод, и задать новые правила, которые, в свою очередь, будут наследоваться детьми узла. Ну, и надо ли говорить, что набор полей, их тип и правила отображения задаются операторами через веб-интерфейсы (с полным набором плюсов такого подхода - логирование всех действий пользователя, разграничение прав, удаленная работа).
Решение получилось компактным, красивым и даже универсальным. Вообще говоря, все равно, что мы имеем на входе - каталог товаров или структуру сотрудников компании - на выходе мы получим набор объектов с индивидуальным набором полей и правил.
На сегодняшний день нам не известна ни одна промышленная CMS, обладающая сопоставимой функциональностью.
В итоге мы получим вот такую вот красивую страничку. Обратите внимание: страница насквозь динамична, все эти ассоциированные ссылки, характеристики и описания полностью зависят от положения отображаемого объекта в иерархии каталога.
Со структурой проще. Мы просто поддерживаем два варианта структуры - родной и представление для клиента. Если бы надо было поддерживать 5, поддерживали бы 5, но пока и двух достаточно.
Вот. На самом деле, это была присказка. А сказка - это Адаптер версии 2.0, о завершении разработки которого мы, собственно, и рапортуем.
Список изменений:
- Полностью переработанный программный интерфейс взаимодействия с учетной системой.
- Обновление данных в автоматическом режиме по заданному расписанию.
- Контроль ошибок. При возникновении потенциально опасной ситуации система отказывается от синхронизации и пишет паническое письмо администратору: «Шеф, все пропало! Гипс снимают! Клиент уезжает!»
- Система отчетов.
- Множество косметических правок.
Программирование: Константин Медведев
Руководство проектом: Сергей Василец.
Вот такая вот яркая, но недолгая сказка. Собственно, и все. Система протестирована, запущена, работает. Мы пошли за йогуртом.