Выполнение переходов и страниц

НАЧАЛО >> Workflow >> Выполнение переходов и страниц📄 Скачать в DOCX

1. Выполнение перехода

Обычный путь выполнения перехода:

  1. Прикладной код получает проект ObjectDataWorkflowProject.
  2. Определяется системный тип записи из поля 920 и, если он уже есть, проектный тип объекта из 113^I.
  3. Проект выбирает workflow для этого типа записи.
  4. Workflow определяет текущий статус записи из поля 113; если записи состояния нет, используется начальный статус проектного типа объекта или начальный статус проекта.
  5. По статусу, ключу перехода или целевому статусу выбирается ObjectDataWorkflowTransition.
  6. Проверяются активность перехода, маршрут, право ALLOWAPPLY и condition-формат; тот же набор проверок доступен через ExplainRecordTransition().
  7. Если переход требует экран, сначала открывается Workflow/WorkflowScreen, затем he3 сохраняет данные в черновик и вызывает Workflow/ApplyWorkflowScreen.
  8. Если у перехода указан approvalGateKey, WorkflowApproval создает request и останавливает выполнение до согласования. После положительного решения continuation запускает тот же переход с повторной проверкой статуса, route, condition, прав и версии настроек.
  9. Workflow обновляет состояние в 113.
  10. Выполняются post-functions перехода.
  11. В поле 907 добавляется история.
  12. Запись сохраняется через штатное сохранение БД или через переданный callback.

Основные публичные методы:

Метод Назначение
Workflow::GetRecordWorkflowStatus() Получить текущий статус записи в проекте
Workflow::ExplainRecordTransition() Получить объяснение доступности перехода: проверки, причины отказа, экран и план post-functions
Workflow::CanApplyRecordTransition() Проверить доступность перехода
Workflow::DryRunRecordTransition() Проверить переход без сохранения записи и выполнения post-functions
Workflow::ApplyRecordTransition() Найти и выполнить переход для записи
Workflow::ApplyTransition() Выполнить уже выбранный переход
Workflow::ValidateWorkflowScreen() Проверить экран перехода перед открытием he3
Workflow::GetWorkflowImpactAnalysis() Получить where-used и базовую оценку влияния workflow
Workflow::HealthCheck_Self() Выполнить self-check базового runtime-контракта Workflow

ExplainRecordTransition() возвращает машинно-читаемый результат с allowed, diagnosticCode, списком checks, списком причин reasons, описанием перехода, исходным и целевым статусом, требуемым экраном и планом post-functions. Этот метод следует использовать для диагностики кнопок, API, dry-run и сообщений пользователю. Он не изменяет запись.

DryRunRecordTransition() использует тот же набор проверок, но работает с копией записи: показывает будущий workflow-state, признак изменения статуса и причину отказа, если переход сейчас невозможен. Dry-run не сохраняет запись и не выполняет command/gbl post-functions.

GetWorkflowImpactAnalysis() предназначен для администрирования и HealthCheck. Он показывает, какие проекты используют workflow, сколько у него статусов, переходов, экранов, схем, фильтров, представлений и материализованных состояний записей. Это помогает оценить последствия изменения или удаления workflow до фактической правки.

2. Condition-форматы

Condition задается в WorkflowTransition как имя формата в поле 1^K. Формат выполняется через Format128 над копией текущей записи. В параметры форматирования передаются данные workflow: проект, переход, текущий статус, пользователь, входные параметры и другая служебная информация.

Переход разрешен, если формат возвращает непустое значение, которое не равно 0, false или нет. Отрицательный числовой результат считается ошибкой выполнения condition.

Для сложной логики лучше писать формат ИРБИС 128 в контейнере прикладного модуля. Это позволяет читать данные записи и параметры workflow без внесения дополнительных служебных полей в запись.

3. Экраны he3

Если у перехода указан screenKey, пользователь сначала заполняет экран Workflow. Запись WorkflowScreen связывает ключ экрана со схемой he3. Схема должна быть доступна в БД, с которой работает запись.

Экран может быть полным .ws или частичным .wss. Для .wss в записи экрана указывается поле записи; при применении черновика Workflow меняет только подполя из WSS и сохраняет остальные подполя этого поля. Если обычный .ws содержит поле с вложенной .wss-секцией, это поле также применяется частично по подполям вложенной WSS.

Экран выполняется штатным механизмом he3:

4. Согласования WorkflowApproval

Переход может требовать формального согласования, если в WorkflowTransition заполнено поле 1^L с ключом WorkflowApprovalGate. Gate выбирает WorkflowApprovalPolicy, режим применения, condition-формат, экраны действий и параметры continuation.

При первом запуске такого перехода Workflow не меняет статус записи. WorkflowApproval создает WorkflowApprovalRequest, сохраняет безопасный snapshot данных экрана, участников, route и версий настроек. После выполнения policy request получает состояние approved, rejected, cancelled или остается waiting.

Continuation не является слепым продолжением старого действия: перед изменением записи Workflow заново проверяет текущий статус, маршрут, condition, права и параметры перехода. Если контекст записи изменился несовместимо, request должен перейти в состояние, требующее нового запуска перехода.

5. Post-functions

Post-functions хранятся в поле 2 записи WorkflowTransition и выполняются после изменения состояния, но до сохранения записи. Поддерживаются типы:

Тип Настройка Назначение
command ключ команды из __call/Workflow прикладного модуля Выполнение PHP-логики прикладного модуля
gbl MNU whitelist и ключ GBL-сценария Выполнение сценария глобальной корректировки над рабочей копией записи

Если post-function возвращает ошибку, Workflow откатывает рабочую запись к исходной копии и не сохраняет результат перехода.

6. Универсальные страницы

WorkflowView умеет строить страницы списков, карточек, форм создания и досок по настройкам. Пользовательский вход в эти страницы выполняется через единый маршрут Workflow/Show.

Метод Назначение
Page_RenderConfiguredPage() Полная страница с выбором renderer по viewType
List_RenderConfiguredListPage() Полная страница списка по проекту, типу записи и pageKey
Card_RenderConfiguredRecordPage() Полная страница карточки записи
Create_RenderConfiguredCreatePage() Полная страница создания записи
Board_RenderConfiguredBoardPage() Полная страница Kanban/timebox-доски
Navigation_RenderConfiguredNavigation() Верхняя навигация и панель фильтров для страницы
List_RenderConfiguredList() HTML списка без внешней обертки страницы
Card_RenderConfiguredRecord() HTML карточки без внешней обертки страницы

Связка страниц работает так:

  1. WorkflowViewScheme по pageKey выбирает представление.
  2. WorkflowView строит верхнюю навигацию только по страницам активной WorkflowViewScheme; одноименная группа представлений в поле 1^R задает, какие пункты выводятся в одной панели.
  3. Представление типа list выбирает фильтр из своего поля 1^I или через WorkflowFilterScheme.
  4. WorkflowFilter строит поисковое выражение и описывает доступные элементы панели фильтрации.
  5. WorkflowView выводит строки через форматы колонок.
  6. Клик по строке ведет на detailPageKey через Workflow/Show.
  7. Представление типа detail выводит секции карточки и секцию действий Workflow.
  8. Представления типа kanban и timebox используют вложенную настройку board.

Представление типа page не строит список или карточку. Оно используется как настраиваемый пункт навигации для внешней прикладной страницы, например страницы создания новой записи. Такая страница может вызвать RenderConfiguredNavigation(), чтобы получить тот же набор ссылок, что и списки проекта.

Такой механизм позволяет прикладному модулю описывать пользовательские страницы в WorkflowViewScheme без собственных wrapper-страниц. Одинокая запись WORKFLOWVIEW с заполненной группой навигации сама по себе не добавляет пункт меню, пока на нее не ссылается схема представлений проекта.