А.Ромейко А.Ромейко"блог"...Sorry!
PDMA_5-01. 30/01/08. Идеи.
1. Предпосылки создания новой версии № 5. Рост файлов .mdb при круглосуточной работе монитора (последнее наблюдение – 580Мегов!). Требуется периодическое сжатие, т.е. закрытие приложения, его сжатие и автоматическое открытие. Открытие сейчас только ручное с визуализацией.
2. Изменение архитектуры построения. Приблизительно – SOA (Сервис Ориентированная Архитектура).
3. Запуск стартовой формы – ручной, как и прежде. Регистрация активности АРМа и установка признаков для сервисов об активности АРМа.
4. Есть реестр сервисов и «библиотека» - серверная директория ФС, где храняться последние версии сервисов – файлы Access.mdb по видам обработки. Каждый АРМ имеет свой локальный реестр и «библиотеку» сервисов.
5. Сервисы различаются: активные – «движки», которые содержат формы, прерывания и вызываются по Shell, и пассивные, содержащие SQL запросы, макросы бизнес логики и открываются «движками», как application.currentDB.
6. Монитор событий – «движок», запускающий другие сервисы, которые перезапускают мониторинг после завершения своей работы.
7. По мере необходимости в сервисе, АРМ:
a. Добавляет требуемый сервис в свой реестр и копирует в свою «библиотеку».
b. Сверяет даты создания сервиса в общем и своём реестрах и обновляет, если необходимо, свой реестр и «библиотеку».
c. Стартует новый сервис «движок».
d. Закрывает себя – обеспечивая автоматическое сжатие, предусмотренное Access при закрытии файла.mdb.
8. Должен быть предусмотрен запрет на экземпляры запуска сервиса на одном АРМе.
9. Журналирование остаётся. Надо добавить «автоматическое» удаление из журнала по сроку информационных и ошибочных сообщений.
10. Перезапуск (сжатие) «движка» мониторинга будет обеспечиваться периодическими сервисами импорта из IRS.
11. Сервисы могут создаваться для обработки новых макетированных документов – идентификатор сервиса (пассивного) привязан к макету документа.
12. Требуются дополнительные процедуры администрирования сервисов – обновление connection и link по всей библиотеке сервисов при изменениях в таблицах БД на SQL серверах.

PDMA_5-01. 19/02/08. Первая реализация.
1. «Чистых сервисов» не получилось – очень плотно они программно объединены в модули, поэтому пришлось ввести ещё один уровень объединения групп сервисов в модули - файлы.mdb. Получилось 5 модулей «движков» и 6 пассивных:
a. PDMA_5_01_Fo01Start – стартовый модуль сервиса
b. PDMA_5_01_Fo02Adm – пока это - «монстр». Все сервисы, кроме заданий ПГ, которые были выделены в отдельный модуль ещё в 4-й версии.
c. PDMA_5_01_Fo03Avt – монитор всех событий, кроме заданий ПГ
d. PDMA_5_01_Tsk10Adm – обработка заданий ПГ в ручном и автоматических режимах.
e. PDMA_5_01_Tsk11Avt – монитор событий в заданиях ПГ.
2. Добавлено 4 новых таблицы:
a. dbo_dm_usAccReg – общий регистр модулей - файлы.mdb
b. dbo_dm_userComp – локальный регистр модулей АРМа.
c. dbo_dm_usServReg - общий регистр сервисов.
d. dbo_dm_usServComp - локальный регистр сервисов.
3. Стартовый модуль проверяет доступ к серверам, если нет ни одного активного модуля АРМа. Предлагает форму для запуска сервисов «движков» и установки признака вкл./выкл. для автоматических сервисов. Запускает «движки».
4. Функция запуска сервисов (1модуль, 2 формы, 12? запросов, 6? макросов) пока тиражирована по всем модулям «движков». Есть идея сделать отдельный сервис для запуска других сервисов, чтобы избежать тиражирования. Но здесь существует проблема организации очереди запусков при одновременном требовании от нескольких сервисов. Функция запуска сервисов имеет:
a. Параметры сервисов (currentID, nextID, parentID) передаются через dbo_dm_userComp. Три режима работы:
i. Запуск нового (следующего - nextID) сервиса.
ii. Возврат (запуск) на предыдущий (родительский – parentID) сервис.
iii. Возврат (запуск) стартового сервиса (модуля - mainID).
iv. Автономное закрытие модуля.
b. Если модуль нового сервиса уже активен, то второй экземпляр модуля не запускается. Запускает модуль для nextID сервиса.
c. В зависимости от признака isQuit закрывает себя (модуль в котором отработала) или оставляет свой модуль активным.
d. Если модуль закрывается, то сбрасываются признаки активности на данном compID модуля accAppID и сервиса currentID
5. Каждый запускаемый модуль сервиса выполняет следующие операции:
a. Определяет compID компьютера (и юзера) на котором запущен.
b. По compID и собственному accAppID берёт из dbo_dm_userComp значение currentID – требуемый для запуска сервис, входящий в данный модуль.
c. Устанавливает признаки активности на данном compID модуля accAppID и сервиса currentID.
d. Если currentID=0, модуль переходит в режим «автономная работа» - считается, что модуль запущен вручную, а не другими сервисами.
e. Запускает форму «движок» или форму для юзера, в зависимости от currentID.
f. По завершении работы сервиса -> Функция запуска сервисов.
6. Конфликт запуска одного и того же сервиса со стороны разных сервисов пока решён следующим образом: 4b, например, если мониторингу требуется сервис по обработке макетированных документов (МД), а модуль сервиса занят оператором с сервисом «Работа с МД», то мониторинг будет пропускать этот сервис в списке автоматических сервисов до тех пор, пока модуль сервиса не освободиться, т.е. пока оператор не завершит свою работу.
7. Функции обновления локальных «библиотек» сервисов (модулей) пока не реализованы. Нужен отдельный автоматический сервис с мониторингом дат создания и копирования их на локал, но как быть с самим этим сервисом, вернее с его обновлением, когда он активен, пока не ясно