В настоящее время я диагностирую проблему с реализацией MS Dynamics CRM 2013, в результате которой системные задания в CRM программно отменяются вскоре после их создания, если выполняются определенные условия в приложении.Однако эти рабочие процессы НЕ отменены и продолжают обработку - и мне интересно, связано ли это с использованием хранимой процедуры SQL для обновления базы данных CRM.
Вот текущий (упрощенный) процесс:
- Событие в приложении запускает рабочий процесс CRM с использованием методов MS XRM OrganizationServiceProxy.
- В приложении происходит что-то, из-за чего мы хотим отменить рабочий процесс, который недавно был запрошен для запуска.
- Запрос «отменить рабочий процесс» сохраняется, а затем обрабатывается пользовательским приложением для обработки вскоре после него.
- Это приложение запускает хранимую процедуру, которая находит соответствующую запись AsyncOperation, и устанавливаетИзменено на getdate (), StatusCode до 32 (Отменено) и StateCode до 3 (Завершено).
Через некоторое время после успешной обработки отмены (как проверено нашим приложением) рабочий процесс иногдабудет продолжать обрабатывать, а StatusCode / StateCode не будетдолжно быть 32 и 3. Модифицированный DateTime в таблице AsyncOperation также будет позже, чем DateTime приложения "отменить запрос рабочего процесса".
Я пытался проверить, не был ли обработан запрос "StartWorkflow"нашим приложением еще нет, но в любом случае оно было отправлено в CRM, прежде чем мы попытаемся его остановить.Итак, CRM знает о рабочем процессе, но обновление таблицы AsyncOperation не вызывает ее отмену.Во многих случаях CreatedOn и / или ModifiedOn Datetime имеют значение ПОСЛЕ того, как мы пытались остановить рабочий процесс, однако, несмотря на запрос запуска рабочего процесса, идущий в CRM раньше.
Мой главный вопрос - есть ли разница между отправкойзапрос к OrganizationServiceProxy обновить AsyncOperation, используя:
workflow.Attributes["statecode"] = new OptionSetValue(3);
workflow.Attributes["statuscode"] = new OptionSetValue(32);
organizationServiceProxy.Update(workflow);
... по сравнению с хранимой процедурой, которая обновляет StateCode и StatusCode напрямую?Я читал, что обычно плохая идея обновлять базу данных CRM напрямую, но, конечно же, извлекая асинхронную работу из службы организации и затем сообщая ей об обновлении определенных столбцов, все, что он делает, - это то, что будет делать хранимая процедура?Это система CRM с большим количеством запускаемых рабочих процессов и большой нагрузкой, поэтому у меня есть теория, что это может быть связано с тем, что рабочий процесс, запущенный для запуска в CRM (но в состоянии очереди), НЕ будет втаблица AsyncOperation, пока CRM не заберет ее ... Это может объяснить, что некоторые записи имеют дату "CreatedOn", которая немного позже, чем дата обработки запроса на его ОСТАНОВКУ.Однако я не уверен, где рабочие процессы хранятся в БД, когда они находятся в очереди, или даже если они не сразу переходят в таблицу AsyncOperation.Мне интересно, если отправка запроса в CRM, где он, вероятно, будет выполнять тот же SQL, что и я, является жизнеспособным решением, или если кто-то знает о других элементах, которые могут заставить рабочий процесс CRM продолжать обрабатывать и перезаписывать StateCode / StatusCodeнесмотря на то, что для кода состояния / кода состояния установлено значение отменено / завершено?
Из-за загрузки в производственном процессе любой случай, когда я могу уменьшить абстракцию и просто напрямую влиять на БД, не только приветствуется, но и является почти необходимой из-за таймаутови медленная производительность в CRM.
Я вижу около 50 примеров этого ежедневно в работе, поэтому он не изолирован, но я не могу воспроизвести его в тестовых средах ... Что заставляет меня верить, что это проблема загрузки,но то, имеет ли CRM дополнительные шаги при обновлении кода состояния / кода состояния в таблице AsyncOperation, является моей главной проблемой.Спасибо!