Workflow

НАЧАЛО >> Workflow >> Модули Workflow >> Workflow📄 Скачать в DOCX

Модуль Workflow является ядром подсистемы рабочих процессов. Он хранит записи типа WORKFLOW, выполняет переходы, проверяет условия, запускает post-function и ведет историю действий в стандартном поле 907.

1. Запись WORKFLOW

Запись workflow описывает сам рабочий процесс: ключ, название, активность и описание. Состав статусов, переходов, экранов, фильтров и представлений хранится в отдельных модулях и связывается с workflow по ключу.

Поле	Назначение
`920`	тип записи `WORKFLOW`
`1^A`	ключ workflow
`1^B`	название
`1^C`	активность
`1^D`	описание

2. Состояние записи

Состояние прикладной записи хранится в поле 113 с типом связи WORKFLOW. В одном экземпляре поля фиксируются workflow, владелец состояния и текущий статус. За счет повторяемости поля одна запись может участвовать в нескольких workflow одновременно.

Workflow не должен знать внутреннюю структуру прикладного типа записи. Поиск записи по внешнему идентификатору, workflow для v920, проектный тип объекта и схемы интерфейса определяются проектом WorkflowProject.

3. Исполнение перехода

Основной метод для кода приложения - ApplyRecordTransition(). Он получает базу, запись, проект и переход либо целевой статус. Перед сохранением модуль:

определяет текущее состояние записи в контексте проекта;
проверяет, разрешен ли переход из текущего статуса;
выполняет condition-формат, если он указан в переходе;
применяет данные формы he3, если переход открывался через экран;
меняет поле 113;
выполняет post-function;
записывает историю в поле 907;
сохраняет запись штатным механизмом ИРБИС 128.

Для UI, API и массовых операций до выполнения перехода следует использовать ExplainRecordTransition() или DryRunRecordTransition().

ExplainRecordTransition() возвращает единый диагностический ответ: разрешен ли переход, какой diagnosticCode получен, какие проверки пройдены, какие причины отказа есть, какой экран потребуется и какие post-functions будут запланированы.

DryRunRecordTransition() использует тот же набор проверок на копии записи и показывает будущий workflow-state без сохранения записи и без выполнения post-functions.

GetWorkflowImpactAnalysis() показывает where-used workflow: связанные проекты, статусы, переходы, экраны, схемы, фильтры, представления и количество записей с материализованным состоянием этого workflow.

4. Conditions

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

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

5. Post-Functions

Workflow поддерживает два типа post-function:

Тип	Назначение
`gbl`	выполнение выбранного GBL-сценария из MNU whitelist
`command`	вызов workflow-команды прикладного модуля

Команды вызываются через __call/Workflow и получают WorkflowContext. Возврат выполняется через WorkflowCommandResult.

6. Системные записи

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

Синхронизация поставляемых JSON-конфигураций выполняется отдельной __call-функцией SyncSystemDefinitions.