На рисунке 1.2.1 представлена общая схема интеграционного решения HtPassMonitor.

На каждом автоматизированном рабочем месте (АРМ) устанавливается Клиент и настраивается список считывателей, по которым должны отображаться события проходов на соответствующем АРМ.

Сервис подключается к СКУД и отправляет события проходов подключенным Клиентам.

Для работы Сервис использует программные модули-поставщики трех типов::

1. Поставщик считывателей – обеспечивает получение списка считывателей. При запуске Сервис сохраняет список считывателей в локальную базу данных. При подключении Клиент запрашивает у Сервиса список считывателей.
2. Поставщик персон – обеспечивает репликацию персон из базы данных СКУД в локальную базу данных Сервиса для быстрой выгрузки информации о персоне при возникновении события прохода.
3. Поставщик событий – получает события проходов из источника событий СКУД. Полученные события Сервис рассылает подключенным Клиентам.

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

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

Набор используемых интеграционных модулей и состав поставщиков данных указываются в файле настроек сервиса "_MainSettings.json". Подробнее о настройке поставщиков смотри раздел 3 Настройка.

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

Принципы приоритизации поставщиков:

• Поставщики считывателей не должны поставлять считыватели с одинаковыми именами, иначе источник событий не будет определён. При этом CSV Readers, как поставщик считывателей, всегда находится ниже в приоритете, чем интеграционные модули, поэтому он может содержать считыватели с такими же названиями, как и те, что поставляются другими интеграционными модулями. В этом случае данные о считывателях из файла "Readers.csv" будут замещены аналогичными данными о считывателях от других поставщиков (интеграционных модулей). Пример замещения данных о считывателях приведен на рисунке 1.2.3;

• При появлении события проверяется принадлежность считывателя этого события к интеграционному модулю, от которого оно поступило. Если событие поступило по считывателю, который не принадлежит ни к одному модулю (то есть считыватель описан только в файле "Readers.csv"), то такое событие будет обрабатываться всегда, вне зависимости от кого оно пришло. Если пришло событие, у которого название считывателя принадлежит другому интеграционному модулю, то такое событие отфильтровывается (игнорируется).

Общий алгоритм работы интеграционного решения:

1. Сотрудник предприятия подходит к турникету и прикладывает свою карту к считывателю или же происходит автоматическое распознавание сотрудника «по лицу». В зависимости от этого программное обеспечение СКУД генерирует одно из двух событий: "Запрос доступа" или "Лицо распознано".
2. Модуль Сервис получает информацию о событии и загружает данные о сотруднике (посетителе), совершающем проход.
3. Полученная информация передаётся всем Клиентам, подключенным в данный момент к Сервису.
4. Клиенты получают информацию о событии и отображают её на экранах АРМ сотрудников постов охраны.