Сохранение истории во внешней базе данных

Иногда необходимо сохранить историю переменных во внешей базе данных. Вот несколько шагов, позволяющих осуществить это: установите желаемую базу данных с таблицей для хранения значений, подключите эту базу данных к AggreGate Server и создайте Модель, которая будет слушать изменения переменных и хранить их в этой таблице.

Установка внешней базы данных

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

В нашем примере мы создали базу данных MySQL с именем history_db и таблицей variable_history, где будем хранить историю переменных из AggreGate. Наша таблица содержит следующие поля:

Имя

Тип

Цель

id

BIGINT

Используется для хранения идентификатора событий изменения переменных. Должен быть типом "число", может содержать длинные значения.

name

CHAR/VARCHAR

Содержит имя пепременной.

time

TIME/TIMESTAMP

Время изменения переменной.

value

FLOAT/DOUBLE

Само значение переменной.

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

Подключение к внешней базе данных

Теперь давайте подключим базу данных к AggreGate Server. Для этого нужно создать для нее учетную запись устройства. Откройте всплывающее меню для узла Устройства в Системном дереве и кликните по пункту Добавить устройство.

В диалоге Добавить устройство выберите База данных в качестве Драйвера Устройства. Назовите устройство historyDatabase и укажите URL соединения базы данных, имя пользователя базы данных и пароль базы данных. Мы используем пользователя root, потому что это удобно в тестовой среде, но, пожалуйста, убедитесь, что вы используете надлежащие протоколы безопасности в реальных средах.

Обратите внимание на правильное заполнение URL-адреса базы данных: строка подключения зависит от вашей DBMS. Можно начать редактирование строки, используя один из шаблонов в выпадающем списке поля. Для большинства современных баз данных можно пропустить поле Класс драйвера.

Если параметры верны и соединение установлено, в системе появится учетная запись устройства History Database и отобразится ее диалог Настройки устройства. Теперь перейдите во вкладку Запросы (1)и добавьте новую запись путем нажатия кнопки Добавить строку (2). На шаге (3) мы добавили пример запроса SELECT * FROM variable_history, чтобы проиллюстрировать получение всех изменений для данной переменной.

После создания и установки устройства можно взаимодействовать с базой данных, выполняя запросы для учетной записи устройства History Database.

Создание модели для извлечения данных

Мы будем использовать модель для прослушивания изменений переменных и записывать данные о событиях в базу данных. Поэтому нужно создать Модель. Откройте всплывающее меню для узла Модели () и выберите пункт Создать. Мы присваиваем нашей новой модели имя externalEventStorage и нажимаем кнопку ОК.

Откроется диалог конфигурации модели. Перейдите на вкладку Привязки (1) и добавьте строку (2). Новая привязка будет добавлена в таблицу привязок. Мы подробно рассмотрим, как заполнять каждое поле. Пока же просто отметьте поле При запуске (3).

Значения для остальных полей, Цель, Выражение, Активатор и Условие, описаны ниже.

Цель

Оставьте это поле пустым. Мы не хотим помещать данные о событиях в цель. Вместо этого мы просто выполним запрос на обновление базы данных в поле Выражение.

Активатор

Давайте заставим нашу привязку слушать событие изменения переменной. Щелкните на кнопке [...] в поле Активатор, чтобы открыть диалог выбора активатора.

Откройте вкладку Событие (1), затем найдите нужное устройство для прослушивания и выберите событие Context variable changed (2). Ссылка на это событие отображается внизу, в нашем случае users.admin.devices.defaultAdminDevice:updated@

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

Условие

Условие будет проверять каждое событие изменения переменной. Если условие ложно, событие будет проигнорировано. Поэтому мы установили выражение условия на cell({env/value}, 'variable') == 'random'. Это означает, что выражение привязки будет вычисляться только в том случае, если событие изменения переменной принадлежит переменной с именем random в выбранном контексте активатора. Обратите внимание, что выбранные нами устройства общего типа имеют ряд общих типов переменных, одной из которых является генератор случайных чисел, полезный для тестирования.

Выражение

Выражение вычисляется каждый раз, когда вызывается привязка и выполняется условие. Откройте редактор выражений для этого поля, нажав на кнопку [...]. В диалоговом окне редактора выражений задайте выражение для выполнения запроса на обновление базы данных. Он выполняется путем вызова функции executeQuery нашего устройства History Database. Запрос добавит новую запись в таблицу variable_history и будет подробно описан ниже.

  • Мы будем использовать callFunction(String context, String function, Object parameter1, Object parameter2, ...) функцию языка выражений для вызова executeQuery функции History Database устройства

  • Шаблон для callFunction в диалоговом окне, открываемом кнопкой «Функции».

  • Параметр context — это строковый путь к контексту, из которого будет вызываться функция. В нашем случае это History Database устройство, которое можно найти в Server Data Древе и скопировать в виде строки в наше выражение.

  • Путь к History Database устройства в нашем примере: users.admin.devices.historyDatabase

  • Параметр функции — это имя функции, которая будет вызвана из указанного контекста, в нашем случае executeQuery. Эта функция принадлежит контексту базы данных SQL History Database .

  • parameter1 (query) является вторым параметром вызывающей функции. Для executeQuery функции это строка запроса:

  • Наш пример запроса соответствует шаблону insert into variable_history(id, name, time, value) values(..., ..., ..., ...) Реальные значения должны быть помещены вместо '...'. Реальные значения мы получаем из нашей среды выражений. В нашем случае она будет содержать переменную, изменяющую параметры события, поскольку мы настроили эту привязку так, чтобы она вычислялась при событии.

  • {env/id} указывает на ID события. cell({env/value}, "variable") получает имя переменной из данных события.

  • formatDate({env/time}, "YYYY-MM-dd HH:MM:s.SS") берет дату и время записи события и форматирует их в строку времени, приемлемую для базы данных.

  • cell(cell({env/value}, "value"), "value") получает измененное значение из данных события, принимает таблицу, представляющую собой измененную переменную value и получает value поле значения переменной.

  • parameter2 (update) - второй параметр executeQuery указывает, является ли данный запрос запросом на изменение. В нашем случае это true, что означает, что запрос не должен возвращать никакого значения.

Примените выражение путем нажатия кнопки OK и нажмите кнопку OK в предыдущем диалоге Конфигурация модели для сохранения наших изменений привязок в модели.

Теперь, если все сделано правильно, изменения переменной random в Default Admin Device начнут сохраняться в таблице value_history базы данных history_db.

Можно проверить, если ли ошибки выполнения привязки, просматривая относящиеся к модели события External Event Storage. Просто выберите Просмотр событий из всплывающего меню модели в Системном дереве. Открывшийся Журнал событий можно использовать для отладки в режиме реального времени.

Просмотр результатов

Наконец, вы можете изучить свои результаты, открывая настройки History Database. Щелкните на узле History Database в Системном дереве левой кнопкой мыши, или выберите Конфигурировать устройство в контекстном меню.

Мы видим историю переменной, которая была сохранена в нашей внешней базе данных:

Was this page helpful?