Вы просматриваете старую версию данной страницы. Смотрите текущую версию.

Сравнить с текущим просмотр истории страницы

« Предыдущий Версия 7 Текущий »


Релиз
Описание
Релиз 3.2
  • 3.2

    New Features

    • Добавлена возможность выполнения SQL скриптов для обновления базы данных. 
    • Добавлена обработка push уведомлений.
    • Доработана возможность получения связанных данных при изменении родительского объекта. Реализовано путем добавления поля KeyFieldTimestamp. 
    • Добавлено расширенное логирование событий, происходящих на сервере. Логирование реализовано с помощью библиотеки Serilog.
    • Добавлены методы для мониторинга состояния сервера.
    • Добавлены методы для проверки наличия обновлений и последующая отправка уведомления пользователям.

     Bug Fixes

    • Исправлены проблемы  с логированием в таблицах БД
    • Исправлен метод асинхронной загрузки метаданных

1) Добавлена возможность выполнения SQL скриптов для обновления базы данных. 

В рамках данной задачи было принято решение реализовать обновление базы данных посредством выполнения различных SQL Script's. Данное улучшение позволяет обновлять БД клиента без необходимости изменения всей структуры, что значительно ускоряет процесс добавления\удаления\переименования данных. 

Раньше обновление происходило путем перезаливки метаданных и данных, теперь можно выполнить команду "execsql" в командной утилите utils.exe.

2)  Добавлена обработка push уведомлений.

В сервере 3-й версии добавлена возможность обработки push-уведомлений как с сервера, так и на сервер.

3) Доработана возможность получения связанных данных

В определенный момент, прикладные разработчики столкнулись с проблемой не прихода связанных данных при изменении родительского объекта. То есть, мы изменяли объект, а связанные с ним данные приходили только при выполнении метода полной синхронизации. Проблема решена путем добавления поля KeyFieldTimestamp. В нем проставляется timestamp последнего изменения любого из ключевых полей таблицы. В случае, если ключевые поля хотя бы одной записи из видимых клиенту по фильтрам были изменены с момента последней синхронизации, то при синхронизации клиенту будет отправлен не частичный, а полный changeset.

4) Добавлено расширенное логирование событий

Раньше логирование происходило разрозненно. Некоторые данные писались в таблицу, некоторые в текстовые логи, некоторые в windows логи. Первым шагом к формализации подхода логирования на сервере является применение библиотеки serilog. Внедренная библиотека дала возможность подробно логировать основные операции на сервере. Логи пишутся в текстовый файл bmserver.log. Формат предоставления данных: "date", "time", "type", "request body".

 Пример:

2016-10-13 12:45:17.801 +03:00 [Information] Removing solution "test1"
2016-10-13 12:45:17.812 +03:00 [Information] Removed solution "test1"
2016-10-13 12:45:18.766 +03:00 [Information] Creating solution "test1"
2016-10-13 12:45:18.821 +03:00 [Information] Solution "test1" created
2016-10-13 12:45:22.237 +03:00 [Information] Setting password for solution "test1"
2016-10-13 12:45:22.240 +03:00 [Information] Set password for solution "test1"
2016-10-13 12:45:26.885 +03:00 [Information] Uploading metadata for solution "test1"
2016-10-13 12:45:31.018 +03:00 [Information] Archiving filesystem for solution "test1"
2016-10-13 12:45:31.216 +03:00 [Information] Archived filesystem for solution "test1"
2016-10-13 12:45:31.216 +03:00 [Information] Uploaded metadata for solution "test1"
2016-10-13 12:48:03.782 +03:00 [Information] Beginning operation 12852bdd-46e1-4ae1-81ba-26293dc593ab: "Sync"
2016-10-13 12:48:06.752 +03:00 [Information] Completed operation 12852bdd-46e1-4ae1-81ba-26293dc593ab: "Sync" in 00:00:02.9381694 (2938 ms)

5) Методы мониторинга состояния сервера

В рамках глобальной задачи по новому формату администрирования сервера был добавлен новый метод для мониторинга состояния. Метод исполняется при get запросе к серверу, требуется авторизация логин-паролем.

При запросе данный метод отдает данные о состоянии сервера/решения. 

http://host/system/status для мониторинга всего IIS приложения. Необходима авторизация под админом приложения.
http://host/solutionName/admin/GetSolutionStatus для мониторинга конкретного решения на сервере. Необходима авторизация под админом решения.
Ответ приходит в виде JSON. 

Пример ответа:

{"SolutionName":"synchro3","LastDataSyncErrors":[],"LastFileSyncErrors":[],"ApplicationPoolName":"DefaultAppPool","ApplicationPoolState":"Started","RequestsInSecond":1,"RestartTimeInMinutes":1740.0,"UpTime":"0:00:00:03,2688229"}

6) Методы для проверки наличия обновлений

Реализован метод, который отравляет push уведомления всем пользователям, при наличии обновлений, затрагивающих их. Обновления могут быть ресурсов или данных. Для оповещения об обновлениях нужно выполнить GET запрос к серверу. 

Данный метод позволяет уведомить пользователей о необходимости обновления их мобильного приложения. В перспективе это должно уменьшить количество заявок в техническую поддержку, т.к. пользователь будет своевременно обновлять мобильное приложение.




Баги:

key summary priority status

Невозможно найти сервер Jira для этого макроса. Причиной может быть конфигурация ссылки на приложение.


Задачи и улучшения:

key summary priority status type

Невозможно найти сервер Jira для этого макроса. Причиной может быть конфигурация ссылки на приложение.

  • Нет меток