Создав аккаунт и зайдя в систему, вы видите дружелюбный интерфейс. Можно создавать лиды, задачи, проекты. Обычно в облачных CRM можно пользоваться только этим, а в "ERP-Платформе" можно редактировать интерфейс и структуру данных, создавать новые модули, делать в штатных модулях свои уникальные изменения и подгонять систему под логику работы ваших бизнес-процессов? И все это в облаке!

Здесь мы расскажем как технически устроена ERP-Платформа, почему ее можно индивидуально и неограниченно конфигурировать. Как получается, что "ERP-Платформа" может вырастать вместе с клиентами, превращаясь для клиента в ERP систему?

Базы данных

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

Внутри контейнера клиента находится 4 базы данных:

Сделано эта деление из технически-прагматичных соображений:

База конфигурации (основная база)

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

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

Файловая база

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

Сделано так из следующих соображений:

• В целях безопасности, все способы взлома при помощи загрузки поддельных файлов отпадают;
• Удобнее бекап и децентрализация структуры. База данных может храниться на любом сервере без прямой привязки к веб-серверу.
• Бекапы файловой базы клиент может хранить у себя на ftp (так же как и с основной);
• Структурой файловой системы можно управлять штатно из встроенного конфигуратора;
• Элементы файловой системы могут быть встроены в совместные блоки с другими элементами конфигурирования;

База логов.

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

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

Так же клиент (администратор клиента) записью логов может управлять самостоятельно. Можно настроить срок хранения данных, отключать или включать запись этих данных индивидуально в таблицах.

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

База передачи данных.

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

Наши технологии позволяют передавать во внешний мир данные прямо изнутри основной базы данных по событиям. Например, вы можете сделать триггер, который в случае изменения данных в таблице передаст данные в ВАШЕМ формате на ВАШ IP адрес в интернете. Т.е. передача данных не привязана напрямую к интерфейсу, а может работать как при каких-то действиях пользователя, так и при наступлении каких-то событий, в том числе все изменения по цепочке триггеров и отложенных заданий.

Эти данные могут быть достаточно объемны, т.к. аналогично логам по одному полю может делаться множество записей при изменении. Их хранение в основной базе нецелесообразно, поэтому по аналогичной технологии с логами, при наступлении события данные ретранслируются в служебную базу данных, и оттуда уже уходят во внешний мир. Некоторое время данные тут живут, на случай анализа проблем, а после очищаются, остаются только заголовки пакетов, т.к. они не занимают много места и постфактум можно понять, что такой-то пакет был передан с таким-то статусом.

Бекап данной базы не осуществляется, т.к. тут только служебные данные.

Конфигурация

Теперь рассмотрим как работает Конфигурационная (основная) база данных и как происходит построение индивидуального веб-интерфейса.
База делится на 2 больших раздела:

1. Данные – это рабочие данные компании
2. Конфигурация – это структура базы данных и интерфейса и структура их взаимодействия

Конфигурация в свою очередь делится на 2 больших раздела:

1. Конфигурация интерфейса.
2. Конфигурация базы данных.

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

Почему интерпретируемая? Дело в правах доступа и выводе элементов в зависимости от внешних условий.

• Права доступа имеют очень глубокую настройку, вплоть до отдельных элементов веб страницы. Они могут даваться на меню, на блоки страницы, на элементы, наследоваться вложенными элементами, быть разных видов (на чтение, редактирование, добавление, удаление). В зависимости от этого разным пользователям веб страница может быть выведена по разному.
  
  
• Отображение элементов может так же зависеть от внешних условий, например в зависимости от статуса документа (лида, задачи, …), какие-то элементы веб страницы могут быть скрыты, а какие-то наоборот показаны.
  
  
• Удобное преобразование в мобильную версию. В зависимости от экрана или типа браузера, вместо вывода двухмерной структуры, можно автоматически схлопывать все ячейки в столбец. Более того, в конфигурации можно указывать неважные элементы, которые можно проигнорировать для мобильной версии.
  Вот пример полностью автоматического преобразования при открытии из мобильного браузера:
  
  
  
• Можно сделать автоматическое зеркалирование структуры страницы при выборе RTL-языка (например Арабский или Иврит)

Конфигурирование интерфейса является визуальным и достаточно простым. В нашей системе реализовано 3D конфигурирование интерфейса.

Что это такое? Например в Битриксе вы можете добавлять только новые поля в списках – это 1D конфигурирование. Вы можете просто добавить новое поле, но не можете его расположить слева, справа, вторым-третьим рядом, в углу и т.п..

2D – когда вы можете располагать элементы интерфейса в любом месте страницы. 2D конфигурирование у нас реализовано просто и элегантно. Весь интерфейс разбивается на ячейки как в экселе. Так же как в экселе вы можете ячейки объединять между собой, и строки и столбцы. Таким образом можно выстроить любую структуру страницы. После этого в ячейки можно добавить элементы интерфейса. Это могут быть не обязательно текстовые поля. Можно добавлять кнопки, списки, изображения, таблицы и т.п. Ячейки можно стилизовать, т.е. раскрашивать в нужные цвета, настраивать границы полей, положение и шрифт и т.п.. Можно задавать фиксированные размеры столбцов и строк. В общем интерфейс редактируется очень гибко.

3D – 2D редактора не всегда достаточно, если страница должна иметь сложную логику работы. Например когда в зависимости от статуса задачи надо скрывать или показывать те или иные блоки страницы. Либо выводить в одну и ту же ячейку различные элементы редактирования в зависимости от тех или иных данных.
Для реализации таких сложных взаимодействий вводится 3-е измерение, по аналогии со слоями. В зависимости от событий может показывать нужный слой ячейки. Т.е. в каждую ячейку можно создать множество слоев со своими элементами и задать логику, по которой будет показываться тот либо иной слой.
У строк или столбцов тоже можно задать логику скрытия или показа, в зависимости от внешних условий.
Облачное 3D конфигурирование страницы позволяет реализовать любую логику работы интерфейса пользователя.



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



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

Сделано это из следующих соображений:

• Разделить редактируемый уровень (где пользователь может конфигурировать БД) и рабочий уровень. Если пользователь сделал что-то не так, то компилятор БД не позволит кривому коду откомпилироваться и начать работать.
  
  
• Современные базы данных, очень совершенный инструмент. Процедуры и триггеры работают очень быстро. Время обработки данных и получения результата, минимально.
  
  
• В процедуре удобным образом можно реализовывать любую логику обработки данных. Наша система полностью поддерживает концепцию PL\SQL и позволяет писать произвольные обработки.
  
  
• Триггер – это процедура особого типа, которая запускается по наступлению события (например записи строки в таблицу). Триггера могут так же использовать всю мощь PL\SQL подхода.
  
  
• Процедуры можно запускать по расписанию или привязывать к командам пользователя из интерфейса.

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

Запросы могут быть любой сложности, включая стыковку множества таблиц, case и т.д.

Внутри одних процедур можно запускать другие.

Разделение уровней на пользовательский (конфигурация) и рабочий, позволяет в нашей системе делать достаточно уникальные вещи, например:

• Тип данных image, где прямо в sql запросе можно получать изображение. Это очень удобно.
  Например: вывести в интерфейсе одним запросом таблицу такого вида не составляет туда:
  
  
  
• Снимать snapshot структуры.
  Например: вы сделали что-то не так, без проблем можно откатиться на предыдущее стабильное состояние.
  
  
• Штатная реализация блокчейн технологий.
  Если вам необходимо сделать не просто таблицу, а вести например лог безопасности, то штатно можно считать контрольную сумму строки. Для этого в таблице надо просто нажать нужную галочку и система автоматом на уровне базы данных будет считать контрольные суммы.
  Можно считать как просто контрольную сумму, так и контрольную сумму с учетом контрольной суммы предыдущей записи, чтобы гарантировать целостность данных во всей таблице.
  В sql запросе аналогично, можно штатной функцией организовывать проверку контрольной суммы. И в зависимости от результата, программировать следствия
  
  
• Автоматизация программирования.
  Можно одной кнопкой создавать наборы типовых процедур к таблице. Можно создавать переменные на основе таблиц, автоматически заполнять поля sql запросов и т.п. функции автоматизации.

Т.е. на уровне конфигурирования структуры можно конфигурацию БД как угодно крутить-вертеть. Как докрутили – все компилируется и становится рабочей частью вашей базы данных.

Все конфигурирование естественно делается в облаке, прямо в браузере.

Дружба интерфейса и базы данных

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

При этом надо чтобы все работало быстро, не выполнялось ничего лишнего.

Связующим звеном между интерфейсом и базой данных служит структура, называемая Источник данных. Она достаточно проста. В ней надо указать:

1. Процедуру которую страница будет вызывать и ситуацию в которой это должно случиться.
2. Что подать на вход процедуре, например из каких элементов форм интерфейса данные будут поданы в нее.
3. Как распределить результат выполнения процедуры. Т.е. в какую ячейку, элемент, таблицу надо вывести результат выданный процедурой.

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

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

Мультиязыковая поддержка

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

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

Так же для удобства разработки система делает автоматический первичный перевод новых элементов на зарегистрированные языки. Работает это так:

1. Если при создании нового элемента поля перевода не заполнены, система автоматически делает запрос с базовым наименованием в Яндекс-переводчик по необходимым языкам.
2. Результат запроса вносится в соответствующие поля.
3. Технический перевод может быть не всегда корректен, пользователь в любой момент может вручную поправить перевод. Но даже технический перевод существенно упрощает разработку.

Благодаря такому подходу, система может автоматически быть переведена на новый язык полностью, в течении пары минут. Запускается скрипт, который пройдет по всем существующим языковым элементам и с заданного базового языка сделает запрос на технический перевод, сохранит новое значение. Так же можно автоматически “допереводить” непереведенные элементы на существующем языке.

Базовая конфигурация

Мы предоставляем нашему клиенту не “голую” платформу, где он может что-то разработать, а аккаунт с уже существующей “базовой” конфигурацией. Т.е. в конфигураторе системы уже разработаны Задачи, Проекты, Заявки, Контрагенты, Лиды, Сделки, Предложения, Графики, Склад, Документы и т.д.
Более подробно базовый функционал описан в разделе ВОЗМОЖНОСТИ.

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

Если у клиента какие-то уникальные бизнес-процессы и требуется разработка какого-то индивидуального модуля – нет проблем. Используя конфигуратор системы, можно разработать любые специальные модули. Клиент может этим заниматься самостоятельно, либо заказать доработки.

Для самостоятельной разработки конфигурации требуется:

1. Опыт работы с процедурным SQL (PL\SQL).
   Для задания логики хранения и преобразования данных.
   
   
2. Базовые знания устройства веб страницы (если есть опыт верстки HTML то все хорошо).
   Для понимания основ конфигурирования интерфейса.

Таких специалистов достаточно много, и найти не проблема. Фактически любой специалист, имеющий опыт работы с базой данных, справится без проблем.

Конфигуратор отчетов

В нашу систему встроен мощный конфигуратор отчетов.
Подробная статья о нашем конфигураторе отчетов на хабре https://habr.com/post/331884/.

Быстродействие системы

Система работает быстро, благодаря правильному архитектурному строению ядра.

На быстродействие системы в значительной степени влияет схема работы приложения с базой данных. Все редактируемые системы стараются использовать язык программирования встроенный в интерфейс (это может быть свой, или один из стандартных популярных языков), а в базе данных хранить только данные. В итоге у них получается следующая схема работы:

1. Выполняемая в интерфейсе программа, формирует sql запросы в базу, их может быть много.
2. Сервер базы данных выполняет их и возвращает результат приложению.
3. Приложение по заданным алгоритмам проводит обработку этих данных.
4. Далее оно может записать результат в базу данных (еще одна передача данных) или вывести результат в интерфейс.

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

Мы сделали более современную схему работы, с минимизацией потерь. Результат абсолютно тот же, что и в схеме выше, но скорость работы существенно больше.

Вся обработка данных происходит на уровне базы, в быстроработающих скомпилированных инструментах. Интерфейс только дает команды и выводит результат.

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

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

ООО «ЕРП-Платформа» © 2021