Службы MIS3. Разработка — различия между версиями
Материал из ИбисоПедии
Admin (обсуждение | вклад) |
Admin (обсуждение | вклад) (→Аутентификация в БД) |
||
| Строка 44: | Строка 44: | ||
** большими буквами | ** большими буквами | ||
** совпадать с именем службы | ** совпадать с именем службы | ||
| − | ** заканчиваться на | + | ** заканчиваться на '''_SRV''' |
логин пароль храним в открытом виде в файле ini (<имя службы>.ini) | логин пароль храним в открытом виде в файле ini (<имя службы>.ini) | ||
| − | * | + | * [Postgresql] |
** user | ** user | ||
** password | ** password | ||
| − | ** | + | ** password_crypt |
=== Требования к работоспособности при потере соединения === | === Требования к работоспособности при потере соединения === | ||
Версия 07:31, 22 октября 2019
Содержание
Общие требования
Структура файлов
- каждая служба живет в своем каталоге
- имя исполняемого файла службы должно заканчиваться на _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
- ХОСТ (портал пациента)
- Интеграция с ЛИНС Махаон
- Интеграция с СПАРМ
- Интеграция с ИСАР
- ЛИС результаты анализаторов - больше не используется
