Немного терминов:

Событие – элементарное действие, приводящее к изменению данных.

Объект события – абстрактное понятие, характеризующее блок информации, части которого распределены в разных системах.

Клиент – приложение, создающее события и требующее получения данных по событиям, также может нести функцию хранилища информации (справочников).

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

Как всё это «должно» работать:

1. На клиенте происходит событие: запись элемента Справочника, проведение/запись Документа, POST запрос, GET запрос, телефонный звонок, электронное сообщение и т.д.
2. Событие передаётся на сервер: как правило, достаточно только ID события, типа события и данных о системе, в которой оно произошло.
3. Сервер запрашивает у клиентов актуальную информацию об объекте события: Например, изменение данных контрагента (записали в бухгалтерии обновили в УТ, WMS и прочих системах).
4. Сервер обновляет данные на всех клиентах/выполняет необходимую обработку события.

Возможные исключения:

1. Один или несколько Клиентов не доступны.
2. Сервер недоступен.
3. Ошибки во время Обновления данных на клиентах.

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

Что из технических средств мы имеем для реализации подобного функционала:

Для получения данных:

1. Подписки на события.
2. Внешние источники данных.
3. WSссылки.
4. Web-сервисы.
5. Прямые запросы к базам данных.
6. Внешние COM компоненты (например: comconnector 1С).
7. Файлы обмена.

Для отправки:

1. Внешние источники данных.
2. WSссылки.
3. Прямые запросы к базам данных.
4. Внешние COM компоненты (например: comconnector 1С).

8. В исключительных случаях Файлы обмена, т.к. сложно проверить факт получение информации клиентом.

Сбор и отправка информации:

Собираем все данные запросами к необходимым системам, агрегируем все данные в структуру, из структуры выбираем необходимы данные для отправки Клиентам, т.к. у клиентов разная структура, протоколы и т.д.

Где может быть сервер? Да хоть где!!! Модуль обработки данных на любом из клиентов или как отдельная система/системы без разницы где всё это будет выполняться, вожен функционал и доступность из любого клиента.

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

Теоретический пример использования: создание и актуализация пользователей.

• Событие: запись элемента справочника «Сотрудники» в ЗУП.
• Клиенты: ЗУП, Буха, УТ, active directory, пропускная система и т.д.

Что происходит:

• В ЗУП срабатывает подписка на событие записи.
• Передаём Уникальный идентификатор сотрудника, то что это сотрудник/пользователь и то что его данные изменили в ЗУП на «сервер».
• На сервере через  comconnector забираем данные из ЗУП, Бух и УТ. Выполняем поиск в AD. Прямым запросом проверяем наличие пользователя и его данные в СКУД.
• Собираем актуальные данные по сотруднику: должность, права, все возможные идентификаторы.
• Заполняем на каждом клиенте все необходимые данные. Если есть данные которые вводятся только на определённом клиенте и не передаются из другого и в текущих данных клиента этого нет, то отправляем уведомление ответственному лицу. Например, необходимо сделать фото менеджера для пропуска и отображения в СКУД (заявка к службе охраны).

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

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