Веб интегратор – Веб-интеграция

Содержание

Что такое интернет-интеграция (Web Integration)?

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

В связи с этим возникают определенные проблемы, ключевыми из которых являются следующие:

  • Потребность в мануальном анализе баз данных различных решений и постоянном переключении между последними.
  • Сложность в предоставлении доступа к определенной информации партнерам, клиентам и сотрудникам.
  • Значимые затраты ресурсов на управление и обслуживание информационных систем.
  • Потребность в ручной синхронизации данных между оффлайн и онлайн системами.

Благо, в современном мире широкие потребности не остаются нерешенными, и проблемам бизнесов, описанным выше, также есть эффективное решение — web-интеграция.

Что такое интернет-интеграция

Web-интеграция — объединение разнородных веб-приложений и систем в единую среду на базе веб.

Иными словами, web-интеграция представляет собой синхронизированное функционирование сайта, склада, бухгалтерии и других специализированных программ. Речь идет о бизнес-взаимодействии корпоративных ресурсов или интернет-магазинов с локальными информационными системами и любыми торгово-учетными решениями, при котором изменения в одном звене общей системы влияют на другие.

Также следует заметить, что web-интеграция актуальна не только для синхронизации систем eCommerce-бизнесов, но и для вывода любых бизнес-процессов в онлайн.

Преимущества web-интеграции с точки зрения бизнеса

  • Простой контроль информации, представленной потребителям на различных точках взаимодействия.
  • Представление наиболее актуальных и точных данных на цифровых точках взаимодействия с ЦА,
  • Увеличение продаж за счет расширения возможностей отделов продаж и клиентской поддержки.
  • Значительное снижение расходов на ручную обработку данных и составление отчетов.
  • Снижение расходов на администрацию информационных систем и веб-сайтов.
  • Менеджмент и упрощение бизнес-процессов.
  • Экономия времени и ресурсов.

Технические преимущества интернет-интеграции

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

4 типа интеграции

1. На уровне представления. Позволяет взаимодействовать с удаленными решением, открывая доступ к их интерфейсам. Работа осуществляется через консоль терминала, платформозависимый или веб-базированный пользовательский интерфейс.

2. На уровне функциональности. Прямой доступ к бизнес-логике приложений, достигаемый непосредственным взаимодействием последних по API или посредством веб-сервисов.

3. На уровне данных. Доступ к базам данных удаленных программ и систем.

4. Комплексная интеграция. Все 3 типа интеграции в разном соотношении. Как правило, комплексная интеграция осуществляется при помощи специализированных коммерческих решений.

Чтобы понять эту концепцию лучше, разберем, как проходит интеграция интернет-магазина и в чем ее преимущества.

Интеграция с 1С

В качестве примера, рассмотрим интеграцию онлайн-магазина с системой «1С: Управление небольшой фирмой».

Что это дает?

  • Возможность создать и вести единую базу заказов, независимо от источников их поступления (с сайта, оформленные в торговой точке, при прямой связи с представителем компании и т. д.).
  • Отображение актуальной информации о наличии и стоимости товаров.
  • Удобный перенос данных между сайтом и учетной системой.

Информационная база интернет-магазина и «1С:Управление небольшой фирмой 8» работают независимо, а в указанный момент времени информация в системах синхронизируется — на сайт выгружается список товаров, а в учетную систему — заказы, оформленные в интернет-магазине.

Заказы, оформленные в интернет-магазине и перенесенные в 1С:УНФ, можно редактировать, изменять их статус при оплате, отгрузке или отмене. Эти изменения будут перенесены в интернет-магазин во время очередного сеанса связи.

Обмен информацией может происходить по расписанию или по решению пользователя. Периодичность обмена задается в настройках программы.

Однако следует заметить, что модель интеграции может быть изменена и проходить, например, по следующей схеме:

  1. Сайт и 1С работают независимо и обмениваются данными в формате CommerceML.
  2.  Сайт не имеет прямого доступа к 1С.
  3. 1С регулярно обращается к публичному скрипту на сайте, отдавая или принимая данные. Инициатором обмена и соединения всегда выступает 1С.

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

В системе Битрикс24, например, доступны модули для учета склада, управления некоторыми почтовыми сервисами, ведения бухгалтерии и многие другие приложения, требуемые для ведения бизнеса.

Напомним, что вы можете интегрировать Битрикс24 и LPgenerator для получения в CRM лидов, отправленных с целевых страниц.

Высоких вам конверсий!

Image source iptvt.com

08-05-2015

lpgenerator.ru

обязанности, плюсы и минусы, интересные факты

WEB-интегратор – это специалист, который осуществляет посредничество между командой дизайнеров и командой разработчиков при создании какого-либо web-проекта. Иногда еще веб-интегратора называют разработчиком пользовательских интерфейсов.

Веб-интегратор имеет дело с визуальными элементами и интеграцией HTML/CSS в:

  • веб-сайты;
  • веб-приложения;
  • мобильные приложения;
  • массовые рассылки;
  • электронные издания.

Хороший веб-интегратор также вносит свой вклад в улучшение эргономики сайтов и других веб-проектов, выполняет функции графического дизайнера и/или веб-разработчика. Web-интегратор чаще всего работает под руководством технического директора или проект-менеджера.  

WEB-интегратор должен, прежде всего, хорошо знать HTML и CSS, а также JavaScript. Для создания визуальной анимации web-интегратору понадобится умение работать с jQuery. Иногда такому специалисту нужны также навыки работы в Adobe Photoshop и даже Indesign и Illustrator. И, конечно, web-интегратору необходимо быть «на ты» с наиболее распространенными CMS, например WordPress, Drupal, SPIP, Joomla и др.

Где учиться на веб-интегратора? Специальности web-интегратор в российских вузах пока не существует. Базовые навыки и знания можно получить на хороших программах по IT-технологиям или программированию в инженерных вузах (например, МГТУ им. Баумана, факультете ВМК в МГУ им. Ломоносова, МФТИ, МИФИ, МЭСИ и др.). Получить недостающие знания можно на дополнительных курсах, которые есть во множестве в тех же самых вузах и в других центрах обучения. В целом же даже опытный web-интегратор должен постоянно пополнять багаж знаний, регулярно проходя курсы повышения квалификации – в этой сфере знания и технологии меняются очень быстро.

Другие профессии из данной тематической группы

www.examen.ru

Интеграция Web-приложений с системами товарного учета – текст доклада с конференции DUMP-IT.RU

30 мая мы выступили с рядом докладов в разных секциях конференции DUMP, которая прошла в Екатеринбурге. Изначально нас попросили затронуть холиварную тему «почему 1С-битрикс», говно :-), но мы решили ограничиться проблемами кастомизации коробок при создании площадок синхронизированных с системами товарного учета (далее СТУ)

Итак, вот о чем был доклад.

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-запросов. Такие взаимодействия требуют получения большого количества различных представлений данных, которые трудно сформировать на основе коробочных решений.
  • Представления данных, гибкие фильтры, гибко настраиваемые форматы и содержание выдачи поиска
  • Возможности по управлению заказом со стороны не только клиента, но и оператора колл-центра. Причем в последнем случае специфика работы требует, чтобы функциональность пользовательских интерфейсов оператора была настроена на максимальную продуктивность.
  • Возможности введения простой иерархии и «псевдокатегорий». Под псевдокатегориями мы подразумеваем такие сущности, которые функционально соответствуют одному из разделов каталога, однако не имеют сопоставления с сущностью этого уровня в БД. К псевдокатегориям можно отнести такие, как «наши товары» или «товары со скидкой»
  • И много чего еще.

Разрабатывая кастомный продукт мы практически не ограничены в наших решениях, поскольку мы не накладываем на себя ни архитектурных рамок, ни инструментальных. У нас есть собственная компонентая база, и мы можем делать все, что угодно.

Ну и все! =)

habr.com

интеграция - это... Что такое Веб-интеграция?

Развитие Интернет сделало веб-браузеры доминирующим ПО для доступа к содержанию, приложениям и системам по всему миру. В компаниях уже сложилась тенденция предоставлять своим сотрудникам, партнерам и клиентам доступ ко всем типам информации и сервисов посредством веб. Однако в корпоративных сетях компаний функционирует огромное число разнородных бизнес-приложений, созданных в различное время, различными организациями, на базе различных технологий. Задача веб-интеграции объединить разнородные веб-приложения и системы в единую среду на базе веб.

Типы интеграции

  • Интеграция на уровне представления. Уровень представления — веб-базированный пользовательский интерфейс, платформозависимый графический пользовательский интерфейс (GUI) или консоль терминала. Данный уровень позволяет пользователю взаимодействовать с приложением. Интеграция на уровне представления даёт доступ к пользовательскому интерфейсу удаленных приложений.
  • Интеграция на уровне функциональности. Данная интеграция подразумевает обеспечение прямого доступа к бизнес-логике приложений. Это достигается непосредственным взаимодействием приложений с API (программному интерфейсу приложений) или же взаимодействием посредством веб-сервисов.
  • Интеграция на уровне данных. В данном случае предполагается доступ к одной или нескольким базам данных, используемых удаленным приложением.
  • Комплексная интеграция. Коммерческие решения по веб-интеграции, как правило, включают все три типа интеграции.


Преимущества веб-интеграции

  • Веб-интеграция позволяет развертывать информационные системы на базе сторонних приложений без необходимости разбираться в их родительских системах, программных средах и архитектурах баз данных.
  • SOA и веб-сервисы используют программный язык и платформонезависимые интерфейсы между приложениями корпоративной инфраструктуры ИТ. Это дает очевидные преимущества в поддержке, управляемости, развертывании информационных сетей.
  • Веб-интеграция позволяет конструировать комплексную функциональность, комбинируя разнородные компоненты посредством протоколов веб-сервисов.
  • Веб-интеграция позволяет использовать веб-сервисы разработчиков.
  • Веб-интеграция позволяет развивать программные интерфейсы приложений через протоколы веб-сервисов без программирования.


Для веб-интеграции используется коммерческое ПО или популярные технологии, такие как PHP/Python/Perl, XForms, SOAP и т. д.

Коммерческое ПО для веб-интеграции

Связанные технологии

Примеры

Пример веб-интеграции предприятия масштаба АВТОВАЗ посредством набора технологий PHP/SOAP/xForms

Статьи

ноябрь 2009 Статья в CIO-World.ru — «Тернистые пути отечественной веб-интеграции»

dic.academic.ru

Страшное слово «Веб-интеграция» » Корпоративный блог Центра Высоких Технологий

В период молниеносного развития Веба, и возрастания его роли в становлении не только онлайнового бизнеса, но и оффлайнового, всё острее встает вопрос определения термина «Веб-интеграции». На данный момент в Википедии нет конкретного определения, а говорится лишь о задаче перед Веб-интеграцией:

«Развитие Интернет сделало веб-браузеры доминирующим ПО для доступа к содержанию, приложениям и системам по всему миру. В компаниях уже сложилась тенденция предоставлять своим сотрудникам, партнерам и клиентам доступ ко всем типам информации и сервисов посредством веб. Однако в корпоративных сетях компаний функционирует огромное число разнородных бизнес-приложений, созданных в различное время, различными организациями, на базе различных технологий. Задача веб-интеграции объединить разнородные веб-приложения и системы в единую среду на базе веб».

Так кто же такие Веб-интеграторы?

В 2007 г. Веб-интеграторы рассматривались в противовес системным интеграторам:

«Да, web-интеграторы открыто противопоставляют себя классическим системным интеграторам. И, прежде всего — основываясь на «приоритетах внедрения». Так, в «Город-Инфо» утверждают: системные интеграторы чаще всего занимаются внедрением отдельных модулей информационных систем, что, по сути, лишь усугубляет проблему «островов информатизации».

Камнем преткновения в этом моменте было решение вопросов автоматизации внутренних бизнес-процессов и хранения данных компаний по средством веба. Это было продиктовано временем и пониманием того, что Интернет — средство облегчения коммуникации между участниками бизнес-процесса.
Однако, не всё так очевидно, тут стоит дополнить, что Веб выступает ещё и тем самым мостиком между компанией и её клиентами. Возможно, на этом моменте не заостряли так внимание, потому что в 2007 году аудитория Интернета не была столь велика, но с появлением социальных сетей и мобильного Интернета — население буквально хлынула на освоение Интернет-пространства. Теперь он стал интересен не только искушенным пользователям.
По данным Фонда «Общественное мнение» к концу 2010 года только в России количество пользователей составляет 46,5 млн. чел., а ведь ещё весной 2007 года эта цифра составляла 28,7 млн. чел.

Подобные изменения в Интернет-пространстве несут и пересмотр понимания термина «Веб-интегратор», но не в корне, а просто дополняют.

На данный момент на рынке ИТ-компаний Веб-интегратрами в большей степени себя называют организации, которые предлагают конкретный продукт для реализации бизнес-задач с готовыми модульными решениями, которые можно трансформировать в зависимости от потребностей клиента. Веб-интеграторами себя позиционирую такие компании, как: NetCat, 1C-Битрикс, АИСТ и др.
Но все чаще встречаются совершенно уникальные проекты, требующие незаурядных решений, не предусмотренных в комплекте любого из продаваемых продуктов Веб-интегрирования. И тут стоит заметить, что Бизнес-задачи проекта не ограничиваются применением лишь только программных продуктов, а также требуют и другие технологии. Здесь же можно рассмотреть наравне с разработкой веб-приложений и проведение интернет-маркетинговых акций. Потому что они также интегрируют компанию в Digital-среду. Веб-интегрирование не ограничивается лишь эффективным использованием корпоративной информационной системы для автоматизации внутренних процессов, но также и отвечает за успешную коммуникацию компании с клиентами, с их целевой аудиторией.
«В практическом смысле можно считать, что web-интеграция представляет собой еще и совокупность действий, усилий, направленных на миграцию компаний — потребителей этих услуг в направлении электронного бизнеса. А это означает разработку и внедрение механизмов, принципов и методов электронного бизнеса. В некоторой степени web-интеграция способна привнести в деятельность организации-заказчика новые стандарты информационного обмена, хранения и использования информации на основе web-технологий».
Тут стоит заметить, что помимо готовых Интернет-решений, которые на данный момент предлагают компании Веб-интеграторы, есть место и заказным разработкам под более нестандартные задачи. Иными словами:

Веб-интеграторы — это ещё и компании специалистов, которые занимаются разработкой заказных Интернет-решений под бизнес-задачи клиента с использованием необходимых веб-инструментов.

Сюда можно отнести:

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

При подготовке поста были также использованы материалы статьи 2007 г.

blog.htc-cs.ru

из маленькой веб-студии в опытного интегратора — Блог Студии Валерия Комягина

Мы быстро поняли, делать простые сайты — невыгодно. Конкуренция возрастала, рынок наводнялся небольшими компаниями. Всё это привело к снижению цен на проекты и падению прибыльности бизнеса. Заказчики становились квалифицированнее. Запросы на создание сайтов дополнялись требованиями «привязать» их к той или иной информационной системе.

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

Наша Студия всегда располагалась в российской «силиконовой долине» — Зеленограде. У нас были сильные программисты, а значит мы могли легко получать и выполнять такие заказы. Было решёно — это наш шанс!

Так мы превратились из обычной студии в специалистов, обеспечивающих слаженную работу сайта с несколькими информационными системами — веб-интеграторов.

Какая гадость эта ваша веб-интеграция

Обеспечить обмен данными между двумя системами несложно. Но наши первые несколько лет работы в новом качестве были болезненными и обошлись недёшево.

Вместо ожидаемых прибылей мы раз за разом теряли деньги, натыкаясь на всё новые сложности, которым наш технический директор дал кодовое названием «подводные камни».

Мы не сдавались, и, словно мышки из анекдота, «кололись, плакали, но упорно продолжали грызть кактус».

В результате Студия превратилась в одну из лучших инженерных команд России, и готова поделиться наработками, которые позволяют нам экономить время, деньги и нервы. Себе и заказчику.

Перед тем как приступить

Прежде чем рассказать о процессах, договоримся о терминологии этой статьи.

Для нас, программистов, любая разработка несложных сайтов сводится к такой модели:

Когда нужно создать не просто веб-сайт, а целую систему, где помимо БД сайта задействованы ещё и кассовый аппарат с кассиром, продающим билеты в театр, складская система, предоставляющая сведения об остатках товаров, или платёжный сервис, отвечающий за процессинг банковских карт, мы используем понятие «третья сторона».

Третья сторона — это информационная система, находящаяся за пределами серверной или дата-центра, призванная подключить к нашей бизнес-логике дополнительные ресурсы. Например, SMS-сервис, отправляющий короткие сообщения на телефон пользователя или система резервирования товара на складе поставщика. С появлением третьей стороны процесс усложняется, и мы применяем этот алгоритм для экономии времени и денег при работе над интегрированным проектом.

Шаг 1. Цели и задачи

Первым делом нужно на простом языке договориться о том, что мы хотим в конце концов получить. Заказчик ожидает от интеграции конкретный результат. Автоматизация ради красоты системы редко кого интересует. Попытка сформулировать цели и ожидания письменно — лучший способ убедиться, что результаты одинаково понимаются всеми участниками рабочего процесса. Мы часто сталкиваемся с такой формулировкой:

Типичный пример: Сайт должен быть интегрирован с билетной системой ProfTicket.

и стараемся в таких случаях добиться большей однозначности формулировки:

Хороший пример: Покупатели должны иметь возможность выбрать свободные места в зале, оплатить билеты и получить их по электронной почте в офисах продаж или с помощью курьерской доставки. Информация о наличии мест для продажи на конкретные сеансы предоставляется билетной системой ProfTicket.

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

Шаг 2. Бизнес-процессы и протокол взаимодействия

Теперь нужно решить, как системы должны взаимодействовать для выполнения той или иной задачи. Продолжим строить аналогии с билетной системой. Кстати, речь идет о совершенно реальном проекте: в 2013 году мы помогли компании «Дилявер» открыть сервис заказа билетов ShowMart.Ru. Для выполнения бронирования билета необходимо ответить на несколько вопросов:

  • Какое мероприятие выбрал покупатель?
  • Какой сеанс (сочетание даты и времени) был выбран?
  • Какие места (номер сектора, ряд и кресла) были выбраны?
  • Не были ли проданы эти места другому покупателю ранее?
  • Не находятся ли данные места в резерве, иными словами, не происходит ли оформление покупки этих мест другим покупателем прямо сейчас?
  • И так далее...

Любое взаимодействие между системами сводится к структуре «запрос — ответ». Запрос отправляет сторона, которой необходимо получить данные (клиент), а ответ — сторона, у которой эти данные есть (сервер).

Чем проще и однозначнее будет такая схема, тем лучше. Как минимум, необходимо убедиться в том, что на один запрос отвечает только одна из систем и системы не дублируют друг друга. Например, информация о цене на билеты хранится только в одной из них.

В какой-то момент нам нужно будет «попросить» одну из систем зарезервировать билеты — проставить отметку, не позволяющую продать эти билеты повторно другому покупателю, а после оформления покупки одна из систем должна будет отправить покупателю письмо-уведомление. Поэтому иногда требуется взаимодействие не на уровне «запрос — ответ», а по формуле «запрос — действие».

Процесс взаимодействия сторонТеперь нам остаётся только зафиксировать, за какие запросы и ответы ответственна каждая из систем. А также указать перечь всех возможных ошибок.

Шаг 3. Регламент принятия решений и медиаторы

Даже в самом простом проекте веб-интеграции принимают участие как минимум три стороны:

  1. Заказчик.
  2. Владелец системы А (например, 1С-программист в штате клиента).
  3. Владелец системы Б (собственно, мы — веб-программисты).

Не будем углубляться в причины и анализ происходящего. Просто зафиксируем как факт: возникновение конфликтов интересов между владельцами двух систем неизбежны. Сложность ситуации зависит от числа участников и уровня их квалификации.

Важно подумать о том, как будут разрешаться спорные ситуации до того, как они появятся. Это непростая тема, но необходимо договориться хотя бы о фундаментальных моментах, например:

  • Чем стороны будут руководствоваться при принятии решения: быстродействием, вопросами безопасности данных или минимальными изменениями в 1С?
  • Кто будет ответственной стороной, принимающей последнее решение, в том случае, если владельцы систем не могут договориться между собой?

На первый взгляд кажется, что ответ на последний вопрос очевиден: заказчик — кому же еще принимать окончательные решения? Однако, это не всегда так.

Интеграционные проекты предъявляют высокие требования к техническим знаниям ответственного за решения. Поэтому иногда пальма первенства отдается одному из участников интеграционного процесса, или привлекается независимый эксперт, чей авторитет признается владельцами обеих систем.

Шаг 4. Стандарт и формат обмена данными

Теперь необходимо договориться о том, на основе какого стандарта и каким способом мы будем осуществлять обмен данными между системами.

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

SOAP

SOAP расшифровывается, как Simple Object Access Protocol. Если дословно переводить с английского, то получится «Простой Протокол Доступа к Объектам». Этот протокол действительно является одним из самых простых и часто используемых при построении веб-проектов. SOAP представляет собой протокол обмена структурированными XML-сообщениями.

Пример SOAP-запроса

Для того чтобы системы использовали единый регламент построения запросов и ответов, используются файлы c описанием такого регламента, составленным на основе стандарта WSDL (от англ. Web Service Description Language — Язык Описания Веб-Сервисов).

SOAP является расширением протокола XML-RPC, и это большой плюс протокола. XML широко распространен, и с форматом XML-Schema хотя бы поверхностно знакомо огромное число специалистов.

Этот же факт является и самым большим минусом SOAP. XML — объёмный формат и с ростом количества данных, которыми обмениваются системы, растет количество передаваемого трафика. С ростом последнего увеличивается время, необходимое на обработку запросов и формирование ответов на них. Всё это делает связку WSDL/SOAP практически непригодной для использования в системах с огромными объёмами плохо структурированных данных — в так называемых Big Data-системах.

SOAP станет отличным выбором, например, для решения задач интеграции интернет-магазина с небольшим ассортиментом со складской системой 1С. В её стандартной поставке предусмотрена поддержка этого протокола, и всё, что останется сделать, подготовить WSDL-описания.

REST

REST (расшифровка аббревиатуры в данном случае нам ничего не даст, поэтому мы ей пренебрежем) — это протокол вызова удаленной процедуры с помощью обычного HTTP-запроса. Да-да, с помощью тех самых методов GET и POST из учебников Тима О’Райли.

За каждый метод в REST отвечает не отдельно взятая запись в файле WSDL, а URL. К примеру, метод для получения сведений о пользователе будет иметь вид — http://example.com/rest/user. А метод создания нового пользователя — http://example.com/rest/user/create.

Для передачи параметров в REST можно использовать тело запроса, а для описания ошибок — статусные заголовки HTTP. Всё максимально просто и не требует использования дополнительных протоколов. REST гораздо примитивнее SOAP. Именно это делает его отличным выбором, когда нужно обмениваться большим объёмом данных и делать это часто.

REST не диктует, в каком формате передавать запросы. А значит для этих целей можно использовать JSON (текстовый формат обмена данными) — самый компактный формат обмена структур в текстовом представлении. Его использование практически полностью решает проблему объёма данных.

ВЕЛОСИПЕД

Иногда приходится использовать комбинации нескольких методов и протоколов взаимодействия.

В 1С есть собственный формат CommerceML — XML для передачи коммерческой информации, чаще всего таким способом передаются каталоги товаров.

Этот формат разработан специалистами фирм 1С и Extra.RU. Им помогали друзья из московского офиса Microsoft.

По этой причине формат не предусматривает многих вариантов использования, и «чистого» CommerceML часто не хватает. Это приводит к необходимости дополнения его специальным функционалом.

Иногда у клиента нет выделенного внешнего сервера для взаимодействия. Тогда мы заводим отдельную папку прямо на сервере хостинга для того, чтобы 1С выгружала туда свои файлы. Там они распознаются нашими скриптами по расписанию.

В случаях когда нужно постоянно поддерживать данные в актуальном состоянии, мы можем связать Rest API и передачу XML вместе. Тогда 1С будет отправлять XML напрямую на сервер, используя стандартные POST-запросы.

Шаг 5. Безопасность данных

Чаще всего там, где возникает необходимость в интеграции, есть объекты коммерческой тайны или персональные данные. Работа с ними после недавних изменений в законодательстве теперь заслуживает отдельной статьи.

Никто не хочет, чтобы клиентская база или сведения о дневной выручке «утекли» к конкурентам. Поэтому важно подумать об обеспечении достаточного уровня безопасности данных, которыми обмениваются системы.

Вариантов защиты много. Мы рассмотрим только некоторые из них.

HTTPS

Протокол HTTP — самый распространенный и самый незащищенный. Данные по нему передаются в незашифрованном виде. HTTPS — это разновидность http-протокола, поддерживающая шифрование с использованием сертификатов SSL или TCL.

Сертификаты — это алгоритм, по которому будет происходить шифрование данных. Об этом алгоритме знают только передающая и принимающая стороны в момент передачи данных. SSL-сертификаты могут поставляться самим сервером, но тогда они будут считаться недоверенными, и браузеры могут выдавать пугающие пользователя картинки.

Окно предупреждения пользователя о недостоверном соединенииДля того чтобы сертификат считался доверенным, его необходимо заказывать у организации, занимающейся сертификацией — центра сертификации. Таких учреждений много. Работая над проектами европейских заказчиков, мы предпочитаем пользоваться услугами одного из двух крупнейших игроков на рынке SSL-сертификации — Thawte или Verisign. В России работаем с Ру-центром. Их значки можно часто видеть на сайтах, где подразумевается оплата или работа с персональными данными.

HTTP-Basic авторизация

Вторым методом обеспечения защиты является способ, при котором две системы «представляются» друг другу с помощью пары «логин — пароль» до того, как начать обмениваться данными. Такой метод называется «HTTP-basic авторизация».

Чтобы злоумышленники не смогли перехватить пароли, «представляться» системам лучше в шифрованном виде, т.е. HTTP-basic авторизацию надо использовать совместно с SSL-шифрованием.

Предоставление доступа по IP-адресу

Если система не слишком сложна и у серверов взаимодействующих систем есть определенные и неизменные IP-адреса, можно предоставлять доступ к обмену данными только для этих IP-адресов.

Этот вариант прост в реализации и поэтому широко распространен. Но иногда он приводит к внезапным проблемам с доступом.

Шаг 6. Техническое задание

У вас могут быть превосходные отношения с заказчиком или его 1С-программистами, но «дружба дружбой, а табачок врозь». Мы настоятельно рекомендуем зафиксировать договоренности по всем описанным шагам письменно.

Поучительный пример из собственного опыта: Нам предстояло сделать сложную интеграцию «1С:Предприятия» заказчика с используемым интернет-магазином. На встрече с 1С-программистами мы договорились о том, что они подготовят веб-сервисы на своей стороне, к которым веб-программисты Студии будут впоследствии обращаться.

В процессе практической тесной работы, которая заняла не один месяц, 1С-программисты изменили свою точку зрения и приняли решения сделать для нас копию своей БД, реплицированную с главной и передать ее нам для того, чтобы мы «делали с ней все, что захотим».

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

В приведённом примере нам повезло — 1С-программисты оказались ребятами порядочными и подтвердили перед своим руководством нашу правоту. Но повезет ли так же в следующий раз?

Вы можете работать по гибким методологиям, использовать классический «водопад» или применять гибридную методику. Это не важно, также как и формат и объем ТЗ. Важно только то, что все договоренности должны быть так или иначе зафиксированы.

Шаг 7. Реализация

В непосредственном производстве работ по интеграции тоже есть несколько отличий от моноразработки.

ЕДИНАЯ КОМАНДА

Чтобы разработка шла как можно более гладко, избегайте деления на «ваших» и «наших». Наоборот, сделайте всё для формирования единой команды из разработчиков внешней информационной системы и ваших программистов.

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

Кроме этого, на устранение разницы в квалификации специалистов и используемых методологий разработки потребуется дополнительное время. Это тоже стоит учесть при расчете времени и бюджета проекта.

ТЕСТИРОВАНИЕ НА ВХОДЕ

Работая с третьей стороной, придется заниматься тестированием не только «на выходе», но и «на входе».

Пример из собственной практики: программист CRM-системы отчитался, что веб-сервис, необходимый для выполнения работы завершен. Руководитель проекта сформировал задачу веб-программисту и выставил ее, сопроводив ссылкой на этот веб-сервис. На следующий день веб-программист в точном соответствии с графиком приступил к выполнению задачи и столкнулся с тем, что веб-сервис не работает. Задача возвращается CRM-программисту. Время веб-программиста, руководителя проекта и деньги заказчика потрачены впустую. Все снова ждут готовности нужного веб-сервиса.

Раньше всё зависело только от вашей команды, и сформулированная задача сразу выставлялась программисту. Теперь же придётся сначала убедиться в том, что компоненты для решения задачи, выполненные третьей стороной, действительно работают.

ПОКРЫТИЕ ТЕСТАМИ

Требования будут меняться со скоростью света, владельцы внешней информационной системы могут изменить веб-сервисы и API без предупреждений. Сменится состав ваших собственных веб-программистов, или может случиться так, что, написав новый функционал, разработчики своими действиями, сломают то, что до этого замечательно работало. Одно лечим, другое калечим.

Чем быстрее обнаружится, в каком месте системы и что именно «полетело», тем меньшими будут затраты на её поддержку, и тем выше будет прибыль. Поэтому не экономьте на покрытии кода тестами.

В случае веб-интеграции процент покрытия кода тестами должен быть как можно более высоким.

Шаг 8. Отказоустойчивость

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

Некоторые из проектов, выполненных нами, могут потерять от $35 000 до $70 000 в случае суточного простоя. Это заставляет дополнительно задумываться о мероприятиях повышения отказоустойчивости всей системы.

  • Резервное копирование. Все это прописывают в ТЗ и договорах. Но давайте будем честны, вы всегда проверяете, действительно ли хостер или разработчик настроил процедуры резервного копирования в соответствии с договоренностями? Чаще всего это выясняется тогда, когда беда уже произошла.
  • Нагрузочное тестирование. На какую посещаемость и пиковую нагрузку рассчитывает заказчик? Умножьте эту цифру хотя бы на 2,5 и сделайте синтетические нагрузочные тесты. Тестировать нужно не только сайт, но и те системы, с которыми взаимодействует проект.
  • Сезонность. Знайте сезонность бизнеса своего заказчика. Посещаемость сайта сети кинотеатров, который мы сделали и поддерживаем, в новогодние праздники возрастает в 2-3 раза. В этом проекте мы начинаем подготовку к Новому году в начале ноября.
  • Готовность к «откату». Вы работаете в команде, и это придется учитывать. Будьте готовы к тому, что ваши новые функции могут нарушить нормальную работу внешней системы и изменения придется быстро «откатить» назад. Несмотря на нагрузочное тестирование, внешние системы иногда выходят из строя по независящим от вас причинам. Вы должны быть готовы продолжить работу, отключив на время совместный функционал. Например, во время аварии сервиса покупки билетов вместо процесса оформления заказа мы показываем сообщение с извинениями, но сам сайт продолжает свою работу.

Шаг 9. Логирование и мониторинг

Не забудьте учесть в сроках и бюджете проекта затраты на создание системы логирования. Мы довольно долго набивали шишки в этом месте.

Это объективный инструмент, с помощью которого можно будет восстановить хронологию событий, поможет не только сохранить нервы, но и защитит в случае судебных разбирательств. Поэтому готовую систему важно «обвешать» индикаторами и датчиками.

В Студии мы стараемся сделать всё так, чтобы о выходе из строя сайта или его части узнавать не из телефонного разговора с разъярённым клиентом, а при помощи собственных систем мониторинга.

Мы не станем подробно затрагивать этот процесс и, может быть, посвятим этому отдельную статью, но для тех, кто плохо знаком с этими темами, советуем начать с гугления терминов Pinba, Zabbix и Munin.

Шаг 10. Документирование

Договоритесь о том, в каком виде будет вестись проектная документация, и постарайтесь держать её в актуальном состоянии.

Это поможет избежать ситуаций, когда для устранения неполадок приходится знакомиться со всем программным кодом. Если даже программист, изначально разработавший всё это, через полгода уже не вспомнит, что и как должно работать, стоит ли говорить о новых разработчиках?

Совет самый простой по смыслу и самый сложный по соблюдению. Мы в Студии стараемся это делать примерно так:

  • Договорились о формате ведения и месте хранения проектной документации.
  • Составили перечень документов, входящих в понятие «проектная документация». Как правило это несколько документов, включая карту бизнес-процессов, описание серверной архитектуры, наше ТЗ, документация на API внешней системы, и т.д.
  • Назначили ответственного за актуальность документации. Обычно это руководитель проекта.
  • Назначили периодичность проверки документации.

Всё! Теперь ответственный время от времени делает выборочную или сплошную, это уже кому как нравится, проверку актуальности документов. Или не делает... и понимает, что может огрести за это в любой момент.

Заключение

Статья получилась большой и сложной. Но меньше всего хотелось отпугивать вас от веб-интеграции. Конечно, она требует опыта. Но опыта не бывает без практики. А практики не бывает без ошибок.

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

Просьба: сейчас в Студии мы пытаемся понять, заинтересованы ли вы в прочтении подобных статей? Чтобы сделать материал полезным и практичным, требуются очень большие усилия. На подготовку этой статьи ушло около 20 часов трёх специалистов.

Наш арт-директор Саша Котов считает, что мы «маемся дурью», и это никто читать не будет 🙂

Поэтому если вы считаете эту работу полезной и думаете, что нам стоит продолжать в том же духе, пожалуйста, лайкните эту статью или поделитесь в соц.сетях. Так мы поймем, что пишем не в стол и получим мотивацию продолжать.

www.internet-design.ru

Кто такой веб интегратор????Кто такой веб интегратор????

Если вы о Web Integrator как о программном средстве, то это фреймворк, написанный с использованием технологии JSP и юзающий tomcat как сервер для работы. Человек - веб интегратор - по логике вещей занимается внедрением веб решений и серверов. Больше чем кодер. Скорее разработчик.

WEB-интегратор – это специалист, который осуществляет посредничество между командой дизайнеров и командой разработчиков при создании какого-либо web-проекта. Иногда еще веб-интегратора называют разработчиком пользовательских интерфейсов. Веб-интегратор имеет дело с визуальными элементами и интеграцией HTML/CSS в: веб-сайты; веб-приложения; мобильные приложения; массовые рассылки; электронные издания. Хороший веб-интегратор также вносит свой вклад в улучшение эргономики сайтов и других веб-проектов, выполняет функции графического дизайнера и/или веб-разработчика. Web-интегратор чаще всего работает под руководством технического директора или проект-менеджера. 1 WEB-интегратор должен, прежде всего, хорошо знать HTML и CSS, а также JavaScript. Для создания визуальной анимации web-интегратору понадобится умение работать с jQuery. Иногда такому специалисту нужны также навыки работы в Adobe Photoshop и даже Indesign и Illustrator. И, конечно, web-интегратору необходимо быть «на ты» с наиболее распространенными CMS, например WordPress, Drupal, SPIP, Joomla и др. Где учиться на веб-интегратора? Специальности web-интегратор в российских вузах пока не существует. Базовые навыки и знания можно получить на хороших программах по IT-технологиям или программированию в инженерных вузах (например, МГТУ им. Баумана, факультете ВМК в МГУ им. Ломоносова, МФТИ, МИФИ, МЭСИ и др.). Получить недостающие знания можно на дополнительных курсах, которые есть во множестве в тех же самых вузах и в других центрах обучения. В целом же даже опытный web-интегратор должен постоянно пополнять багаж знаний, регулярно проходя курсы повышения квалификации – в этой сфере знания и технологии меняются очень быстро.

touch.otvet.mail.ru

Author: alexxlab

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *