Основным инструментом для логирования был выбранlog4js (https://www.npmjs.com/package/log4js)
Информация сохраняется в файловой системе по такому пути ~/logs.
Подписка на socket вызовы
Для создания собственных обработчиков для socket требуется регистрация обработчика. Примером для регистрации может быть rpc. В данном приложение вызов всех RPC функций возможен не только по HTTP, но и через WebSocket.
Регистрация происходит в файле ~/modules/socket/main.js. Для этого требуется подписаться на определенное событие. В текущем примере будет идти речь об rpc.
socket.on(‘rpc', function);
, где function — это функция которая будет вызвана при получении сообщения от rpc. Данная функция должна выглядеть примерно так:
function(req, res, socket) { // (1)
return function (data) { // (2)
}
}
, где:
- res и req (1) — объекты которые примерно эмитируют стандартные response и request;
- socket (1) — объект подключения;
- data (2) — данные которые были переданы.
RPC — инъекция
Данная возможность позволяет внедрять собственный код при вызове стандартной RPC-функции. Например, нам требуется при создании нового пользователя записать информацию в лог.
Для начала нам нужно создать файл, который будет заниматься перехватом функции и реализует запись в лог.
Создаем файл ~/modules/injections/notification.js.
exports.userCreateWithLog = function(state, action, method, data) { // (1)
if(action == ‘sys_users’ && method == ‘Add’) { // (2)
var login = data.login; // (3)
console.log(‘Пользователь с логином ’ + login + ‘ создан.’);
}
}
Файл должен экспортировать функцию (1), в нашем случаи это — userCreateWithLog. Данная функция принимает несколько параметров (1):
- state: any — информация об авторизованном пользователе.
- action: string — имя RPC — объекта (сущности базы данных);
- method: string — имя метода RPC объекта.
- data: any — данные переданные RPC функции.
В функции создаем условие на проверку объекта и метода, который хотим обрабатывать (2).
Далее получаем (3) данные из объекта и выполняем с ним требуемую работу.
Создание собственных RPC — функций
Создание функция заключается формирование объекта в определенном формате. Для работы RPC требуется, чтобы каждый объект находился в определенном пространстве имен, например в текущем проекте это — PN.
Например, нам требуется создать собственный объект, который позволит получить серверное время. Для этого нам нужно создать файл, который должен располагаться в папке ~/modules/custom-context. Пусть это будет shell.js
Информация, которая находиться в файле shell.js
/**Читать далее «Создание собственных RPC — функций»
* объект для формирования ответа
*/
var result_layout = require('mobnius-pg-dbcontext/modules/result-layout'); // (1)
/**
* Объект с набором RPC функций
*/
exports.shell = function (session) { // (2)
return { // (3)
isLocal: true, // нужно указывать, иначе безопасность при создании meta не пропустит (4)
/**
* Получение серверного времени
* @param {*} data
* @param {*} callback
* @example
* // никаких параметров не нужно передавать
* PN.shell.getServerTime({}, function(){})
*/
getServerTime: function (data, callback) { // (5)
callback(result_layout.ok([new Date()])); // (6)
}
}
}
Правило формирования токена
Если применяется «Basic – авторизация», то токен должен состоят из строки «Token», символа пробела, плюс логина и пароля, которые разделены символом «:» (двоеточие) и закодированы в строку base64. Например, «Token » + convertToBase64(user:password);.
Рисунок 1.Пример токена авторизации.
Токен авторизации должен передаваться в заголовке запроса, например, это – заголовок «rpc-autorization».
Примечание: Имя заголовка может отличаться в зависимости от проекта. Применение не стандартного заголовка обусловлено тем, что при использовании proxy-серерва, стандартные заголовки могут быть переопределены.
Пакет для передачи данных
«Пакет» — единица данных для обмена информацией. Обмен данными между мобильным устройством происходить при помощи «пакетов». Пакет состоит из:
- заголовка;
- метаданных;
- строкового блока;
- бинарного блока.
Заголовок
– представляет из себя строку, в которой указывается число. Число предназначено для определения длины метаданных. Строка имеет длину 16 символов и состоит из типа, чисел, «наполнителя» и статуса пакета. Наполнителем должен являться символ «.» (точка). Статусы пакета:
- 0 – создан
- 1 – доставлен
- 2 – в обработке
- 3 – обработан
- 9 – обработан с ошибкой
Пример
NML950………0
, где NML — тип пакета, 950 – это длина строки, в которой содержатся метаданные «пакета», а остальные символы — это «наполнители».
Примечание: Длина строки должна равняться 16 символам.
Читать далее «Пакет для передачи данных»Правила комментирования колонок базы данных
Для автоматической генерации интерфейса ExtJS требуется придерживаться следующих правил:
- Для каждой таблицы/представления/функции должен быть создан комментарий — указать наименование (описание).
- Для колонок так же должен быть указан комментарий — это краткое описание колонки. Колонка так же поддерживает несколько дополнительных параметров, которые указываются в комментариях. Для этого перед комментарием указываем «[]» и внутри пишем параметры. Разделителем параметров выступает символ «|». Список параметров:
- e100 — параметр сортировки, чем больше число тем выше будет выведено поле.
- d — поле выводиться по умолчанию в выпадающем списке. В рамках одной таблице должно встречаться, только один раз.
Примеры
- id: integer — [e100] идентификатор
- c_name: text — [e90|d] наименование
«Настройки» системы
Для хранения настроек применяется таблица cd_settings, которая хранит информацию, как ключ-значение.
Правило именования
- Имена настроек должны содержать только латинские символы и числа. В качестве разделителя должен применяться символ «_» (нижнее подчеркивание).
- Для разных категорий настройке должен быть свой префикс.
- ALL_ — общая
- DB_ — база данных
- SRV_ — сервис
- UI_ — пользовательский интерфейс
- MBL_ — мобильное приложение
- Для указания региона, к которому должна применять настройка, доступно поле f_maindivision в котором требуется указать null, если требуется чтобы настройка применялась для всех. Либо выбрать конкретный регион.
- Для указания, что настройка должна быть привязана только к определенному пользователю требуется заполнить поле f_user.
Общие соглашения об именовании объектов базы данных
- Наименование объекта БД должно содержать слова на английском языке (на транслите, по возможности без сокращений), разделенные символом «_»;
- Русские буквы и другие символы, которые SQL Server запрещает применять в наименованиях объектов без экранирования – запрещены;
- Наименования объектов, совпадающие с зарезервированными словами SQL, запрещены;
Шаблон именования Таблиц/Представлений/функций:
SC.PP_ST_NAME
SC.PP_PP_ST_NAME
SC — схема, dbo или core
PP — префикс, их может быть несколько, core.ui_rpt_sd_users
S — раздел;
T — тип объекта;
NAME — наименование объекта, кратко отражающее его суть или назначение. Для таблиц требуется указывать имена в множественном числе (sd_users, cd_logs);
схемы БД
| core | ядро системы |
| dbo | Database owner — стандартная схема |
Префиксы для таблиц/представлений/функций:
| Префикс | Назначение |
| RPT | Reports — отчетные |
| EXP | Export — таблицы периодического экспорта данных |
| IMP | Import — таблицы периодического импорта данных |
| BUF | Buffers — буферные |
| UI | User Interface — функции используемые в клиентских приложениях |
| MUI | Mobile User Interface — функция используемся для мобильных устройств. |
Сокращения обозначения типа объекта (Представление/функция):
| Символ | Назначение |
| V | Представление |
| F | Функция |
| TR | Триггер |
| FS | Скалярная функция |
Сокращенные обозначения вида таблиц:
| Символ | Назначение |
| D | Данные |
| S | Справочники |
Разделы для таблиц/представления/функций:
| Символ | Назначение |
| A | Analytics — аналитика, AD_Telemetry |
| C | Common — общие назначения, CD_Settings |
| D | Documents — документы, (DD_Tasks) |
| E | Electric, (ED_Network_Items) |
| P | Permissions — безопасность, (PD_Users) |
| S | System — системная, (SD_Divisions) |
| X | eXtended — универсальные справочники |
Соглашение об именование столбцов
<Префикс>_<Наименование>
Префикс состоит из одной или двух букв и обозначает тип данных (реже назначение столбца):
| Символ | Назначение |
| B | тип данных boolean (b_main) |
| BA | тип данных bytea (ba_data) |
| C | строковый тип данных text (c_name) |
| D | дата (d_date) |
| F | признак внешнего ключа (f_user) |
| FN | признак внешнего ключа без обязательного наличия записи в связанной таблице (fn_user) |
| N | числовой тип данных (n_count) |
| S | системное назначение (s_salt, s_hash, sn_delete) |
| JB | тип данных JSON (jb_params) |
| X | вычисляемое поле |
Наименование столбцов соответствует общим правилам именования объектов.
Часто используемые имена столбцов таблиц БД и их назначение.
| Наименование столбца | Назначение |
| id | Идентификатор, первичный ключ. В большинстве случаев генерируется автоматически. |
| object_id | Идентификатор, в одной таблице может встречаться несколько раз. |
| f_user | Ссылка на пользователя |
| d_date | Дата создания, дата возникновения события |
| b_disabled | Отключение записи. Запись становиться не активной, но доступна для просмотра. |
| sn_delete | Системное поле для указания, что запись была удалена пользователем и для просмотра, которой требуются соответствующие права. |
| c_const | Константа. Уникальное текстовое значение для идентификации записи справочника. Это значение запрещено изменять |
| n_code, c_code | Код, выводимый для пользователя. Часто является естественным ключом. Как правило, по нему сортируются записи строки в списках |
| c_name | Наименование |
| c_short_name | Сокращенное наименование |
| b_current | Признак основного элемента. Записи со значением false являются архивными. Данный признак является вычисляемым. Установка значения true производится на основе даты d_date. |
| b_check | Проверено, данный признак проставляется после проверки информации диспетчером или автоматически если пользователь является доверенным. |
| gx_geodata | Вычисляется при создание записи. Используются n_longitude и n_latitude см. “Координаты в базе данных PostgreSQL“; |
| jb_data | Предназначена для хранения JSON данных |
Правило назначения версий
Для определения новой версии приложения предлагается следующий алгоритм:
- Версия приложения должна состоять из 3 или 4 групп чисел.
- Первая группа — номер версии приложения (архитектура).
- Вторая группа — количество дней пройденных с даты начала разработки.
- Третья группа — статус приложения:
- 0 — альфа — прототип
- 1 — бета — отправлен в тестирование
- 2 — выпуск-кандидат — передан на тестирование заказчику
- 3 — публичный выпуск — окончательно передан заказчику
- Четвертая группа — количество минут от текущей даты.
Из-за особенности npm создание группы из четырех чисел не представляется возможным, предлагается применять группу из 3 чисел, где третья группа будет отсутствовать (информация о статусе приложения).
Пример:
1.2.0.48 – Версия 1.2 — прототип от 18.12.2019, 00:48:00
1.2.3.56 — Версия 1.2 — публичная версия от 18.12.2019, 00:56:00.