01.08.2014, 11:52 | #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. |
|
01.08.2014, 13:50 | #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!!! |
|
01.08.2014, 14:09 | #3 |
Участник
|
Ну, в общем-то, тут всё понятно:
http://prntscr.com/48g3qf Непонятно, почему он не отваливается\самозавершается по таймауту. Это баг или фича? |
|
01.08.2014, 14:31 | #4 |
Чайный пьяница
|
Имхо описание говорит само за себя. Та запись, которая инициировала запуск или которая используется в процессе - не была найдена. Например её удалили или не заполнен лукап, а в процессе вы полагаетесь на то что эта запись доступна. Для полного понимания надо глубже понимать ваш процесс.
__________________
Эмо разработчик, сначала пишу код, потом плачу над его несовершенством. Подписывайтесь на мой блог, twitter и YouTube канал. Пользуйтесь моим Ultimate Workflow Toolkit |
|
01.08.2014, 15:04 | #5 |
Участник
|
Коллеги, спасибо. Но вопрос был в другом . Я понимаю причину "повисшего" р\п. Я не понимаю, почему он остаётся в статусе ожидания, а не падает с ошибкой или просто останавливается по какому-то системному таймауту? Так и должно быть в ЦРМ? И чтобы избежать подобных статусов нужно чётко прописывать условия выполнения в р\п? И обязательно ли ставить шаг "Остановить рабочий процесс" при построении?
|
|
01.08.2014, 16:47 | #6 |
Чайный пьяница
|
Процесс "падает" при ошибке. Сделано это для того, чтобы можно было разобраться в чём же ошибка, устранить её и перезапустить процесс.
__________________
Эмо разработчик, сначала пишу код, потом плачу над его несовершенством. Подписывайтесь на мой блог, twitter и YouTube канал. Пользуйтесь моим Ultimate Workflow Toolkit |
|
|
За это сообщение автора поблагодарили: magicandy (1). |
01.08.2014, 18:23 | #7 |
Участник
|
Цитата:
Сообщение от magicandy
Ну, в общем-то, тут всё понятно:
http://prntscr.com/48g3qf Непонятно, почему он не отваливается\самозавершается по таймауту. Это баг или фича? В данном случае мы имем StatusCode “Waiting” он находить под State “Suspended” Так что все логично Что -то мне подсказывает, что вы не давно начали знакомство с Dynamics CRM Я бы Вам посоветовал почитать что такое statuscode и statecode. Эти поля актуальны для всех сущностей, но имеет разные значения. Почитать можно тут и тут Тем самом система создает иерархию статусов.
__________________
Читайте SDK!!! |
|
04.08.2014, 14:39 | #8 |
Участник
|
Цитата:
Цитата:
Что -то мне подсказывает, что вы не давно начали знакомство с Dynamics CRM
Ошибки поправил, теперь необходимо корректно удалить скопившийся "мусор". Руками делать очень долго. Нашёл решение: http://www.crmcodex.com/2011/05/remo...ing-workflows/ Какие-нибудь ещё есть варианты? |
|
04.08.2014, 21:23 | #9 |
Участник
|
Вопрос отпадает. В CRM13 можно штатными средствами пакетно удалять подобные вещи. Не подцепляет ли такое удаление связанных сущностей? Как это, например, происходит при удалении Организаций. Попробовал удалить несколько записей, вроде всё цело остаётся. А вот удалять несколько тысяч, что-то несколько боязно
|
|
04.08.2014, 22:23 | #10 |
Еда - топливо, Одежда - н
|
Удаляйте, ничего страшного не произойдет...
Если вы волнуетесь о наследовании связей... То их как таковых нет в р\п. Косите все под чистую )) Кстати проект банковский? ))
__________________
Все что вам нужно - это мозК Еда - топливо... Одежда - необходимость... |
|
|
За это сообщение автора поблагодарили: magicandy (1). |
05.08.2014, 16:02 | #11 |
Участник
|
Спасибо, теперь выкосил без сомнений
Нет, проект не банковский. Продажи и сервис. |
|
|
|