Автор: Александр Краснов

Основным инструментом для логирования был выбранlog4js (https://www.npmjs.com/package/log4js) 

Информация сохраняется в файловой системе по такому пути ~/logs.

Для создания собственных обработчиков для 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-функции. Например, нам требуется при создании нового пользователя записать информацию в лог.  

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

Создаем файл ~/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 требуется, чтобы каждый объект находился в определенном пространстве имен, например в текущем проекте это — PN.  

Например, нам требуется создать собственный объект, который позволит получить серверное время. Для этого нам нужно создать файл, который должен располагаться в папке ~/modules/custom-context. Пусть это будет shell.js

Информация, которая находиться в файле shell.js

/** 
* объект для формирования ответа 
*/ 
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) 
        } 
    } 
}  

Читать далее «Создание собственных RPC — функций»

Если применяется «Basic – авторизация», то токен должен состоят из строки «Token», символа пробела, плюс логина и пароля, которые разделены символом «:» (двоеточие) и закодированы в строку base64. Например, «Token » + convertToBase64(user:password);.  

Рисунок 1.Пример токена авторизации. 

Токен авторизации должен передаваться в заголовке запроса, например, это – заголовок «rpc-autorization». 

Примечание: Имя заголовка может отличаться в зависимости от проекта. Применение не стандартного заголовка обусловлено тем, что при использовании proxy-серерва, стандартные заголовки могут быть переопределены. 

«Пакет» — единица данных для обмена информацией. Обмен данными между мобильным устройством происходить при помощи «пакетов». Пакет состоит из:

• заголовка;
• метаданных;
• строкового блока;
• бинарного блока.

Заголовок

– представляет из себя строку, в которой указывается число. Число предназначено для определения длины метаданных. Строка имеет длину 16 символов и состоит из типа, чисел, «наполнителя» и статуса пакета. Наполнителем должен являться символ «.» (точка). Статусы пакета: 

• 0 – создан
• 1 – доставлен 
• 2 – в обработке 
• 3 – обработан 
• 9 – обработан с ошибкой

Пример

NML950………0

, где NML — тип пакета, 950 – это длина строки, в которой содержатся метаданные «пакета», а остальные символы — это «наполнители».

Примечание: Длина строки должна равняться 16 символам.

Читать далее «Пакет для передачи данных»

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

1. Для каждой таблицы/представления/функции должен быть создан комментарий — указать наименование (описание).
2. Для колонок так же должен быть указан комментарий — это краткое описание колонки. Колонка так же поддерживает несколько дополнительных параметров, которые указываются в комментариях. Для этого перед комментарием указываем «[]» и внутри пишем параметры. Разделителем параметров выступает символ «|». Список параметров:
   • e100 — параметр сортировки, чем больше число тем выше будет выведено поле.
   • d — поле выводиться по умолчанию в выпадающем списке. В рамках одной таблице должно встречаться, только один раз.

Примеры

• id: integer — [e100] идентификатор
• c_name: text — [e90|d] наименование

Для хранения настроек применяется таблица cd_settings, которая хранит информацию, как ключ-значение.

Правило именования

1. Имена настроек должны содержать только латинские символы и числа. В качестве разделителя должен применяться символ «_» (нижнее подчеркивание).
2. Для разных категорий настройке должен быть свой префикс.
   • ALL_ — общая
   • DB_ — база данных
   • SRV_ — сервис
   • UI_ — пользовательский интерфейс
   • MBL_ — мобильное приложение
3. Для указания региона, к которому должна применять настройка, доступно поле f_maindivision в котором требуется указать null, если требуется чтобы настройка применялась для всех. Либо выбрать конкретный регион.
4. Для указания, что настройка должна быть привязана только к определенному пользователю требуется заполнить поле f_user.

1. Наименование объекта БД должно содержать слова на английском языке (на транслите, по возможности без сокращений), разделенные символом «_»;
2. Русские буквы и другие символы, которые SQL Server запрещает применять в наименованиях объектов без экранирования – запрещены;
3. Наименования объектов, совпадающие с зарезервированными словами 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.