Ошибка ULS в SharePoint 2007 System.NullReferenceException при запуске рабочего процесса - PullRequest
0 голосов
/ 17 августа 2011

(MOSS 2007 32bit SP2)

У меня есть рабочий процесс, который был разработан в Visual Studio и развернут как функция и связан с моим списком. Элементы в этом списке создаются программно, и последний шаг процесса - просмотреть коллекцию SPWorkflowAssociation в списке и запустить WF, который соответствует определенному имени:

// code to create the list item & get the new item's index (itemIndex)...

foreach (Microsoft.SharePoint.Workflow.SPWorkflowAssociation flowAssoc in SPContext.Current.Web.Lists["{listname}"].WorkflowAssociations) {
    if (flowAssoc.Enabled && flowAssoc.AllowManual && (flowAssoc.Name.Trim() == workflowNameToLookFor.Trim())) 
        SPContext.Current.Site.WorkflowManager.StartWorkflow(SPContext.Current.Web.Lists["{listname}"].Items[itemIndex], flowAssoc, flowAssoc.AssociationData, true);
}

(пожалуйста, простите за уродливые полностью уточненные имена и постоянное повторное извлечение SPListItem, если только вы не думаете, что это как-то виновато)

Это использовалось в течение нескольких месяцев, когда рабочим процессом был рабочий процесс SharePoint Designer. Теперь, когда я развернул свой пользовательский WF (который имеет другое имя), я получаю «странное поведение»:

Все работает на 100%, если я (не системная учетная запись, а администратор семейства сайтов) запускаю код, чтобы создать элемент и запустить рабочий процесс. Но если любой другой пользователь (даже кто-то с полным доступом на сайте и всеми задействованными списками) делает то же самое, он получает общую страницу «Ошибка, произошла непредвиденная ошибка» из SharePoint, но элемент создан правильно, ошибки WF нет связан с ним (история WF для элемента полностью пуста), и они могут затем без проблем запустить указанный рабочий процесс.

Единственная ошибка, генерируемая в ULS, когда это происходит:

Engine RunWorkflow: System.NullReferenceException: ссылка на объект не установлена ​​для экземпляра объекта. в Microsoft.SharePoint.Workflow.SPWorkflowHostServiceBase.LoadInstanceData (Guid instanceId, Boolean & обжатые данные) в Microsoft.SharePoint.Workflow.SPWinOePersistenceService.LoadWorkflowInstanceState (Guid instanceId) , WorkflowInstance workflowInstance) в System.Workflow.Runtime.WorkflowRuntime.Load (ключ Guid, контекст CreationContext, WorkflowInstance workflowInstance) в System.Workflow.Runtime.WorkflowRuntime.GetWorkflow (Guid instanceId) в Microsoft.SharePoint.We.We.SeWWW.SeWWW.SeWWW.SeWWW.SeOWWeSeWWE winoeworkflow, SPWorkflowEvent e) в Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow (идентификатор отслеживания Guid, хост SPWorkflowHostService, рабочий процесс SPWorkflow, события Collection1, события TimeSpan timeOut)

Если я изменю имя нужного рабочего процесса на что-то, чего не существует, то вообще не будет ошибки (так как мой оператор IF в FOREACH никогда не найдет совпадение), поэтому он определенно находит мой рабочий процесс и пытается его запустить.

Но (опять же), если я посмотрю на страницу Состояние / история рабочего процесса на элементе, который сгенерировал ошибку, там не будет ни ошибки, ни записи о том, что WF когда-либо пытался начать там, и с этой страницы пользователь может запустить вручную рабочий процесс без проблем.

I , я использую форму ассоциации InfoPath для WF, но если это было в ее основе (например, если мне нужно передать что-то с его данными / схемой в WorkflowManager.StartWorkflow), я ' Я ожидаю увидеть ту же ошибку для моего администратора семейства сайтов. Я не использую какую-либо форму инициации WF.

Я схожу с ума, пытаясь найти источник этого. Надеясь, что кто-то видел эту ошибку ULS или такого рода поведение раньше ...

1 Ответ

0 голосов
/ 17 августа 2011

На самом деле не нашел причину этого, но я смог это исправить ...

После сброса всех списков / библиотек во всем содержимом сайта для наследования разрешений от сайта и предоставления моему тестовому пользователю полного доступа на уровне сайта я все еще получал ошибку / сбой от моего тестового пользователя. Однако, если я предоставил своему тестовому пользователю права администратора семейства сайтов (это дочерний сайт / веб-сайт непосредственно под SC, т. Е. http://mossServer/sites/SC/thisSite/), тогда все работало.

Поэтому я настроил этот сайт на повторное наследование его разрешений от SC, затем разорвал наследование и добавил обратно в мою «обычную» группу для этого сайта (в которой находится тестовый пользователь) с разрешениями Contribute и Approve, и избавился от все заведомо неприменимые записи из СЦ. Теперь все работает для тестового пользователя.

У меня все еще есть несколько посторонних групп с доступом к сайту, которые мне нужно очистить, но я не думаю, что мой тестовый пользователь входит в какую-либо из них, поэтому я не думаю, что они были разницей. Я думаю, что каким-то образом (я допустил ошибку, сделав одноразовое изменение «очистки разрешений» вместе с развертыванием моей новой WF), я сломал «скрытое» (не для объекта, видимого из всего содержимого сайта) назначение разрешений, которое имело решающее значение для процесс (хотя я все еще не понимаю, что это могло быть, так как пользователь смог увидеть WF и вручную запустить его на элементе, который он создал).

Я оставлю комментарий, если найду что-нибудь еще, но похоже, что переопределение разрешений из семейства сайтов исправило все, что было сломано.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...