Что такое интегрированные компьютерные системы

Обновлено: 15.01.2025

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

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

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

Википедия дает нам такое определение:

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

Я считаю, что в данном случае Вики абсолютно права. И дополнить ее можно только одним определением:

Интеграция программных систем и продуктов — это обмен данными между системами с возможной последующей их обработкой.

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

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

Например, если вы объединяете конфигурацию 1С: Торговля с 1С: Бухгалтерией, вам может потребоваться передать данные по всем продажам в бухгалтерию, а обратно получить сведения об оплате по этим продажам.

Определяем, какой продукт является источником, какой – приемником.
Сопоставляем объекты между источником и приемником.
Выбираем протокол для интеграции
Проводим постобработку данных (после переноса в одну из сторон)

Важно: при интеграции различных программных решений нужно хорошо понимать их функционал.

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

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

Выбираем источник и приемник

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

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

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

Сопоставление объектов (данных)

Каждый раз при работе с данными нужно очень хорошо понимать, что именно вы выгружаете, в каком виде, а также, куда вы будете выгружать эти данные. В некоторых случаях в источнике у вас будет строковая переменная, а в приемнике – два или более объектов. В других важно просто правильно выбрать объект-приемник.

Например, практически в любой CRM контактное лицо и клиент – это одно и то же. С другой стороны в 1С контактное лицо может быть клиентом, партнером, поставщиком. И очень важно понимать, куда именно записывать данные этого контактного лица. Также важно сопоставлять все данные до того, как начнется работа непосредственно с кодом. Для этого прекрасно подойдут таблицы или блок-схемы.

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

Например, при выгрузке контактного лица из CRM нужно четко сопоставить этот контакт партнеру или покупателю.
Также очень важно понимать, какие преобразования потребуются для выгружаемых данных. Например, нужные для интеграции данные в источнике хранятся в качестве перечисления в виде текста. А в приемнике (пусть это будет 1С) аналогичное перечисление имеет ссылочный тип. Следовательно, вам потребуется преобразовать текст в ссылку, и уже ссылку передать в документ.

И здесь возникает проблема: требуются правила сопоставления.

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

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

В результате возникают самые разные казусы. Например, вы используете в качестве ключевого слова для поиска при сопоставлении слово «дилер». Клиент по каким-то причинам меняет его в программе-источнике на слово «дилеры». Казалось бы, мелочь! Но эта мелочь приведет к тому, что поиск в 1С перестанет работать.

Обязательно оставляю клиенту подробно описанные правила сопоставления и пояснения, какие параметры и данные менять недопустимо.
Предусматриваю варианты оповещения об ошибке. Т.е. не только фиксирую проблему в логе ошибок, но и оповещаю пользователя о сбое каким-то образом: при помощи SMS, письмом на email, всплывающими уведомлениями в 1С. А иногда всеми этими способами сразу.

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

Например, в моей практике была ситуация, когда я провел интеграцию 1С и Oracle, причем, последний являлся программой-источником. Далее на стороне Oracle изменили одно из полей. В результате заказы перестали загружаться в 1С вообще, при этом сервер не выдавал уведомление об ошибке. Обнаружили проблему через неделю.

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

При помощи смс, электронного письма, всплывающих уведомлений в 1С информацию о сбое должен получить человек, который занимается обработкой заказов.
Для контроля аналогичное уведомление (чаще всего на email) отправляется руководителю отдела или директору компании.
Обязательно ведется лог-файл ошибок для того, чтобы специалист смог просмотреть все подробности.

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

Обмен данными: писать самому или применять типовое решение?

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

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

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

В некоторых случаях, когда типовое решение действительно на 100% удовлетворяет потребности клиента, а скорость работы для него не критична, я также применяю готовые продукты. Например, при выгрузке номенклатуры и фотографий на сайт я не редко использую готовый обмен данными от Битрикс. Но только для выгрузки. Для работы с заказами я применяю самописный обмен.

Метод подключения: REST API, SOAP или прямое подключение к базе приемника

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

Вопросы клиентского доступа: почему не работает обмен?

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

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

Ограничение доступа по IP.
Ограничение прав пользователя.
Ограничение по количеству обращений к источнику или приемнику

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

1С идентификаторы и ошибки, связанные с ними

При интеграции с 1С очень часто ошибки обмена данных возникают из-за неверного выбора УИ (уникального идентификатора). Суть проблемы заключается в том, что объекты в 1С имеют два типа УИ: один уникален внутри выбранного типа объектов. Второй используется для работы со всей базой данных.

Если вы будете проводить поиск по всему справочнику с использованием идентификатора, который предназначен для работы внутри определенного типа данных, возникнет ошибка. Объект может быть вообще не найдет, либо система найдет сразу несколько разных объектов. К этой особенности 1С нужно относиться очень внимательно.

Еще одна проблема: нет возможности привязаться к уникальному идентификатору.

Например, системой-источником является сайт, и на нем не предусмотрено отдельное поле для информации о клиенте, она идет в общем тексте заказа. В этом случае придется выбрать какой-то другой вариант идентификации, например, по email.

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

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

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

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

Формат выгрузки

Для обмена данными используются самые разные форматы. Это может быть JSON, XML, CSV, TXT, прямой доступ к базе и т.д. У меня в этом вопросе нет каких-то определенных предпочтений. Я считаю, что здесь нужно исходить из рациональных требований проекта.

Постобработка

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

Оповещение менеджера о поступлении заказа, например, при помощи sms
Уведомление пользователей о поступлении новых заказов или другой актуальной информации по email
Звуковой сигнал и/или всплывающее окно в 1С с напоминанием о том, что появились новые запросы или заявки

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

Например, это может быть уведомление клиента о том, что его заказ успешно прошел выгрузку и отправлен в обработку. И здесь также может быть использовано sms, электронное письмо или просто изменение статуса заказа в системе.

Тестирование интеграции

С моей точки зрения интеграция – это часть (иногда частный случай) внедрения программного обеспечения. И здесь, как и для любой другой работы по внедрению ПО, потребуется тестирование программистом, потом – лично консультантом, а также различные варианты тестирования вместе с пользователями. Об этом я подробно писал в статье Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть III. Финальная.

Отличие односторонней и двусторонней интеграции

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

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

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Кашубин Станислав Петрович

ИКС-технология представляет собой инструмент для синтеза систем программного обеспечения из стандартных компонентов. Технология может найти применение при разработке систем автоматизации производства, САПР, а также пакетов прикладных программ для научных и инженерных расчетов.

IСS-technology (creation of integrated computer systems)

IСS-technology is a tool for the synthesis of software systems from standard components. The technology can find application in the development of industrial automation systems, CADS, as well as software packages for scientific and engineering calculations.

Текст научной работы на тему «ИКС-технология ( создание интегрированных компьютерных систем)»

тезисов по материалам VI Международной молодежной научно-практической конференции «Человек и космос». Днепропетровск, НЦАОМУ, 2004. С.403. А.ВасильевА.М., Ландсман А.П. Полупроводниковые фотопреобразователи. М.:Сов.радио, 1971. 248 с.

Поступила в редколлегию 26.02.2006 Слипченко Николай Иванович, канд. техн. наук, профессор, проректор по научной работе ХНУРЭ. Научные интересы: радиофизика и электроника. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. (0572) 702 10-20.

Письменецкий Виктор Александрович, канд. техн. наук, профессор ХНУРЭ. Научные интересы: разработка устройств обработки сигналов. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. 702 13-43.

Яновская Наталия Николаевна, студентка ХНУРЭ. Научные интересы: исследование характеристик фоточувствительных структур. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. 702 13-43.

Фролов Андрей Витальевич, аспирант каф. МЭПУ ХНУРЭ. Научные интересы: исследование характеристик фоточувствительных структур. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел.702-16-59.

УДК 004.4 С.П. КАШУБИН

ИКС-ТЕХНОЛОГИЯ (создание интегрированных компьютерных систем)

В Институте проблем машиностроения НАН Украины им. А.Н. Подгорного проектируется инструментарий под названием ИКС-технология, которая синтезирует различные ИКС -интегрированные компьютерные системы. Разработка таких инструментальных средств является актуальной задачей, так как эти инструменты существенно повышают производительность труда программистов.

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

- ИКС-технология должна поддерживать несколько отраслей знаний.

- ИКС должны быть открытыми.

- Знания, относящиеся к одной отрасли, должны храниться в отдельной БД под названием Фонд задач. Система управления Фондом должна содержать функцию синтеза ИКС.

- Общая информация обо всех Фондах должна быть записана в систему МетаФонд, которая даст возможность создавать новые Фонды.

- Начальная версия системы ориентирована на среду СУБД Access-2 и предназначена для концептуальных исследований ИКС-технологии.

Головной модуль генерируется ИКС-технологией. На листинге 1 приведен пример прикладной задачи.

Dim k8 As Variant

Dim k7 As Variant

Dim aaa2(3, 3, 15) As Variant

Dim aa1(10, 15) As Variant

Dim aaa3(3, 3, 15) As Variant

Dim k1 As Variant

Dim k2 As Variant

Dim k3 As Variant

Dim k4 As Variant

Dim k5 As Variant

Dim k6 As Variant

Set БД = DBEngine.Workspaces(0).Databases(0)

Call ae1(k1, aa1(), k3, k7)

Листинг 1. Пример синтезированной задачи ИКС Иногда требуется обработать входную/выходную информацию прикладных задач специальным образом. Например, построить график, соединиться с техническим устройством и т.д. Программы, которые это делают, названы обработчиками задач. Обработчики создаются при поддержке ИКС-технологии. Пример обработчика приведен на листинге 2.

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

Система экспорта/импорта предназначена для установления информационной связью ИКС с ее внешними системами. Внешней системой может быть как отдельная программа, так и целый пакет программ, например базы данных, пакеты программ для научных и инженерных расчетов, CAD/CAM/CAE и пр. Для внешних систем Access-типа экспорт/ импорт осуществляется таблицами, а для остальных систем - текстовыми файлами.

Set БД = DBEngine.Workspaces(0).Databases(0)

Call ae1_o1(aa1(), k1, k3)

Листинг 2. Обработчик прикладной задачи

Базы данных, называемые Фондами задач, содержат описания всех компонентов, необходимых для синтеза ИКС. Управление Фондами осуществляется экранными формами, начиная с главной формы, пример которой приведен на скриншот 2.

Процесс наполнения Фонда сводится к тому, чтобы ввести в систему описания всех компонентов для сборки потенциальных ИКС, таких как имя компонента, перечень его входов и выходов, текст описания (метод решения, алгоритм и т.д.), инструкция конечному пользователю. С главной формы можно запускать процедуры формирования отчетов. Отчеты бывают двух видов: описание задач (один отчет для одного Фонда) и описание ИКС.

Скриншот 1. Интегрированные компьютерные системы Для синтеза ИКС необходимо вызвать соответствующую форму нажатием кнопки «ИКСы» из главной формы Фонда (скриншот 2) и сделать выборки: задач, обработчиков, входов/выходов, внешних систем. Кроме того, необходимо ввести тексты описания ИКС и инструкцию конечному пользователю. Новая ИКС создается на основе ядра ИКС и информации, хранящейся в Фонде. Ядро ИКС - это общая часть всех ИКС, в нее включены почти все формы и незаполненные управляющие таблицы. Во время синтеза ядро ИКС дополняется необходимыми компонентами, настраиваются свойства форм, создаются новые формы, таблицы и программы, создается DLL-библиотека. После синтеза новой ИКС ее программы необходимо оттранслировать.

Фонд Задач т|ж 1

аего1 Аэродинамическая задача №1 ае1 ■

аего2 Аэродинамическая задача №2 ае2 г

аегоЗ Аэродинамическая задача №3 аеЗ К5Н

аего4 Аэродинамическая задача N-4 ае4 ■Я

Ьоф Расчет корпуса самолета Ьо Щря

соскрИ Выбор кабины пилота со В

геас_ппо1 Расчет реактивного двигателя т

1аН Оптимальный расчет хвоста самолета 1а в

1игЬ_гпо1 Расчет турбомотора (и ■ш т

ипс1егсаг Расчет шасси самолета ип

Расчет крыла истребителя в

Расчет крыла Ых самолета 11

Скриншот 2. Главная форма Фонда задач

Новый «пустой» Фонд создает система МетаФонд, в состав которой входит база данных с программными надстройками. В базе данных хранится информация обо всех Фондах, а также описания основных понятий ИКС-технологии.

В 1 отображены результаты работы по данному направлению исследований. В качестве прототипа для ИКС-технологии была взята пакетная оболочка SP, которая представляет собой интегрированную среду разработки и управления пакетами прикладных программ [1]. Языками программирования для SP являются Пролог и Си.

Разработана начальная версия ИКС-технологии, которая синтезирует системы программного обеспечения из стандартных компонентов. Программирование выполнялось в среде СУБД Access-2, объем программного кода (без прикладных задач) не превосходит 1.5 Mb. Исследования системы проводились на тестовых примерах. В результате анализа результатов исследований можно сделать следующие выводы:

1. ИКС-технология удовлетворяет требованиям, которые сформулированы выше.

2. Научная новизна ИКС-технологии состоит в том, что она (технология) уникальна и позволяет синтезировать программное обеспечение нового стандарта. Кроме того, с концептуальной точки зрения ИКС-технология может послужить прототипом для создания системы управления вычислительными сетями. С этой целью были проведены соответствующие исследования.

3. Практическое значение ИКС-технологии вытекает из того, что эту технологию можно использовать при проектировании таких систем, как CAD/CAM/CAE и ППП для научно-инженерных расчетов с учетом того, что некоторые элементы проектируемой системы существуют, а некоторые элементы нужно создавать заново. Идея создания ИКС-технологии родилась из практической деятельности автора при проектировании систем программного обеспечения.

4. Целесообразно создать рыночную версию ИКС-технологии на основе существующей. Принципиальных трудностей с точки зрения программирования здесь возникнуть не должно.

Интегрированные системы в до- и после- компьютерную эру.

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

A.M. Омельянчук
Начальник КБ компании 'Сигма-ИС'

Что такое интегрированные системы безопасности? Такие системы устанавливались начиная с 1970-х гг., и всегда под этим понимали немного разное. Неизменным оставалось лишь одно: несколько подсистем различного назначения - как правило, охранно-пожарная сигнализация, СКУД, видеонаблюдение - должны работать как единая система. Типичными признаками интегрированной системы являются единое рабочее место оператора и возможность автоматических действий в одной подсистеме в ответ на события в другой.

Прошлый век

Традиционное решение конца прошлого столетия - релейно-мебельная интеграция. Единое рабочее место обеспечивается за счет аккуратного монтажа нескольких пультов в единый стол. Взаимосвязь между подсистемами осуществлялась за счет до сих пор единственного стандартного интерфейса - 'сухого контакта'. Выход тревоги от охранной сигнализации заводится на вход запуска записи видеосистемы, выход тревоги пожарной сигнализации - на вход разблокировки аварийных выходов системы СКУД и т.д. Сколько-нибудь сложная система предоставляет оператору десятки экранов и клавиатур управления, а связи между подсистемами осуществляются 100-парным кабелем. Новый уровень интеграции возник после начала активного применения компьютеров. В принципе две системы, имеющие компьютеры, можно объединить более информативным каналом, нежели несколько 'сухих контактов'. К сожалению, как уже упоминалось, это единственный в отрасли стандарт. Потому подключение каждой новой системы подразумевает тесное общение с ее разработчиками и как минимум дописывание нового программного кода. Тем не менее возможности систем с компьютерной интеграцией значительно шире и, как правило, подразумевают управление с одного компьютера всеми подсистемами, а также возможность настроить тысячи виртуальных связей, не прокладывая, как это потребовалось бы ранее, тысячи проводов.

Надо сказать, что сейчас уже существует довольно много программных комплексов, ориентированных на относительно быстрое подключение новых подсистем. Вы приносите описание интерфейса удаленного управления новой подсистемы, и уже через пару недель, а то и раньше основные параметры подсистемы доступны в этой программной системе. Дело в том, что основные понятия во многих подсистемах схожи, а потому разработчики таких программ придумывают некий промежуточный уровень (свой внутренний стандарт представления данных), более или менее пригодный для всех известных им подсистем. И затем для каждой новой подсистемы делают только 'драйвер' -конвертер/преобразователь из внутреннего формата данных подсистемы в формат данных интегрирующего ПО. Конечно, никакие 'изюминки', никакие гениальные новые функции вновь подключаемых подсистем, как правило, не доступны. Или, по крайней мере, требуют значительно больше времени, чем две недели, чтобы из универсального компьютерного АРМ можно было воспользоваться этими новыми функциями.

Как измерить интеграцию

По мере развития возможностей интеграции появились и новые критерии 'глубины интеграции'. Например, SIA (Ассоциация индустрии безопасности США) предложила использовать как основной признак качественной интеграции такое понятие, как 'общая база данных'. Как всегда бывает с достаточно сложными понятиями, это определение не слишком удачно. Понятно, что, по сути, имеется в виду возможность конфигурирования всех подсистем с одного рабочего места в единообразном пользовательском интерфейсе. Однако остаются открытыми вопросы: зачем центральной программе хранить все данные у себя в базе и обязательно ли база данных должна предусматривать одну из типовых СУБД (SQL, Oracle и т.д.) или обычные файлы - это тоже базы данных? В нормативных документах некоторых наших ведомств в начале нынешнего столетия было популярно требование к аппаратуре всех подсистем 'иметь возможность удаленного управления'. Это требование гарантировало как минимум возможность мебельной интеграции. А с учетом того, что эти пульты часто являются компьютерными программами, их даже можно запустить на одном компьютере. Кроме того, при наличии удаленного управления заведомо есть некоторый более или менее описанный интерфейс для подключения этого удаленного пульта, а значит, зная такие интерфейсы для всех подсистем, можно посадить несколько программистов, и они сделают 'интегрирующую программу'. В качестве аналога критерия 'глубины интеграции' порой фигурировало довольно абсурдное требование, чтобы удаленное управление осуществлялось в объеме не менее локального. Абсурдное, например, потому, что типичное локальное действие -'включить порт удаленного управления' - в принципе невозможно осуществить удаленно. К счастью, строгость законов Российской империи, как известно, изрядно смягчается необязательностью их исполнения. На моей памяти никто из технических специалистов этих ведомств ни разу не заикался о проверке этого требования в полном объеме - приемлемым считалось, если удаленно можно было использовать основные функции.

Системы без компьютеров

Одновременно все эти годы шел процесс повышения интеллектуальности контроллеров подсистем. То, что раньше называлось ППК (прибор приемно-контрольный), или рекордер, сейчас уже трудно назвать такими простыми терминами. Современный видеорекордер - далеко не просто магнитофон, от которого происходит его название. Да и называть современные контроллеры охранно-пожарных систем словом ППК, как назывались их предки, состоявшие исключительно из лампочек и тумблеров, - у меня язык не поворачивается. Самый простой микропроцессор в отдельно взятом пожарном извещателе или даже Smart-карте в вашем кармане сегодня может сравниться по вычислительной мощности с персональными компьютерами 1980-х гг. и значительно превышает возможности 'больших' компьютеров, использовавшихся в 'почтовых ящиках' в 1970-е гг. А что уж говорить про центральные процессорные блоки больших охранных систем - они полностью сравнимы по мощности со вполне современными компьютерами: гигабайты памяти, гигагерцы тактовой частоты. Разумеется, по мере повышения интеллектуальности контроллеров множились надежды на то, что интегрированные системы охраны будут выглядеть как компьютерные сети - действительно, вроде бы если у всех контроллеров есть Ethernet-разъем, то их можно легко объединить в одну сеть. К сожалению, жизнь показала, что соединить-то их можно (в том смысле, что они не сгорят при таком соединении), но и взаимодействовать они добровольно не начнут. Будучи на одинаковых разъемах, 'разговаривают' они на разных языках. Отсутствие стандартизации мешает. Много раз пытались создать какие-то стандарты, но они устаревали быстрее, чем даже были написаны первые черновые варианты. Прогресс приводит к ежедневному появлению многих новых понятий, которых вчера еще не было, и протокол, вроде бы всех устраивавший ранее, сегодня уже никому не интересен. Все так же, как и в компьютерных системах. Чтобы подключить новое оборудование, нужно написать новый 'драйвер', а то и добавить отдельный аппаратный 'конвертер протоколов'.

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

Интеграция с видео

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

Компьютерное интегрирующее ПО исторически развивалось с другой стороны. Наиболее развитыми компьютерными АРМ обладали системы контроля доступа - ведь там неизбежно необходимо много работы осуществлять по ведению базы данных карт доступа и полномочий их владельцев. Поэтому системы контроля доступа имели в своем составе компьютерные АРМ уже тогда, когда видеосигнал был уделом видеомагнитофонов.

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

Самое главное, компьютерная система имеет богатые средства управления, а также интерфейс, привычный многим пользователям компьютеров. Разработка новых систем на базе готовых, наработанных для офисных приложений библиотек с помощью развитых средств программирования намного легче, чем для встроенных микропроцессоров. Поэтому первые цифровые системы обработки видео нередко строились на основе компьютеров с добавлением более или менее специализированных средств ввода видеосигнала. Естественное расширение компьютерных систем видеонаблюдения - подключение охранных систем, которые - с точки зрения программирования - обычно крайне просты. Результат уже называется интегрированной системой. СКУД в таких системах нередко подключается только вместе с отдельным ПО управления СКУД, поскольку работа со СКУД далеко не так проста. Считающаяся же 'интегрирующей' система управления видеозаписью лишь получает от системы контроля доступа отдельные сигналы - например, о проходе в заданную дверь -для активации видеозаписи.

Наиболее 'продвинутыми' (в смысле интеграции) оказались те системы, авторы которых разрабатывали как СКУД, так и видео. Они наиболее интегрированные в том смысле, что объединяют в себе видео, СКУД и 'охранку', однако в большинстве случаев они поддерживают только один тип видеоаппаратуры, только один тип аппаратуры СКУД и в лучшем случае несколько вариантов 'охранки'. Именно эти системы сейчас наиболее эффективны, если необходимо подключить какое-то новое оборудование. Да, с немалым трудом и, как правило, только при активной поддержке авторов нового оборудования, но постепенно список 'подключаемых подсистем' у таких программ растет и растет.

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

Самое интересное, что абсолютно те же самые процессы параллельно шли и среди аппаратных (некомпьютерных) средств. В классических охранных системах еще в 1990-х гг. появились дополнительные модули для регистрации видео -хотя бы отдельных кадров с последующей пересылкой по телефонному или иному каналу на пост наблюдения. Как всегда, видеоверификация призвана снизить количество ложных тревог и ложных выездов на объект тревожной группы. С другой стороны, в каком-то смысле интегрированными стали домофоны и видеодомофоны, многие из которых сейчас поддерживают минимальную СКУД и иногда даже охранно-пожарную сигнализацию. Наиболее активно в этом направлении развивались домофоны для многоквартирных домов. Со стороны 'от видео' также развивались некомпьютерные автономные видеосерверы. Первым делом они были оснащены дисками (или флэш-накопителями) для видеозаписи. Через некоторое время для целей оптимизации использования дискового пространства к ним были добавлены средства видеоанализа и входы (как всегда, под 'сухие контакты') для охранной сигнализации. Все это позволяет более эффективно использовать диск, писать с высоким качеством в подозрительных ситуациях и с более низким - при отсутствии сигналов тревоги. Решительный шаг был сделан, когда некоторые такие видеорекордеры обзавелись собственным небольшим экраном для просмотра видеозаписи. Так они стали полным эквивалентным заменителем компьютерной видеосистемы. Надо сказать, что схемотехника и в большой мере программное обеспечение у данных систем порой трудно отличить от 'компьютерных'. Конечно, оптимизированные для круглосуточной работы одноплатные системы конструктивно более надежны, чем модульные компьютеры широкого назначения. Однако внутри, как правило, стоит процессор либо х86 (реже PowerPC), либо ARM (как в современных КПК), а операционная система - либо Linux, либо Windows-Embedded. Конечно, для обработки видео обычно присутствует специальный DSP-процессор, и, в отличие от чисто компьютерных систем, в таких случаях этот процессор нередко может эффективно выполнять свою работу даже при полном отключении процессора управления, а вся эта привычная комбинация из Windows и Pentium-подобного процессора занимается лишь красивым пользовательским интерфейсом (опять же потому, что его намного легче создавать с использованием огромного количества наработанного для Linux/Windows инструментария). Конечно, если экран не превышает 5-10 дюймов, на нем неуместно использовать многооконный интерфейс, но оно и к лучшему - все эти масштабируемые передвигаемые окна порой полезны в офисных приложениях, но страшное зло в системах безопасности.

Почти сразу такие оснащенные дисплеями видеорекордеры научились показывать картинку не только с собственного диска, но и по сети, записанную своими менее продвинутыми собратьями. Ну и, конечно, вскоре появились системы, для которых их создатели, как и для 'компьютерных' интегрированных систем, написали драйверы для подключения одной или нескольких, в первую очередь охранных, систем. Или перенесли на такие контроллеры программы управления СКУД и т.д.

Немного о перспективах

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

Напомню, что и 'обычные' компьютерные системы могут быть реализованы с использованием не настольных, а индустриальных моноблочных одноплатных компьютеров, обладающих также повышенной надежностью (и непропорционально повышенной ценой). Граница между ними и контроллерами, выросшими из микропроцессорных решений, тонка. Основным критерием я бы назвал применение схемотехнических решений, обеспечивающих продолжение видеозаписи и видеоанализа при зависании операционной системы процессора управления. Впрочем, и этот критерий не идеален. И на обычном компьютере можно реализовать решения, освобождающие плату видеосопроцессора от зависимости от операционной системы (но это иногда может, например, потребовать установки отдельного жесткого диска, предназначенного исключительно для видеозаписи). Однако даже если видеозапись будет идти, все прочие, собственно 'интегрирующие' функции в лучшем случае не будут мешать работать отдельным подсистемам, а в худшем - при зависании Windows прекратит работу охранная или пожарная сигнализация. В этом отношении embedded (встраиваемые) версии Linux и Windows значительно надежнее. Кроме того, во встраиваемых версиях операционных систем можно легко выкинуть все ненужные компоненты и тем самым еще значительно повысить скорость и надежность работы устройства.

Подводя итоги сказанного, вновь с грустью упомяну о медленно развивающемся процессе стандартизации интерфейсов. В основном речь о программных интерфейсах - на основе XML и WebServices. Не буду вдаваться в детали - все они пока на весьма ранней стадии. Для интересующихся перечислю основные названия: ANSI/SIA OSIPS (особенно интересны видеорасширения), OASIS oBIX, OASIS WSDM, OASIS EDXL, AXIS/SONY/BOSCH ONVIF. Подробности легко найти в Интернете. Все эти интерфейсы ориентированы на использование довольно мощных компьютеров, но я опасаюсь, что когда какой-то из них получит широкое распространение, опять пожарный извещатель станет мощнее современного компьютера и опять эти интерфейсы будут тормозом прогресса.

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

Общее определение системной интеграции

Какова роль системного интегратора?

В широком смысле в мире ИТ системный интегратор (SI) рассматривается как компания, специализирующаяся на внедрении, планировании, координации, составлении графиков, тестировании, улучшении и иногда поддержке ИТ-систем. Хорошими примерами системных интеграторов являются, например, Deloitte, IBM, Accenture, TCS и т.д. Они реализуют крупные ИТ-проекты (например, проекты ERP), пытаясь управлять такими проектами и многочисленными вовлеченными поставщиками. Однако с точки зрения системной интеграции роль системного интегратора сужается до обеспечения интеграции данных между различными существующими системами конечного потребителя, определенными в объеме проекта. Это может означать все, что угодно, от простых внутренних двухточечных соединений до очень сложных интеграций «многие ко многим» как внутри компании, так и с третьими сторонами.

Роль системных интеграторов в этом уравнении обычно заключается в разработке, внедрении и тестировании интеграционного решения, но роль системного интегратора может также включать постоянное управление решениями, а также связь с третьими сторонами для установления связи с ними. Однако наиболее важно то, что системный интегратор вносит свой вклад в интеграцию, которой заказчик не хватает внутри компании (или имеет под рукой нехватку доступных внутренних ресурсов). CTI признан одним из лучших системных интеграторов России рейтинга CRN/RE.

Методы системной интеграции

Типичные методы системной интеграции делятся на следующие категории:

Двухточечная интеграция

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

Вертикальная интеграция

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

Звездная интеграция

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

Горизонтальная интеграция

При горизонтальной интеграции отдельная подсистема используется в качестве общего уровня интерфейса между всеми подсистемами. Очень часто этот уровень называют Enterprise Service Bus (ESB). Этот метод позволяет каждой подсистеме иметь только один интерфейс для связи со всеми другими подсистемами, подключенными к общему уровню интерфейса (т. Е. С десятью системами есть только десять соединений). Преимущество этого метода также в том, что каждую подсистему можно изменить или даже заменить без необходимости переделывать интерфейсы любых других систем.

Интеграция с общим форматом данных

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

Почему интеграция B2B актуальна как никогда?

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

Хотя интеграция B2B первоначально началась с того, что крупные предприятия обязали методы получения бизнес-информации, она довольно быстро переросла в стандарты электронного обмена данными (EDI), а затем и в другие новые технологии, такие как XML, JSON и т. Д. В настоящее время кажется, что каждый Новое приложение имеет некоторый тип API, который позволяет интегрироваться с таким приложением. Тем не менее, это оставляет задачу фактической интеграции такого API с другими системами, и чаще всего большинство компаний просто не знают, как это сделать.

Проблемы системной интеграции

Типичные причины неудач проекта системной интеграции включают, например:

Постоянные изменения интеграционного ландшафта

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

Отсутствие квалифицированных ресурсов

Отсутствие ответственности

Когда вы интегрируете множество различных подсистем, ответственность за успех интеграции очень легко размывается. В уравнении может быть несколько заинтересованных сторон (например, поставщики, владельцы систем и т. Д.), Ни один из которых не несет ответственности за интеграцию всей системы. В лучшем случае они заботятся только о своей стороне интеграции, но они не рискуют выходить за пределы своей собственной территории. Но в интеграции всегда есть несколько сторон. Итак, когда что-то идет не так, ситуация очень легко превращается в указание пальцем и обвинение других сторон вместо того, чтобы кого-то «владеть» интеграцией. Если проектом системной интеграции занимается одна сторона, эта сторона также (часто по контракту) несет ответственность за успех такого проекта системной интеграции, и нет никакой двусмысленности в отношении подотчетности.

Интеграция устаревшей системы

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

Как iPaaS и платформа гибридной интеграции (HIP) могут помочь преодолеть проблемы интеграции?

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

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

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

Вы хотите узнать больше о HIP? Ознакомьтесь с публикацией «Руководство по платформе гибридной интеграции». Кроме того, ознакомьтесь с публикацией на iPaaS: Всеобъемлющее руководство, чтобы узнать больше об iPaaS.

Читайте также: