Общие сведения о разработке на IS-Builder

12 13

Это первая статья из цикла, в котором будут рассмотрены базовые знания по разработке на IS-Builder. Этот  курс не заменяет курс по разработке и справочные материалы, но позволяет начать самостоятельное изучение системы и модификации системы с помощью IS-Builder.

ISBL,  IS-BUILDER LANGUAGE - встроенный в IS-Builder высокоуровневый язык программирования, предназначенный для описания алгоритмов работы прикладных задач.

Для успешного программирования на ISBL и решения прикладных задач важно понимание архитектуры системы DIRECTUM и программной модели платформы IS-Builder.

DIRECTUM – клиент-серверное приложение, поэтому программные компоненты делятся на клиентские и серверные. В состав серверных программных компонент системы DIRECTUM в минимальном случае входит база данных под управлением СУБД Microsoft SQL Server, сервер сеансов и служба Workflow.

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

Платформа IS-Builder предлагает инструменты быстрого и удобного создания всех компонентов корпоративной системы электронного документооборота. Среди них справочники, карточки электронных документов, сценарии, типовые маршруты, их отдельные блоки и т.д. Для этого используются компоненты разработчика (располагаются в папке Компоненты/Утилиты разработчика):

 

 Компоненты для разработки справочников

Справочник - список определенных объектов (записей) с заданным набором реквизитов. Например, в системе определен справочник Работники, в котором хранятся данные о работниках. В качестве реквизитов (полей) записей заданы: Фамилия, Имя, Отчество, Дата рождения, Должность, Подразделение и т.д.

Для разработки и модификации справочников используется компонента Типы справочников, которая позволяет:

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

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

Компоненты для разработки карточек электронных документов

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

Компоненты для разработки сценариев и отчетов

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

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

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

Компоненты для разработки функций

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

Компоненты для настройки типовых маршрутов

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

В маршрутах могут использоваться роли (Регистратор договоров, Секретарь генерального директора  и т.д.), они задаются в компоненте Роли.

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

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

Компонента для настройки мастеров действий

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

Компонента для работы с константами

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

Компоненты для экспорта/импорта разработки

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

Прочие компоненты

Компонента Выполнить внешний сценарий предназначена для выполнения сценариев на языке ISBL, которые хранятся в виде текстовых файлов вне системы DIRECTUM. Используется для выполнения разовых сценариев.

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

Более подробно разработка различных компонент с использованием описанных инструментов будет рассмотрена в следующих статьях.

Блокировка элементов разработки

С целью защиты элементов разработки от одновременного изменения несколькими разработчиками начиная с версии DIRECTUM 5.1 имеется возможность ставить на элементы разработки блокировку. Для внесения изменений в элемент разработки его необходимо заблокировать. Данная информация отображается в карточке элемента разработки:

Механизм блокировок доступен для следующих компонент: Отчеты, Сценарии, Функции ISBL, Блоки типовых маршрутов, Типы справочников, Типы карточек документов, Типовые маршруты, Мастера действий.

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

Андрей Подкин
DIRECTUM – клиент-серверное приложение
Не совсем так. Клиент-серверными называются приложения, построенные по двухзвенной архитектуре. А у DIRECTUM после появления службы Workflow архитектура стала трехзвенной.
 
В зависимости от того, где заданы вычисления, они выполняются либо на сервере, либо на клиенте.
Не совсем так. Один и тот же код, написанный в одном и том же месте может выполняться как на сервере (веб-доступа), так и на клиенте.
 
Компоненты для настройки
А чем настройка отличается от разработки? Или что компоненты для настройки делают в компонентах разработчика?
 
Компоненты для экспорта/импорта разработки
Они умеют экспортировать/импортировать все, что было перечислено в статье?
Антон Юминов
Не совсем так. Клиент-серверными называются приложения, построенные по двухзвенной архитектуре. А у DIRECTUM после появления службы Workflow архитектура стала трехзвенной.
Таки можно посмотреть иначе. 3-звенная архитектура - это когда бизнес-логика на специальном сервере. Клиент при этом разговаривает со вторым звеном и в БД напрямую не лезет. Как при использовании веб-доступа. DIRECTUM через веб-доступ - 3-звенная архитектура. Со службой Workflow - это 2.5-звенная в лучшем случае. У нас классический толстый клиент. Не нужно путать новых разработчиков. Они поймут 3-звенную архитектуру как ту самую, правильную 3-звенную smiley
Антон Юминов
Они умеют экспортировать/импортировать все, что было перечислено в статье?
Как я ни старался ни ТМы, ни мастера в ISX не экспортируются smiley. Может чего неправильно понимаю?
А чем настройка отличается от разработки? Или что компоненты для настройки делают в компонентах разработчика?
Таки, Андрей, ты прав. Нужно нам самим разобраться/договориться. Я слышал 2 точки зрения. Первая - настройка - это все, что можно сделать без лицензий разработчика. Вторая - настройка - это все, что можно сделать без написания кода, по крайней мере, без обращений из кода к объектной модели. Сам я склоняюсь ко второй точки зрения. Особенно с появлением мастеров. В мастерах действий и шагу нельзя ступить без написания кода, вовсю использующего объектную модель IS-Builder, следовательно называть разработку мастера действий настройкой как-то язык не поворачивается smiley
Мария Макарцева

А я делю разработку и настройку как раз по принципу можно ли это перенести с помощью утилит экспорта/импорта разработки. Если можно, то это разработка, а если надо переносить чем-то другим, то настройка.

Мария Макарцева

А еще можно делить на разработку и настройку используя описание Физической структуры данных из справки. В разделе Описание таблиц есть подразделы Таблицы разработки и Таблицы данных. Вот, например, таблица MBFunc находится в разделе Таблицы разработки и содержит функции, значит функции это разработка. А вот типовые маршруты и мастера хранятся в таблице MBAnalit, а это таблица данных, значит ТМ и мастера это настройка. Правда, чтобы использовать данный способ нужно знать какие объекты в каких таблицах хранятся, ну а если вы это знаете, то тем более знаете, что является разработкой, а что настройкой. wink  

Ксения Останина

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

Компоненты экспорта\импорта умеют экспортировать только разработку. О способах экспорта того, что не удается экспортировать этими компонентами (типовые маршруты, мастера действий и т.д.) постараемся рассказать в следующих статьях.

Андрей Подкин
Не нужно путать новых разработчиков.
Согласен. Именно поэтому нельзя объединять SQL-сервер с сервером Workflow. Разработка под Workflow больше похожа на клиентскую.
 
Первая - настройка - это все, что можно сделать без лицензий разработчика.
Это действительно так.
 
А я делю разработку и настройку как раз по принципу можно ли это перенести с помощью утилит экспорта/импорта разработки.
И это тоже правильно.
А еще - разработку можно локализовать.
 
О способах экспорта того, что не удается экспортировать этими компонентами (типовые маршруты, мастера действий и т.д.) постараемся рассказать в следующих статьях.
Это, конечно, очень хорошо. Но надо хотя бы намекнуть начинающему разработчику, что ему ждать. Прямо сейчас статья только одна. И после нее в голове получается каша.
Елена Лекомцева
 Не совсем так. Один и тот же код, написанный в одном и том же месте может выполняться как на сервере (веб-доступа), так и на клиенте.

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

Денис Баранов
А у DIRECTUM после появления службы Workflow архитектура стала трехзвенной.

А если добавить пару заданий шедулера, то будет 5-звенная! Ура! Наличие дополнительных специализированных клиентов, умеющих общаться как с сервером, так и с другими клиентами (workflow, агент DICS) не делает DIRECTUM трехзвенным. Вот если бы у нас клиент не общался напрямую с сервером, тогда да - была бы трехзвенка.
Андрей Подкин
Наличие дополнительных специализированных клиентов, умеющих общаться как с сервером, так и с другими клиентами (workflow, агент DICS) не делает DIRECTUM трехзвенным. Вот если бы у нас клиент не общался напрямую с сервером, тогда да - была бы трехзвенка.
Конечно, это не утка не делает. Просто это селезень, который крякает так же, как утка предоставляет Workflow (и другим и некоторым частям) те же преимущества над клиент-серверной архитектурой, что и классическая трехзвенка: масштабируемость, конфигурируемость, безопасность, надёжность.
Денис Баранов

А разве в классической трехзвенке каждое звено не является необходимым для работы системы? Если я не пользуюсь задачами (например, у меня построена система учета чего-нибудь на базе IS-Builder 7), то я могу совершенно полноценно работать вообще с отсутствующей службой Workflow. В чем заключается безопасность?

Да, работа клиента с Workflow похожа на трехзвенку. Но это означает лишь, что "некоторая часть системы DIRECTUM использует архитектуру, похожую на трехзвенную". А прямые клиент-серверные запросы никто не отменял. Значит, это клиент-сервер с "примочками сбоку". smiley Полезными, не спорю. Но не дающими права называть получившийся комплекс системой с трехзвенной архитектурой. Вот есть у нас агент DICS - тоже отдельная служба, тоже общается с базой данных. Почему ж тогда в итоге трехзвенная? Четырех, получается уже.

Андрей Подкин
Да, работа клиента с Workflow похожа на трехзвенку. Но это означает лишь, что "некоторая часть системы DIRECTUM использует архитектуру, похожую на трехзвенную".
Перевожу: Да, селезень крякает как утка. Но это означает лишь, что он похож на утку только по звукам. А вот по окрасу - непохож.
 
Вот есть у нас агент DICS - тоже отдельная служба, тоже общается с базой данных. Почему ж тогда в итоге трехзвенная? Четырех, получается уже.
Да хоть 100500. Смысл в звеньях только один. Убрать логику
а) с машины пользовтаеля
б) с SQL-сервера.
Чтобы можно было независимо от них обслуживать и получать с этого профит.
Денис Баранов

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

Да хоть 100500

Ну так бы и написал - "у системы DIRECTUM стопицотзвенная архитектура". Все бы сразу твои реплику ценили как она того заслуживает, никто бы и слова не сказал. wink

Авторизуйтесь, чтобы написать комментарий