Документация содержит описание продукта HyperHive версии 2.0.12 (стр. 10 )

При нажатии на кнопку Добавить группу открывается форма добавления новой группы, в которой для создания группы необходимо задать значения следующих параметров:

Импорт из LDAP – флажок, определяющий признак импорта группы из внешней LDAP-системы; Название – поле для ввода названия группы в платформе; Доступ к ресурсам – список запрещенных и разрешенных для доступа ресурсов, который управляется группой элементов управления (кнопки Разрешить и Запретить); Push-топики – список push-топиков, по которым пользователь будет получать уведомления; Учетные данные – техническая учетная запись, которая будет использована для подключения к системам-источникам.

4.14 Отправка push-уведомлений в платформу

В данной статье приведено описание API сервера HyperHive для отправки push-уведомлений на мобильные устройства.

Общие сведения

Доставка push-уведомлений в платформе HyperHive текущей версии реализована на базе протокола MQTT. В общем случае система-источник отправляет уведомление на сервер HyperHive посредством web-api, а сервер HyperHive, в свою очередь, доставляет уведомления в приложения на мобильных устройствах посредством протокола MQTT. Ниже приведена общая схема работы push-уведомлений в платформе HyperHive.

Настройка push-уведомлений

Для того чтобы можно было пользоваться push-уведомлениями, в HyperHive необходимо создать push-сервис, а в нем push-тему. Push-темы имеют иерархический вид, например, a/b/c. При их создании можно использовать два специальных символа:

Символ “+” позволяет подписываться на все темы одного конкретного уровня. Пример: при создании темы a/+ и выдаче прав на неё мобильному пользователю последний получает уведомление и в том случае, если запрос на push-entry пришёл с указанием любой из тем a/b, a/c. Символ “#” позволяет подписываться на все темы выше по иерархии. Пример: при создании для мобильного пользователя темы a/# он получит уведомления по следующим запросам:

a/b a/b/c a/b/+/ a/b/+/d

Специальные символы могут быть использованы только при создании темы в веб-панели администратора. При отправке запроса на Push API тема должна быть указана однозначно (a/b – правильная тема, a/# – неправильная).

Для создания push-сервиса необходимо выбрать пункт меню Push-сервисы, откроется окно со списком существующих push-сервисов. Для добавления нового push-сервиса необходимо нажать кнопку Добавить push-сервис, откроется окно, в котором необходимо указать следующие параметры:

Название – параметр будет использоваться внутри платформы, должен быть уникальным в рамках проекта; QoS (Quality of Service) – режимы доставки сообщений:

Подтверждение доставки не ожидается, retry не предусмотрен. Если мобильный клиент находится оффлайн – сообщение теряется; Сообщение точно будет доставлено один раз (но может большее количество раз), сообщение кэшируется в брокере, если мобильный клиент не в сети. Сообщение точно будет доставлено один раз, оно кэшируется в брокере, если мобильный клиент не в сети.

Более подробно методы работы с push-уведомлениями представлены в разделе Методы работы с push-уведомлениями.

Подписка на push-темы на стороне мобильного устройства

Данная тема представлена в разделе разработчика – Отмена выполнения и получение промежуточных результатов асинхронных задач.

4.15 Версии проекта

Раздел Среды/<Имя_среды>/<Имя_проекта>/Версии проекта предназначен для просмотра списка версий проекта платформы.

В списке версий проекта напротив каждой версии расположена кнопка Удалить, нажатие на которую приводит к удалению версии проекта из системы.

Название версии проекта в списке отображается в виде гиперссылки, при активации которой происходит переход к окну редактирования параметров версии проекта.

Для создания версии проекта необходимо нажать на кнопку Добавить версию проекта и в открывшемся окне указать следующие параметры:

Название – названии версии проекта; Комментарий – текстовое описание версии проекта.

5. Разработка

В настоящем разделе представлены основная информация и рекомендации по разработке приложений с использованием HyperHive.

До начала разработки необходимо проверить:

наличие лицензии HyperHive и (или) лицензии разработчика HyperHive (см. раздел Запрос лицензии); корректность установки и настройки сервера HyperHive (см. раздел Загрузка и установка); наличие загруженного архива фреймворка для соответствующей платформы (см. раздел Загрузка архива фреймворка).

Также в настоящем разделе приведена информация по использованию фреймворков для соответствующих платформ; демо-приложения (проекты, исходные коды), в которых применяются возможности указанных фреймворков.

5.1 API сервера

Коммуникации клиентов с сервером мобильной платформы HyperHive осуществляются посредством HTTP-API. В настоящем разделе приведена информация по API сервера, с которым может взаимодействовать разработчик:

5.1.1 Работа с дельтой

API – это основной инструмент для работы с данными, предоставляемыми мобильной платформой.

Основные определения

Дельта – отличие между двумя версиями данных ресурса. Для каждой таблицы ресурса дельта содержит список строк на вставку и список идентификаторов строк на удаление. Также дельта содержит номер начальной и конечной версии данных. Версия данных ресурса является целым положительным числом: версия 0 соответствует ресурсу, в котором данных нет.

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

Ресурс – сущность с данными, которая с помощью API переносится из бизнес-системы (например, SAP) в мобильное устройство. Ресурс имеет имя и состоит из набора таблиц с данными.

Отличия от API версии релиза 2.0 (v0.6) от версии релиза 1.1 (v0.5)

Единая точка входа (auth); Единая точка получения информации о ресурсах; Структура в новых терминах; На выход табличного ресурса – одна таблица.

Предоставление дельты

На схеме приведен сценарий использования дельта-кэша при работе с одним ресурсом.

Данные в кэше

Кэш является сущностью, которая хранит в себе следующие данные:

Несколько ответов источника данных с указанием версий; Дата последней записи в кэш; Информация для сопоставления запроса с кэшем: для какого ресурса этот кэш; какие креденшалы использовались при запросе к источнику данных.

Кэш является актуалным, если выполнены все перечисленные условия:

время жизни кэша не истекло; значения параметров ресурса являются значениями по-умолчанию; кэш загружался хотя бы один раз.

Значения по-умолчанию для параметров табличного ресурса зависят от типа параметра:

для скалярных параметров – это значения, указанные в панели управления; для табличных параметров – это пустая таблица, т. е. таблица без строк. Либо если таблица не передана в качестве параметра.

В панели управления можно увидеть следующую информацию:

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

Обозначение версий дельты

Значение версий

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

нумерация версий начинается от 0; версия 0 обозначает, что данные ресурса еще не загружены; при первой загрузке данные ресурса получают версию 1, даже если они пустые; при каждой следующей загрузке номер версии увеличивается на 1, даже если данные ресурса не изменились; если номер последней версии не известен, то вместо него можно указать ключевое слово "last", которое обозначает самую последнюю версию данных ресурса.

Формат записи

Ниже описан синтаксис записи версий дельты в нотации ABNF.

       delta_versions = old "-" new

  old = "v" version_number

  new = ("v" version_number) / "last"

  version_number = 1 * DIGIT

Примеры корректных версий:

       v0-last

  v2-last

  v1-v3

  v2-v2

Дельта не имеет смысла, если конечная версия "0" или если конечная версия больше начальной. Примеры не корректных версий:

       v2-v1

  v0-v0

  v1-v0

Если самая последняя версия равна 1, то запись "v2-last" не имеет смысла.

Типы и методы обращения к API

Запрос может быть выполнен синхронно (в том же потоке выполнения) и асинхронно (в новом потоке выполнения). В случае обычного, синхронного запроса, результат (если имеется) будет доступен сразу же после выполнения запроса. В случае асинхронного запроса, результат нельзя получить сразу же: указывается необходимость выполнить запрос и получить его результат (т. е. подготовка к запросу, а не сам запрос к API). Для получения результата в таком случае используется функция callback – функция, которая будет вызвана системой по приходу результата запроса. Результат запроса будет передан в эту функцию как аргумент.

Время выполнения различных запросов к API может быть как очень коротким (быстрые методы), так и длительным (длительные методы).