Платформа RP Server предназначена исключительно для создания приложений, работающих с базами данных под управлением Microsoft SQL Server. В основном, это относится к задачам автоматизации предприятия, но не сводится только к ним. Это – довольно мощная самодостаточная среда, имеющая встроенный язык программирования и позволяющая создавать не просто экранные формы, но логически завершенные программные модули и большие приложения, состоящие из множества модулей.
Среда разработки (RP Designer) предназначена для создания приложений. Ее можно сравнить с Visual Studio. Приложение, созданное программистом в среде разработки, помещается в репозиторий.
Репозиторий (RP Repository) представляет собой БД под управлением Microsoft SQL Server. Эта же БД кроме приложения может содержать и целевую схему данных, с которой работает само приложение. Т.е. получаем в одной базе и пользовательские данные, и приложение, которое их обрабатывает.
Среда исполнения (RP Runtime) предназначена для исполнения приложений, хранящихся в репозитории. Фактически, это то, что принято называть толстым клиентом, поскольку система клиент-серверная. Трехзвенную архитектуру можно реализовать через терминальный доступ.
Среда разработки позволяет создавать объекты нескольких типов: списки, диалоги, меню, процедуры и др. Из этих объектов и строится приложение.
Для управления объектами используется встроенный язык (x-язык), который является интерпретируемым языком.
Каждый объект имеет собственное множество обработчиков событий. Многие из них имеют реализацию по умолчанию, поэтому в типовых случаях их реализация не требуется. Например, чтобы создать список со всеми характерными для списков свойствами (сортировка, поиск, фильтрация, выгрузка в файл и т.д.), достаточно просто написать SQL-запрос. Если требуется реализовать какое-то дополнительное свойство, нужно писать соответствующий обработчик.
Поскольку код приложения хранится в таблицах БД, то инсталляция сводится к созданию в целевой БД требуемой структуры данных и переносу содержимого таблиц с кодом.
Доработка приложения под конкретного клиента может осуществляться двумя способами.
Первый способ (дополнительные сегменты кода) позволяет дополнить обработчики существующих объектов серийной версии собственными фрагментами кода, которые система на этапе исполнения встроит в код обработчика перед ним, после него либо вместо него.
Второй способ (замещение объектов) позволяет полностью заменить объект серийной версии собственным объектом, либо создать собственный объект с нуля. В частности, можно заменить объект меню, добавив в него собственные пункты, к которым прицепить целый набор собственных объектов.
В обоих случаях, как дополнительные сегменты, так и объекты замещения, можно связывать с пользователями БД (или ролями). Т.е. можно создать несколько разных версий одного и того же объекта, каждый из которых будет исполняться только для определенного пользователя (или роли).
Все такие объекты хранятся отдельно от объектов серийной версии, поэтому обновление серийной версии их не затрагивает. Вместо этого формируется протокол изменений, по которому сопровождающий программист может определить, что ему нужно протестировать или доработать. Если изменения в серийной версии не затронули наработок сопровождающего программиста, то ему ничего не нужно делать, т.к. система автоматически подхватит его объекты.
Распространять такие наработки можно путем выгрузки в экспортный файл и загрузки в целевую БД.
Архитектурно платформа состоит из трех основных частей: среда разработки, среда исполнения и репозиторий
Среда разработки (RP Designer) предназначена для создания приложений. Ее можно сравнить с Visual Studio. Приложение, созданное программистом в среде разработки, помещается в репозиторий.
Репозиторий (RP Repository) представляет собой БД под управлением Microsoft SQL Server. Эта же БД кроме приложения может содержать и целевую схему данных, с которой работает само приложение. Т.е. получаем в одной базе и пользовательские данные, и приложение, которое их обрабатывает.
Среда исполнения (RP Runtime) предназначена для исполнения приложений, хранящихся в репозитории. Фактически, это то, что принято называть толстым клиентом, поскольку система клиент-серверная. Трехзвенную архитектуру можно реализовать через терминальный доступ.
Разработка
Среда разработки позволяет создавать объекты нескольких типов: списки, диалоги, меню, процедуры и др. Из этих объектов и строится приложение.
Для управления объектами используется встроенный язык (x-язык), который является интерпретируемым языком.
Каждый объект имеет собственное множество обработчиков событий. Многие из них имеют реализацию по умолчанию, поэтому в типовых случаях их реализация не требуется. Например, чтобы создать список со всеми характерными для списков свойствами (сортировка, поиск, фильтрация, выгрузка в файл и т.д.), достаточно просто написать SQL-запрос. Если требуется реализовать какое-то дополнительное свойство, нужно писать соответствующий обработчик.
Инсталляция
Поскольку код приложения хранится в таблицах БД, то инсталляция сводится к созданию в целевой БД требуемой структуры данных и переносу содержимого таблиц с кодом.
Кастомизация
Доработка приложения под конкретного клиента может осуществляться двумя способами.
Первый способ (дополнительные сегменты кода) позволяет дополнить обработчики существующих объектов серийной версии собственными фрагментами кода, которые система на этапе исполнения встроит в код обработчика перед ним, после него либо вместо него.
Второй способ (замещение объектов) позволяет полностью заменить объект серийной версии собственным объектом, либо создать собственный объект с нуля. В частности, можно заменить объект меню, добавив в него собственные пункты, к которым прицепить целый набор собственных объектов.
В обоих случаях, как дополнительные сегменты, так и объекты замещения, можно связывать с пользователями БД (или ролями). Т.е. можно создать несколько разных версий одного и того же объекта, каждый из которых будет исполняться только для определенного пользователя (или роли).
Все такие объекты хранятся отдельно от объектов серийной версии, поэтому обновление серийной версии их не затрагивает. Вместо этого формируется протокол изменений, по которому сопровождающий программист может определить, что ему нужно протестировать или доработать. Если изменения в серийной версии не затронули наработок сопровождающего программиста, то ему ничего не нужно делать, т.к. система автоматически подхватит его объекты.
Распространять такие наработки можно путем выгрузки в экспортный файл и загрузки в целевую БД.