Службы MIS3. Разработка

Общие требования

Структура файлов

• каждая служба живет в своем каталоге
• имя исполняемого файла службы должно заканчиваться на _srv
• имя службы должно начинаться с ibis
• имя исполняемого файла по управлению службой должно заканчиваться на _ctl
• настройки службы должны храниться в ini файле рядом с исполнимыми файлами.

Пример расположения служб

IBIS_SRV
 ├──Ibis.ini
 ├─SERTIFIATE
 │  ├──IBIS_SERTIFICATE_SRV.EXE
 │  ├──IBIS_SERTIFICATE_CTL.EXE
 │  ├──IBIS_SERTIFICATE.INI
 │  └──LOG - Папка с логами
 └─SPARM
    ├──IBIS_SPARM_SRV.EXE
    ├──IBIS_SPARM_CTL.EXE
    ├──SPARM.INI
    └──LOG

Именования файлов

• _SRV.EXE севрис
• _CTL.EXE управляющая программ
• _APP.EXE в виде отдельного приложения (на этапе разработки)

Взаимодействие с postgresql

Аутентификация в БД

• каждая служба должна работать под своим уникальным пользователем (для того чтобы можно было мониторить работу службы со стороны БД)
• имя пользователя должно быть
  • большими буквами
  • совпадать с именем службы
  • заканчиваться на \"SRV\"

логин пароль храним в открытом виде в файле ini (<имя службы>.ini)

• \[Postgresql\]
  • user
  • password
  • password\_crypt

Требования к работоспособности при потере соединения

• Служба должна корректно отрабатывать ошибки, связанные с потерей соединения с БД и пытаться восстановить соединение самостоятельность.

application_name в сессии postgresql

Любая сессия должна себя идентифицировать установив application\_name в формате <имя файла> (версия). Например:

 kis_mqtt.exe (1.0.0.1)

Ниже пример кода:

procedure TdmMain.conAfterConnect(Sender: TObject);
var
  S : String;
begin
  S := ExtractFileName(FSrvInfo.AppExe);
  S :=  S+  ' (' + FSrvInfo.FileVer + ')';
  con.ExecSQL('SET  application_name =  + S + '); // устанваливаем переменную application_name (pg_stat_activity)
end;

Зависимость от другого ПО

• служба не должна зависеть от стороннего ПО, такого как
  • вебсерверы (IIS, APACH)
  • Net framework
  • клиент БД

Диагностика работы службы

• служба должна писать информацию о событиях, в файл лога. Рекомендуется использовать SynLog из библиотеки Synopse mORMot framework
• файлы логов должны быть легко просматривамы сторонними программами.

WEB API

• checkstatus - возвращает 1 в теле ответа, если сервис работает правильно
• info - возвращает json, в котором есть настройки, текущий статус сервера (есть подключение к БД и т.п.)
• stat - возвращает json со статистикой работы
• showlog - показывает лог работы программы
• admin - возвращает html страницу с настройками

Документация

В каталоге обязательно должен быть файл readme.md в формате markdown (для редактирования можно использовать Typora). В нем должны быть следующие разделы:

• Назначение
• Состав (список файлов с описанием)
• Установка
• Настройка
• Обновление
• Мониторинг (проверка работоспособности, где и какие логи ведутся, как посмотреть какие ошибки возникали)

По правильному, содержимое файла markodown нужно продублировать на wiki (в typora есть экспорт)

Список сервисов

• KIS MQTT_connector брать пример отсюда
• Учет смертности и рождаемости ХМАО
• Across
• ХОСТ (портал пациента)
• Интеграция с ЛИНС Махаон
• Интеграция с СПАРМ
• Интеграция с ИСАР
• ЛИС результаты анализаторов - больше не используется