Настройка политик повторного вызова -

Документация пользователя

Работа с данными

Интеграционные сервисы

Управление

Управление процессами

Служебные технологические сервисы

Предоставление кворумного ЦОД

Интеграция с инфраструктурой электронного правительства

Производственный процесс

Демопримеры

Синтетика

Интеграционные шлюзы

Эксплуатационная документация

Часто задаваемые вопросы

Глоссарий

Главная

Управление процессами

1.12 Engine Platform V Flow

Настройка политик повторного вызова

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

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

Каждый XML-файл содержит перечень моделей (RetryPolicyModel) политик повторных вызовов для процесса. Каждая модель создается с обязательным указанием businessFamily, для которой она разработана.

Каждая политика повторного вызова (RetryPolicy) представляет стратегию исполнения повторного вызова (RetryStrategy), т.е. алгоритм, по которому будет проведен повторный вызов шага процесса.

Стратегия	Описание	Приоритет отработки

Adaptive	Адаптивный повторный вызов - не настраивается в файле, срабатывает автоматически	1
Linear	Линейный повторный вызов - задается количество попыток и интервал срабатывания	2
Interval	Интервальный повторный вызов - задается размер и количество интервалов для срабатывания	2
Manual	Ручной повторный вызов — задается количество попыток, предоставляемых пользователю для проведения повторной операции	3

XML-файл может содержать несколько блоков RetryPolicyModel, каждый из которых содержит внутри себя не ограниченное количество политик RetryPolicy. Пример файла с политиками повторного вызова представлен ниже.

Раскрыть type=xml
<xs:retryPolicyModels xmlns:xs="http://domain.ru/bpms/retryPolicy" businessFamily="dul_family">
    <xs:retryPolicyModel description="Политика Retry ДЮЛ" id="DULRetryPolicy">
        <!-- id модели используется для связи с тасками, для которых она будет применима -->
        <xs:retryPolicies>
            <xs:retryPolicy description="Политика для TransportTimeoutException">
                <xs:exceptions>
                    <!--Список исключений, на которые нужно реагировать-->
                    <xs:exception>com.sbt.core.amqp.exceptions.TransportTimeoutException</xs:exception>
                    <xs:exception>com.sbt.core.amqp.exceptions.TransportNoRouteException</xs:exception>
                    <xs:exception>com.sbt.core.amqp.exceptions.UnavailableServiceException</xs:exception>
                    <xs:exception>com.sbt.core.amqp.exceptions.TransportException</xs:exception>
                    <xs:exception>com.sbt.pprb.ac.common.exception.CdmWrappedException</xs:exception>
                </xs:exceptions>
                <xs:retryStrategy>
                    <xs:linear>
                        <!-- задать количество повторных попыток и интервал -->
                        <xs:count>3</xs:count>
                        <xs:timeout>PT1M</xs:timeout>
                    </xs:linear>
                </xs:retryStrategy>
            </xs:retryPolicy>
        </xs:retryPolicies>
    </xs:retryPolicyModel>
</xs:retryPolicyModels>

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

Информация о шагах процессов, для которых указаны политики повторного вызова, сохраняется автоматически и доступна пользователю для просмотра на вкладке Просмотр Retry Policy.

Настройка триггеров срабатывания политик

Для каждой стратегии автоматического повторного вызова (Linear, Interval) и ручного (Manual) должен быть указан триггер, т.е. правило срабатывания политики — перехваченная ошибка или конкретное значение переменной контекста.

Список возможных триггеров:

exception — тип исключения;
exceptionMessage — сообщение, возвращаемое при наступлении ожидаемого исключения;
errorExpressions — обработка определенных значений, возвращаемых в контекст в процессе исполнения модели. Необходимо указать переменную или тег @RESULT для получения значения, полученного на текущем шаге, а также значение, на соответствие с которым будет выполняться проверка.

XML-файл с настройкой триггеров представлен ниже.

Раскрыть type=xml
<xs:exceptions>
   <xs:exception>java.lang.IllegalStateException</xs:exception>
   <xs:exception>java.lang.IllegalArgumentException</xs:exception>
   <xs:exception>MakeExceptionGreatAgain</xs:exception>
   <xs:exception>org.activiti.engine.ActivitiException</xs:exception>
</xs:exceptions>
<xs:exceptionMessages>
   <xs:exceptionMessage>some ExceptionMessage</xs:exceptionMessage>
</xs:exceptionMessages>
<xs:errorExpressions>
   <xs:errorExpression>
      <xs:expression>@RESULT.text</xs:expression>
      <xs:value>100</xs:value>
   </xs:errorExpression>
   <xs:errorExpression>
      <xs:expression>@RESULT.text</xs:expression>
      <xs:value>-1</xs:value>
   </xs:errorExpression>
   <xs:errorExpression>
      <xs:expression>#{counter}</xs:expression>
      <xs:value>6</xs:value>
   </xs:errorExpression>
</xs:errorExpressions>

Стратегия Adaptive

Адаптивный повторный вызов срабатывает автоматически при получении следующих ошибок:

временно недоступен: по ММТ - No API, для HTTP — 503 Service Unavailable.
превышение допустимой нагрузки: по ММТ - No Resources, для HTTP — 429 Too Many Requests.

Этот тип повторного вызова срабатывает только в том случае, если эти ошибки не переопределены в модели политики. В противном случае по этим ошибкам будет использоваться та политика повтора, которая указана в модели.

Если при вызове сервиса произошла ошибка, то срабатывает адаптивный повторный вызов и создается сущность в базе данных с временем ожидания (указано в конфигураторе на текущий момент) — engine.no.api.wait.time (для No API), engine.no.resources.wait.time (для No Resources). Также данное API помещается в список ограничения blockApi. Все другие элементы, что вызывают этот сервис, также будут создавать сущности без попытки вызвать данное API. По истечении заданного времени в конфигураторе процесс попробует снова исполнить сервис. В случае успеха API будет удалено из списка blockApi, в противном случае - будет создана сущность снова. Максимальное время попыток ограничивается значениями engine.no.api.maximum.time и engine.no.resources.maximum.time для no api и no resources соответственно.

Количество попыток не ограничено. Ограничивается только максимальное время.

Настройки для исполнения адаптивного повторного вызова указываются в файле application.yml в блоке Engine.

Стратегия Linear

Для задания линейного повторного вызова необходимо в XML-файле добавить соответствующий блок и указать:

максимальное количество попыток;
интервал вызова сервиса.

Раскрыть type=xml
<xs:retryStrategy>
    <xs:linear>
        <xs:count>3</xs:count>
        <xs:timeout>PT1S</xs:timeout>
    </xs:linear>
</xs:retryStrategy>

Алгоритм обработки блока:

По истечении заданного количества попыток будет проброшено исключение (exception), и шаг будет завершен.
При срабатывании линейного повторного вызова после другого вызова (другая политика, в том числе линейная) сбрасывается счетчик количества попыток.

Стратегия Interval

Для задания интервального повторного вызова необходимо в XML-файле добавить соответствующий блок и последовательно указать необходимые интервалы повторного вызова сервиса:

Раскрыть type=xml
<xs:retryStrategy>
    <xs:intervals>
        <xs:interval>PT1S</xs:interval>
        <xs:interval>PT2S</xs:interval>
        <xs:interval>PT10S</xs:interval>
    </xs:intervals>
</xs:retryStrategy>

Алгоритм обработки блока следующий:

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

Стратегия Manual

Для создания ручного повторного вызова необходимо в XML-файле добавить соответствующий блок и указать следующее:

максимальное время, при котором доступен ручной повторный вызов;
количество попыток для повторного вызова сервиса вручную пользователем.

Раскрыть type=xml
<xs:retryStrategy>
    <xs:manual>
        <xs:maxRetryTime>PT10S</xs:maxRetryTime>
        <xs:count/>
    </xs:manual>
</xs:retryStrategy>

Алгоритм обработки блока:

Ручной повторный вызов доступен для вызова заданным временем maxRetryTime. По истечении данного времени будет проброшено исключение (exception). Данная политика срабатывает, если не заданы иные политики либо после исполнения автоматических вызово (Linear, Adaptive, Manual). Исполнение данной политики происходит путем вызова API BPM на портале во вкладках Контроль Инцидентов или в шагах процесса в Контроль Исполнения. Также вызов доступен при вызове публичного API BPM Long retryProcessInstances(List<String> processInstanceIds).
При создании сущности ручного вызова также отправляется MMTEvent RetryEvent с набором полей, в которых описана вся необходимая информация о том месте, где возникла ошибка.

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

Предыдущий раздел

Методы класса BpmsEnginePluggableActivitiTestCase

Следующий раздел

Стартовые события

Была ли страница полезной?

docs_gostech@sberbank.ru