YY
В листенерах идёт обращение к переменным, которые ещё не получили в принципе (потому как они вычисляются на предыдущем степе).
Size: a a a
2020 May 18
SD
Мне кажется, формулировка "кажется" не самый лучший подход при работе с компьютерными технологиями)))) вы уверены что они действительно вызываются? И вызываются именно там, где вы думаете? И в другие места их не прикрутили?)
YK
может сервис таск нужно передвинуть за шлюз? то есть только после получения одобрения чтобы срабатывал
YY
del
YY
Мне кажется, формулировка "кажется" не самый лучший подход при работе с компьютерными технологиями)))) вы уверены что они действительно вызываются? И вызываются именно там, где вы думаете? И в другие места их не прикрутили?)
Нашёл на схеме, почему случается ошибка, но её природу понять не могу.
Оказалось, дело вовсе не в листенерах, а в output'ах.
Оказалось, дело вовсе не в листенерах, а в output'ах.
НА
Ребята, привет, подскажите, пожалуйста, где можно найти нормальный RFI для bpm-системы?
SD
Нашёл на схеме, почему случается ошибка, но её природу понять не могу.
Оказалось, дело вовсе не в листенерах, а в output'ах.
Оказалось, дело вовсе не в листенерах, а в output'ах.
👍
НА
Облазил всё и вся, ничего нормального не смог найти
YY
Проблема такая:
В вызываемой активности есть externalTask, который должен после выполнения положить определённый результат в output, но выполниться (а если точнее, даже запуститься), он ещё не успел. Соответственно, никакого результата в output переменную в нём мы положить не можем.
Вопрос остаётся почти тот же: Камунда пытается смапить все переменные, даже если сама принудительно завершила активность, нормальное ли это поведение? И если да, как это можно исправить?
Маппинг переменной в outputParameters прописан как обычный sourceExpression.
В вызываемой активности есть externalTask, который должен после выполнения положить определённый результат в output, но выполниться (а если точнее, даже запуститься), он ещё не успел. Соответственно, никакого результата в output переменную в нём мы положить не можем.
Вопрос остаётся почти тот же: Камунда пытается смапить все переменные, даже если сама принудительно завершила активность, нормальное ли это поведение? И если да, как это можно исправить?
Маппинг переменной в outputParameters прописан как обычный sourceExpression.
НА
Или если есть у кого-нибудь пример, вы не могли бы поделиться, пожалуйста
DK
Или если есть у кого-нибудь пример, вы не могли бы поделиться, пожалуйста
что за RFI?
SD
Проблема такая:
В вызываемой активности есть externalTask, который должен после выполнения положить определённый результат в output, но выполниться (а если точнее, даже запуститься), он ещё не успел. Соответственно, никакого результата в output переменную в нём мы положить не можем.
Вопрос остаётся почти тот же: Камунда пытается смапить все переменные, даже если сама принудительно завершила активность, нормальное ли это поведение? И если да, как это можно исправить?
Маппинг переменной в outputParameters прописан как обычный sourceExpression.
В вызываемой активности есть externalTask, который должен после выполнения положить определённый результат в output, но выполниться (а если точнее, даже запуститься), он ещё не успел. Соответственно, никакого результата в output переменную в нём мы положить не можем.
Вопрос остаётся почти тот же: Камунда пытается смапить все переменные, даже если сама принудительно завершила активность, нормальное ли это поведение? И если да, как это можно исправить?
Маппинг переменной в outputParameters прописан как обычный sourceExpression.
А где она пытается смапить? В "ожидание approve"?
НА
Список функциональных требований к bpm системе
YY
А где она пытается смапить? В "ожидание approve"?
нет, в параллельной активности "Deploy on DEV" вызывается externalTask, который имеет output'ы. Вот для этого таска она их пытается смапить и падает.
Т.е. на уровне ниже даже.
Т.е. на уровне ниже даже.
DK
Список функциональных требований к bpm системе
SD
нет, в параллельной активности "Deploy on DEV" вызывается externalTask, который имеет output'ы. Вот для этого таска она их пытается смапить и падает.
Т.е. на уровне ниже даже.
Т.е. на уровне ниже даже.
А с областью видимости там все норм? Мне пока непонятна ваша проблема
YY
А с областью видимости там все норм? Мне пока непонятна ваша проблема
Проблема следующая:
Есть две параллельных таски - 1. Ожидание аппрува, 2. Вызов другого флоу (Выкладка и тесты на DEV).
В вызванном во 2 пункте флоу внутри имеется externalTask. Этот externalTask имеет outputParameters.
Но он даже запуститься не успевает (соответственно, маппить нечего). И вот тут он падает с ошибкой.
Область видимости у переменных нормальная. Когда идём по позитивному сценарию, всё ок.
Почему инцидент зарегистрировался на другой активности, в принципе есть предположение, что exception propagation так работает, видимо.
Есть две параллельных таски - 1. Ожидание аппрува, 2. Вызов другого флоу (Выкладка и тесты на DEV).
В вызванном во 2 пункте флоу внутри имеется externalTask. Этот externalTask имеет outputParameters.
Но он даже запуститься не успевает (соответственно, маппить нечего). И вот тут он падает с ошибкой.
Область видимости у переменных нормальная. Когда идём по позитивному сценарию, всё ок.
Почему инцидент зарегистрировался на другой активности, в принципе есть предположение, что exception propagation так работает, видимо.
SD
Мне все-таки кажется вы неверно определили место проблемы. Что в инциденте? Какая ошибка?
НА
НА
Денис, спасибо большое, полезная штука, я говорил вот про нечто подобное