Механизм межблочного взаимодействия
Разработка прикладных программ на платформе Инфо-Бухгалтер 10 подразумевает возможность комплексной автоматизации, то есть создания различных блоков, которые функционируют в едином информационном пространстве и обмениваются информацией в реальном времени. К примеру, операция перемещения товара в блоке "Склад" может приводить к формированию соответствующей проводки в блоке "Бухгалтерия". Для реализации такой возможности используется механизм обработки прикладных событий. В клиент-серверной системе блоки могут взаимодействовать тремя способами:
- Генерация события происходит на клиентском месте, обработка происходит локально, также на клиентском месте. Пример: в отчете блока А выбрали строку, в ответ должен вызваться отчет из блока Б.
- Генерация события происходит на сервере, обработка происходит локально, а также на сервере. Пример: в блоке А добавили операцию, в ответ надо добавить операцию в блоке Б.
- Генерация события происходит на клиентском месте, обработка происходит удаленно на сервере. Пример: для отображения в блоке А потребовалось значение, рассчитываемое в блоке Б.
Принцип работы механизма межблочного взаимодействия
В исходный код прикладного блока можно включать генерацию событий. Следует заметить, что на этапе генерации события еще неизвестно, будет ли оно обработано. Сведения о том, какие события будут обработаны, в каких блоках и каким образом, указываются в текстовых файлах с расширением .evd, которые должны храниться в директории /events. В клиент-серверной системе файлы описания событий могут присутствовать как на рабочих местах, так и на сервере (это означает, что часть событий может обрабатываться локально, а часть - виртуальной машиной серверного приложения). В файле описания событий для каждого прикладного блока указывается, какие события каким алгоритмом обрабатываются. Обработчиками событий являются исполняемые файлы на внутреннем языке, которые должны находиться там, где происходит обработка события. Если на клиентском месте файл не найден - событие пересылается на сервер.
Например, в файле описания file1.evd, расположенном на клиентском месте, указано, что Событие_А обрабатывает алгоритм алг1.ibx. Это означает, что как только в прикладной программе будет активизировано Событие_А, будет предпринята попытка запустить алгоритм алг1.ibx виртуальной машиной клиентской части. Если на клиентском месте этот алгоритм не найден - событие будет передано на сервер, и далее задача обработки этого события решается серверным приложением: в файле описания, расположенном на сервере, ищется имя этого события и алгоритм, его обрабатывающий, и если алгоритм найден - он запускается виртуальной машиной серверного приложения. В файлах описания на клиентских местах можно также указывать директиву пересылки события на сервер вместо алгоритмов-обработчиков. Это означает, что событие сразу передается на сервер, на клиентском месте обработчики не ищутся. Если обработчик не найден вообще - никакой обработки по умолчанию не происходит. Алгоритмы-обработчики должны обладать определенной сигнатурой - они принимают в качестве параметра передаваемое событие.
Итак, чтобы механизм обработки событий функционировал, используются следующие источники данных:
- Код прикладных программ - генератор событий;
- Файлы описаний *.evd - информация о правилах обработки событий каждым прикладным блоком;
- Алгоритмы-обработчики событий - обработка событий.
Схема механизма обработки событий
Для лучшего понимания механизма обработки событий приведем структурную схему, демонстрирующую порядок действий платформы при возникновении события. В качестве пояснения к схеме следует заметить, что реализация механизма обработки событий позволяет избежать напрасных расходов по передаче параметров в случае, когда событие не прошло фильтр по имени и семейству (то есть событие было сгенерировано прикладным блоком, но в evd-файле информации об этом событии не обнаружено). Событие целиком, с набором параметров, передается только в случае успешного прохождения фильтра.
