|
|
#1 |
|
Участник
|
CRM 2013. 5000+ рабочих процессов в статусе Waiting
Коллеги, приветствую.
Сегодня заглянул в System Job и с удивлением обнаружил, что там 5000+ р\п висят в статусе waiting. Мне данная ситуация кажется несколько подозрительной. По таблице workflowwaitsubscriptionbase записей >21000. Причём джобов в статусе succeeded немногим больше 2000. То есть складывается впечатление, что все джобы, условия запуска которых не выполнились, не прерывались, а так и остались висеть в ожидании. Отсюда несколько вопросов: 1) Я прав и это действительно ненормальная ситуация, если я точно знаю, что у меня нет такого количество р\п, которые чего-то должны ожидать? 2) Может ли быть причиной подобной ситуации, что в рабочих процессах нет обязательного шага "Остановить рабочий процесс"? 3) Разве waiting не должен отваливаться по какому-то таймауту? Сервис asynchronous proctssing перезапустил, проблем с ним вроде нет. Да и аномалий в работе р\п в целом не замечено. Спасибо за ответ. UPD: Вот скрин р\п, массово висящего в статусе waiting. http://prntscr.com/48fgr4 В данном случае он остаётся в waiting, если queue item не case. Опять же, повторюсь, разве не предусмотрено таймаута для подобных ситуаций? Последний раз редактировалось magicandy; 01.08.2014 в 12:28. |
|
|
|
|
#2 |
|
Участник
|
Добрый день
Цитата:
Сообщение от magicandy
Коллеги, приветствую.
Сегодня заглянул в System Job и с удивлением обнаружил, что там 5000+ р\п висят в статусе waiting. Мне данная ситуация кажется несколько подозрительной. По таблице workflowwaitsubscriptionbase записей >21000. Причём джобов в статусе succeeded немногим больше 2000. То есть складывается впечатление, что все джобы, условия запуска которых не выполнились, не прерывались, а так и остались висеть в ожидании. Отсюда несколько вопросов: 1) Я прав и это действительно ненормальная ситуация, если я точно знаю, что у меня нет такого количество р\п, которые чего-то должны ожидать? 2) Может ли быть причиной подобной ситуации, что в рабочих процессах нет обязательного шага "Остановить рабочий процесс"? 3) Разве waiting не должен отваливаться по какому-то таймауту? Сервис asynchronous proctssing перезапустил, проблем с ним вроде нет. Да и аномалий в работе р\п в целом не замечено. Спасибо за ответ. ![]() Цитата:
Сообщение от magicandy
UPD:
Вот скрин р\п, массово висящего в статусе waiting. http://prntscr.com/48fgr4 В данном случае он остаётся в waiting, если queue item не case. Опять же, повторюсь, разве не предусмотрено таймаута для подобных ситуаций?
__________________
Читайте SDK!!! |
|
|
|
|
#3 |
|
Участник
|
Ну, в общем-то, тут всё понятно:
http://prntscr.com/48g3qf Непонятно, почему он не отваливается\самозавершается по таймауту. Это баг или фича? |
|
|
|
|
#4 |
|
Чайный пьяница
|
Имхо описание говорит само за себя. Та запись, которая инициировала запуск или которая используется в процессе - не была найдена. Например её удалили или не заполнен лукап, а в процессе вы полагаетесь на то что эта запись доступна. Для полного понимания надо глубже понимать ваш процесс.
__________________
Эмо разработчик, сначала пишу код, потом плачу над его несовершенством. Подписывайтесь на мой блог, twitter и YouTube канал. Пользуйтесь моим Ultimate Workflow Toolkit |
|
|
|
|
#5 |
|
Участник
|
Коллеги, спасибо. Но вопрос был в другом
. Я понимаю причину "повисшего" р\п. Я не понимаю, почему он остаётся в статусе ожидания, а не падает с ошибкой или просто останавливается по какому-то системному таймауту? Так и должно быть в ЦРМ? И чтобы избежать подобных статусов нужно чётко прописывать условия выполнения в р\п? И обязательно ли ставить шаг "Остановить рабочий процесс" при построении?
|
|
|
|
|
#6 |
|
Чайный пьяница
|
Процесс "падает" при ошибке. Сделано это для того, чтобы можно было разобраться в чём же ошибка, устранить её и перезапустить процесс.
__________________
Эмо разработчик, сначала пишу код, потом плачу над его несовершенством. Подписывайтесь на мой блог, twitter и YouTube канал. Пользуйтесь моим Ultimate Workflow Toolkit |
|
|
|
| За это сообщение автора поблагодарили: magicandy (1). | |
|
|
#7 |
|
Участник
|
Цитата:
Сообщение от magicandy
Ну, в общем-то, тут всё понятно:
http://prntscr.com/48g3qf Непонятно, почему он не отваливается\самозавершается по таймауту. Это баг или фича? В данном случае мы имем StatusCode “Waiting” он находить под State “Suspended” Так что все логично Что -то мне подсказывает, что вы не давно начали знакомство с Dynamics CRM Я бы Вам посоветовал почитать что такое statuscode и statecode. Эти поля актуальны для всех сущностей, но имеет разные значения. Почитать можно тут и тут Тем самом система создает иерархию статусов.
__________________
Читайте SDK!!! |
|
|
|
|
#8 |
|
Участник
|
Цитата:
Цитата:
Что -то мне подсказывает, что вы не давно начали знакомство с Dynamics CRM
Сравнительно недавно. Спасибо за ссылки.Ошибки поправил, теперь необходимо корректно удалить скопившийся "мусор". Руками делать очень долго. Нашёл решение: http://www.crmcodex.com/2011/05/remo...ing-workflows/ Какие-нибудь ещё есть варианты? |
|
|
|
|
#9 |
|
Участник
|
Вопрос отпадает. В CRM13 можно штатными средствами пакетно удалять подобные вещи. Не подцепляет ли такое удаление связанных сущностей? Как это, например, происходит при удалении Организаций. Попробовал удалить несколько записей, вроде всё цело остаётся. А вот удалять несколько тысяч, что-то несколько боязно
|
|
|
|
|
#10 |
|
Еда - топливо, Одежда - н
|
Удаляйте, ничего страшного не произойдет...
Если вы волнуетесь о наследовании связей... То их как таковых нет в р\п. Косите все под чистую ))Кстати проект банковский? ))
__________________
Все что вам нужно - это мозК Еда - топливо... Одежда - необходимость... |
|
|
|
| За это сообщение автора поблагодарили: magicandy (1). | |
|
|
#11 |
|
Участник
|
Спасибо, теперь выкосил без сомнений
![]() Нет, проект не банковский. Продажи и сервис. |
|
|
|
|
|