Это первая статья из цикла, в котором будут рассмотрены базовые знания по разработке на 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. Для контроля изменений в разработке при экспорте или импорте появился флажок Снимать мои блокировки.
А я делю разработку и настройку как раз по принципу можно ли это перенести с помощью утилит экспорта/импорта разработки. Если можно, то это разработка, а если надо переносить чем-то другим, то настройка.
А еще можно делить на разработку и настройку используя описание Физической структуры данных из справки. В разделе Описание таблиц есть подразделы Таблицы разработки и Таблицы данных. Вот, например, таблица MBFunc находится в разделе Таблицы разработки и содержит функции, значит функции это разработка. А вот типовые маршруты и мастера хранятся в таблице MBAnalit, а это таблица данных, значит ТМ и мастера это настройка. Правда, чтобы использовать данный способ нужно знать какие объекты в каких таблицах хранятся, ну а если вы это знаете, то тем более знаете, что является разработкой, а что настройкой.
В статье я постаралась указать компоненты, которые в любом случае пригодятся разработчику. Пусть официально ТМ и мастера действий - это настройка, но разработчику нужно уметь их разрабатывать.
Компоненты экспорта\импорта умеют экспортировать только разработку. О способах экспорта того, что не удается экспортировать этими компонентами (типовые маршруты, мастера действий и т.д.) постараемся рассказать в следующих статьях.
Об этом надо помнить. Так как вывод сообщений в событиях на клиенте отработается корректно, а при отработке на сервере веб-доступа произойдет исключение.
это не уткане делает. Простоэто селезень, который крякает так же, как уткапредоставляет Workflow (и другим и некоторым частям) те же преимущества над клиент-серверной архитектурой, что и классическая трехзвенка: масштабируемость, конфигурируемость, безопасность, надёжность.А разве в классической трехзвенке каждое звено не является необходимым для работы системы? Если я не пользуюсь задачами (например, у меня построена система учета чего-нибудь на базе IS-Builder 7), то я могу совершенно полноценно работать вообще с отсутствующей службой Workflow. В чем заключается безопасность?
Да, работа клиента с Workflow похожа на трехзвенку. Но это означает лишь, что "некоторая часть системы DIRECTUM использует архитектуру, похожую на трехзвенную". А прямые клиент-серверные запросы никто не отменял. Значит, это клиент-сервер с "примочками сбоку". Полезными, не спорю. Но не дающими права называть получившийся комплекс системой с трехзвенной архитектурой. Вот есть у нас агент DICS - тоже отдельная служба, тоже общается с базой данных. Почему ж тогда в итоге трехзвенная? Четырех, получается уже.
Ага, самолет и вертолет оба летают, значит допустимо самолет называть вертолетом. Основные функции похожи, значит можно вертеть терминологией как вздумается. Новое слово в семантике - говорю Манчестер, подразумеваю Ливерпуль. И то и другое - города, какая к черту разница.
Авторизуйтесь, чтобы написать комментарий