Команда
BVSTATMON обеспечивает клиентской программе возможность отслеживать различные состояния и переходы состояний купюроприёмника.
Основной целью является получение сигнала о неисправности или вскрытии купюроприёмника, а также получение сигнала о восстановлении работоспособности купюроприёмника.
- BVSTATMON [<respfile> [<mask> [<timeout>]]]
- <respfile> - имя файла ответа, в ResponseDir;
- <mask> - битовая маска ожидаемых состояний (см. Флаги состояний), шестнадцатеричное число (только HEX, без дополнительных спецификаций)
- <timeout> - таймаут ожидания ввода, секунды (десятичное число)
- Ответ записывается в файл, первая строка может иметь одно из перечисленных значений:
- 0 OK
- 1 TIMEOUT
- 4 CANCEL ;запрос прерван (программно - либо BVSTATMON без параметров, см ниже, либо завершение работы службы или системы)
- 6 SIMULATED ;состояние симулировано, см. команду BVSIMEVENT. По сути этот результат полностью аналогичен 0 OK, однако возвращается другим кодом, чтобы предоставить клиентской программе возможность отличать смоделированные события от реальных.
- Если первая строка 0 OK или 6 SIMULATED, то вторая - битовая комбинация полученных состояний (шестнадцатеричное число - только HEX)
При нулевом/отсутствующем таймауте ожидание не выполняется, результатом может быть либо
0 OK/
6 SIMULATED, либо
1 TIMEOUT.
Вызов с нулевым таймаутом используется для прямого чтения текущего состояния.
Команда
BVSTATMON без параметров прерывает (
4 CANCEL) сразу все ожидающие конкурирующие запросы.
Вызывающее приложение может узнать о готовности ответа по завершению процесса
BVSTATMON.EXE
Маска ожидаемых состояний может иметь любое число бит (0..32).
Примечание: приложение NDemia CashMatic KioskBrowser имеет собственный встроенный код, полностью соответствующий интерфейсу BVSTATMON, поэтому описание данной команды является действительной документацией по механизму мониторинга купюроприёмника для всего продукта NDemia CashMatic.
Программа
BVSTATMON.EXE представляет собой безоконный (не консольный и не скрыто-оконный) процесс операционной системы, результат выполнения записывается в текстовый файл под указанным именем в пути
ResponseDir (конфигурируемый параметр службы
NDemia CashMatic Kiosk, настраивается командой
CONFIG).
Служба
NDemia CashMatic Kiosk должна работать на момент вызова
BVSTATMON.
Определён фиксированный набор событий, которые может распознать служба
NDemia CashMatic Kiosk. Каждому событию сопоставлены
код события и
флаг состояния.
Когда некоторое событие происходит, служба делает запись с соответствующим кодом события в логе купюроприёмника. При этом устанавливается соответствующий флаг в комбинации состояний, хранящейся в памяти службы, кроме того, в этой комбинации могут быть сброшены некоторые другие флаги состояний, в зависимости от конкретного события. Таким образом, установленное значение флага означает, что когда-то произошло событие, устанавливающее это состояние, и после того события не произошло событие, сбрасывающее это состояние.
Например, установление связи с купюроприёмником фиксируется в логе купюроприёмника как событие
ONLINE, при этом служба устанавливает флаг состояния
ONLINE. После этого связь может сохраняться много суток, в лог может быть записано много других событий, однако флаг будет оставаться установленным до тех пор, пока не произойдёт событие
OFFLINE, поэтому клиентская программа с помощью
BVSTATMON в любой момент может определить текущее состояние связи.
BVSTATMON возвращает позитивный результат (
0 OK/
6 SIMULATED) если/когда установлен хотя бы один флаг из маски ожидания.
С помощью команды
BVSIMEVENT флаги состояний можно устанавливать принудительно. При этом:
записи в
лог купюроприёмника не делаются;
сброс флагов соответствующим образом связанных состояний выполняется (в том числе принудительно установленных);
соответствующие по маске ожидания активные запросы
BVSTATMON срабатывают.
Служба отслеживает, какие флаги состояний были установлены принудительно, поэтому запросы
BVSTATMON всегда могут получить соответствующий действительности результат
0 OK или
6 SIMULATED.
Запросов
BVSTATMON может выполняться одновременно несколько (в отличие от
GETCASH), например, с разными масками. Это следует учесть в части задания имён файлов - одно имя не должно использоваться в нескольких запросах, иначе возможно наложение ответов (служба формирует файлы ответов в режиме
shared read-write-delete, поэтому наложение ответов действительно возможно и не вызывает конфликта с точки зрения файлового доступа).
Служба открывает файлы ответов в режиме
FILE_SHARE_DELETE, что позволяет вызывающей программе перед вызовом службы создать файл с флагом
FILE_FLAG_DELETE_ON_CLOSE (см. документацию по
Windows API, функция
CreateFile), и в дальнейшем не заботиться об удалении этого файла - операционная система автоматически удалит его даже при сбоях работы программного обеспечения.
