Службы KIS. Разработка — различия между версиями

Версия 06:42, 22 октября 2019

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

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

• каждая служба живет в своем каталоге
• имена каталогов в ВЕРХНЕМ регистре
• все имена файлов в нижнем регистре
• имя исполняемого файла службы должно заканчиваться на _srv
• имя службы должно начинаться с kis
• имя исполняемого файла по управлению службой должно заканчиваться на _ctl
• настройка подключения к БД должна храниться в файле kis.ini
• настройки службы должны храниться в <имя_службы>.ini файле рядом с исполнимыми файлами. см. Конфигурационные файлы KIS

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

KIS_SRV
 ├─KIS_MQTT
 │  ├──kis_mqtt_srv.exe
 │  ├──kis_mqtt_ctl.exe
 │  ├──kis.ini
 │  │  kis_mqtt.ini
 │  └──LOG - Папка с логами
 └─KIS_EHR_CONNECTOR
    ├──kis_ehr_connector_srv.exe
    ├──kis_ehr_connector_ctl.exe
    ├──kis.ini
    ├──kis_ehr_connector.ini
    └──LOG

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

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

Имя службы windows

Имя службы должно быть латинскими буквами в нижнем регистре (с подчеркиваниями). Примеры названий служб:

• kis_mqtt
• kis_ehr_connector (может сократить до kis_ehr)
• kis_pg_rest
• kis_supp
• kis_simi_epic

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

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

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

• [Postgresql]
  • user
  • password
  • password_crypt

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

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

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

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

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

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

WEB API

Здесь описаны методы http, которые должна реализовать служба, чтобы можно было мониторить состояние службы. Эти методы будут вызвать сторонние приложения (админка kis_z, или другие сторонние программы) для отображения статуса работы службы

GET /checkstatus

Метод возвращает 1 в теле ответа, если сервис работает правильно

GET /info

возвращает json, в котором есть настройки, текущий статус сервера (есть подключение к БД и т.п.) Пример

 
 {"FileVer": "1.0.0.6",
	"StartDT": "2018-10-17T16:08:16.867+03:00",
	"AppExe": "C:\\KIS_SRV\\KIS_MQTT_SRV\\kis_mqtt_srv.exe",
	"DBInfo": {
		"ConnectStr": "192.168.1.16:7432\/emiac1",
		"ConnectStatus": "connected",
		"lastMessageRecivedDT": "2019-02- 04T08:20:58.302+03:00",
		"MeessageCount": 35024,
		"ListenState": "Active"
	},
	"MQTTInfo": {
		"ConnectStr": "192.168.1.16:1883",
		"ConnectStatus": "active",
		"ClientID": "V5nZpiOiintKZ1wgeg2K1f1",
		"LastSendDT": "2019-02-04T08:20:58.302+03:00",
		"MessageCount": 35008	}

GET /stat

Возвращает json со статистикой работы за период. Для построения графика нагрузки службы (метод необязателен и делается в последнюю очередь)

Пример:

  
{
	"last10hour": [{
		"dt": "2019-02-04T08:20:00.000+03:00",
		"Count": 10
	},
	{
		"dt": "2019-02-04T08:21:00.000+03:00",
		"Count": 12
	},
	{
		"dt": "2019-02-04T08:22:00.000+03:00",
		"Count": 9
	}]
}

GET /showlog

Показывает лог работы программы

Обычная html страница, которая показывает файл лог, который лежит на сервере

GET /admin

Возвращает html страницу управления

GET /checkupdate

Проверить наличие обновления (в БАЗЕ)

• если обновление не найдено, то возвращает пустую строку
• если обновление найдено, то возвращает версию обновления

GET /curversion

возвращает строку, текущая версия сервиса

POST /update

Обновиться

• проверить есть ли доставленное обнове в БД
• вызвать утилиту обновления для сервиса

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

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

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

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

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

• KIS MQTT_connector брать пример отсюда