Настройка типовых маршрутов

Опубликовано:
1 июля 2011 в 09:00

23 0

Введение

Данная статья продолжает цикл статей для начинающего разработчика на ISBL.

Предыдущие статьи раскрыли следующие моменты:

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

Теория

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

А они бывают двух видов:

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

В жестких типовых маршрутах есть события (Начало выбора, Завершение выбора и Возможность старта).

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

Событие "Завершение выбора". Вычисления в этом событии срабатывают после запроса запрашиваемых параметров. Здесь уже обрабатываются запрошенные параметры и прочие вычисления.

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

Начиная с DIRECTUM 5.1 в жестких типовых маршрутах появились два новых события: "Возможность прекращения" и "Прекращение", позволяющие:

задавать сложные условия возможности или запрета прекращения задачи,
очищать ресурсы при прекращении задачи,
отправлять уведомления ответственным при прекращении задачи, например — уведомлять администратора о прекращении задачи из-за ошибки.

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

Много раз упомянул параметры типового маршрута.

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

Будем считать, что теории достаточно. Вернемся к нашей задаче.

Описание процесса

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

Создается карточка запроса.
Задание руководителю подразделения работника – заполняет доступ к какому ПО нужно, тип прав доступа.
Создается документ на основе отчета «Права доступа работника» с ТКЭД « «Запрос на назначение прав доступа работнику».
Задание руководителю IT-отдела – согласует, подписывает его ЭЦП.
Задание администратору – задание на заведение пользователей, предоставление прав доступа, подготовку раб. места.
Уведомление руководителю подразделения.

Проанализируем поступившую информацию и набросаем в голове типовой маршрут.

Название типового маршрута будет «Согласование запроса на назначение прав доступа». Тип – жесткий.

При выборе типового маршрута необходимо запрашивать параметры Работник и Дата выхода.

Разберем каждый из этапов:

Создается карточка запроса – на схеме будет блок типа Сценарий. В вычислениях блока будет создаваться запись справочника «Права доступа работников на ПО». Значения карточки будут заполняться из параметров задачи.
Задание руководителю подразделения работника – блок типа Задание.
Создается документ на основе отчета – блок типа Сценарий. Будет запускаться отчет «Права доступа работника» и сохраняться в документ с типом карточки «Запрос на назначение прав доступа работнику», документ будет вкладываться в задачу.
Задание руководителю IT-отдела – блок типа Расширенное задание. При выполнении задания поставим проверку ЭЦП на созданном документе на предыдущем этапе.
Задание администратору – блок типа Задание.
Уведомление руководителю подразделения – блок типа Уведомление.

Всё вроде понятно. Можно приступать.

Создание типового маршрута

Запускаем проводник системы и переходим в папку Компоненты – Утилиты администратора – Общее администрирование и запускаем компоненту «Типовые маршруты».

Создаем новую запись как показано на рисунке:

Как видим в карточке типового маршрута есть помимо стандартных кнопок две новые:

Параметры – откроется окно для заполнения параметров типового маршрута. Также это окно можно будет вызвать из схемы маршрута;

Схема – откроется графический редактор схемы.

Параметры типового маршрута

Для начала заполним параметры ТМ.

Мы точно знаем, что нам понадобятся параметры «Работник» и «Дата выхода на работу», но если посмотреть на карточку записи справочника «Права доступа работников на ПО»:

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

Таким образом, параметры типового маршрута будут выглядеть так:

Остановимся только на параметре «Работник». Если нажать на кнопку …, то откроется окно свойств параметра:

Для того чтобы всё правильно работало, указываем справочник Работники и ставим галочку «Скрывать закрытые записи».

Нажимаем кнопку ОК, затем Сохранить в карточке маршрута.

Схема типового маршрута

Открываем схему по кнопке Схема и видим такую картину:

В таком виде маршрут, естественно, не будет работать.

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

Указываем для запроса все параметры:

Параметр обязательный означает, что без указания значений не удастся завершить выбор ТМ.

Закрываем, сохраняем схему по кнопке . Первая кнопка сохранит схему без закрытия схемы, вторая – с закрытием.

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

Хорошо. Параметры для запроса указали. Теперь при выборе ТМ в карточке задачи вы увидите:

Продолжаем настройку ТМ. Теперь укажем свойства задачи такие как Тема и Текст.

Впишем следующее:

Тема: Необходимо согласовать запрос на предоставление прав доступа к ПО для нового работника

Текст: Согласуйте запрос на предоставление прав доступа к ПО для нового работника.

Остальные свойства задачи оставляем по умолчанию.

Сохраняем схему.

Теперь переходим уже непосредственно к рисованию схемы.

Как было описано выше, на схеме будет 6 блоков помимо «Начало» и «Конец».

Переходим на вкладку «Блоки».

1. Создание карточки запроса.

Перетаскиванием добавляем в схему блок типа Сценарий.

Выделяем блок и видим свойства блока слева:

Пишем наименование блока «Создание карточки запроса», а также замечаем такое свойство как «Вычисление». При нажатии на кнопку … в значении этого свойства откроется окно редактора кода на ISBL. Необходимо написать такой код, который создаст запись справочника Права доступа работников на ПО, заполнит реквизиты из параметров задачи, сохранит запись и вложит в задачу.

Вот этот волшебный код:

// Сохранить текущий контекст нашей организации
 OurFirmCode = GetOurFirmContext()

 // Установить контекст нашей организации ООО Мобил Авто
SetOurFirmContext("ООО")

 // Создать новую запись справочника
UserPermissionsRec = References.UserPermissions.CreateNew
// Получить значение параметра задачи Работник
EmployeeID = ТМПолучитьПараметрЗадачи("Работник")
// Заполнить реквизит Работник
EmployeeRec = References.РАБ.GetObjectByID(EmployeeID)
UserPermissionsRec.Работник = EmployeeRec.SYSREQ_CODE
// Получить значение параметра задачи Логин
Login = ТМПолучитьПараметрЗадачи("Логин")
// Заполнить реквизит Логин
UserPermissionsRec.Реквизит = Login
// Получить значение параметра задачи ДатаВыхода
Date = ТМПолучитьПараметрЗадачи("ДатаВыхода")
// Заполнить реквизит Приступает к работе с
UserPermissionsRec.Дата = Date

 // Сохранить запись справочника
UserPermissionsRec.Save

 // Вложить запись справочника в задачу
ТМДобавитьВложение("ЗаписьСправочника"; UserPermissionsRec.SYSREQ_ID)

// Восстановить контекст нашей организации
SetOurFirmContext(OurFirmCode)

2. Задание руководителю подразделения работника.

Перетаскиваем в схему блок типа Задание. Что нам нужно знать про блоки задания? Задание должно приходить конкретному исполнителю или исполнителям. У нас это должен быть руководитель подразделения, в которое принимают работника. Как вы наверное догадались, то это не один человек и наша задача научиться определять правильного исполнителя задания. И тут к нам на помощь приходят… нет, не Чип и Дейл, а Роли типовых маршрутов.

Немного теории. Роли указываются в качестве исполнителей блоков типовых маршрутов и хранятся в справочнике Роли.

Роли бывают:

статическими. Исполнители перечисляются в карточке статической роли. Например, Генеральный директор;
вычисляемыми. Исполнители получаются путем вычисления. Например, Руководитель инициатора задачи. Такие роли повышают гибкость типовых маршрутов, позволяя вычислять исполнителей, вместо того, чтобы создавать несколько типовых маршрутов или запрашивать исполнителей у инициатора.

Особенности использования ролей:

настройка вычисляемых ролей – задача разработчика;
вычисляемая роль должна опираться на содержимое базы данных DIRECTUM, в частности – на то, что в задаче присутствует вложение нужного типа, или на организационную структуру предприятия;
исполнители вычисляемой роли определяются в момент срабатывания соответствующего блока типового маршрута;
статические роли заполняются в момент их создания: в табличной части указываются исполнители роли. В дальнейшем, как правило, они актуализируются администратором системы.

Очевидно, что нам понадобится вычисляемая роль «РуководительРаботника». Создаем в справочнике Роли новую запись как на рисунке:

Нажимаем на кнопку Вычисление и вставляем код:

// Параметры ТМ 
  Params = Sender.WorkFlowParams
  EmployeeCode = Params.ValueByName("Работник").Value.Code

  // Получить запись работника
  Employee = References.РАБ.GetObjectByCode(EmployeeCode)

  // Получить Подразделение работника
  DepartCode = Employee.Подразделение
  ChiefCode = GetRequisiteValueAsString("ПОД"; DepartCode; "Работник")

  // Если руководитель указан, то получить пользователя и добавить в исполнители роли
  if Assigned(ChiefCode)
    UserName = СетевоеИмяПоКодуРаботника(ChiefCode)
    if Assigned(UserName)
      ТМДобавитьИсполнителяРоли(Result; UserName)
    endif
  endif

Сохраняем карточку роли.

Переходим в схему ТМ и выбираем в добавленном задании эту роль в качестве исполнителя.

Заполняем свойства блока.

Наименование: Задание руководителю подразделения работника

Тема: Необходимо заполнить карточку запроса на доступ к ПО

Текст: Заполните карточку запроса доступа к ПО.

Сохраняем схему ТМ.

Продолжение следует...

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

Пока комментариев нет.

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