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

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

Содержание

1 Общие требования
2 Диагностика работы службы
3 WEB API
4 Документация
5 Список сервисов

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

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

каждая служба живет в своем каталоге
имена каталогов в ВЕРХНЕМ регистре
все имена файлов в нижнем регистре
имя исполняемого файла службы должно заканчиваться на _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

application_name в сессии postпresql

Любая сессия должна себя идентифицировать установив 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

Здесь описаны методы 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 брать пример отсюда

@@ Строка 60: / Строка 60: @@
 ** password_crypt
-== Требования к работоспособности при потере соединения ==
+=== application_name в сессии postпresql ===
+Любая сессия должна себя идентифицировать установив application_name в формате <имя файла> (версия). Например
+  '''kis_mqtt.exe (1.0.0.1)'''
+Ниже пример кода:
+<source>
+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;
+</source>
+=== Требования к работоспособности при потере соединения ===
 * Служба должна корректно отрабатывать ошибки, связанные с потерей соединения с БД и пытаться восстановить соединение самостоятельность.
-== Зависимость от другого ПО ==
+=== Зависимость от другого ПО ===
 * служба не должна зависеть от стороннего ПО, такого как