Badanie głównej przyczyny problemu "żądania nie znalezionego w TrackedRequests" SharePoint "

Question

Mamy od dawna problem w naszym systemie śledzenia błędów o przerażającym" BŁĄD: prośba nie została znaleziona w śledzonych żądaniach. Możliwe, że tworzyliśmy i zamykaliśmy sieci w inny wątek: "wiadomość w dzienniku śledzenia programu SharePoint.

W miarę rozwoju Workflow software dla rynku SharePoint, od czasu do czasu sprawdzamy ten problem, aby upewnić się, że nie jest on spowodowany przez nasze produkty. Osobiście doszedłem do wniosku, że jest to problem w SharePoint, ale być może ktoś inny może mi udowodnić, że się mylę.

Oto, co wiem:

1. Według setek wyników wyszukiwania zwracanych przez Google na ten temat, kwestia ta wydaje się być związane głównie z SharePoint Workflow, zarówno SharePoint Designer i wizualne przepływy Studio oparte .

2. Zakładając, że logowanie do ULS jest ustawione na Monitorowalne, najłatwiejszym sposobem na odtworzenie tego problemu jest utworzenie nowego przepływu pracy programu SharePoint Designer, dołączenie go do biblioteki dokumentów, ustawienie automatycznego uruchamiania przy dodawaniu/aktualizacji, nie dodawanie dowolne działania, zapisz przepływ pracy i prześlij plik do biblioteki dokumentów.

3. Błąd jest widoczny tylko w dzienniku programu SharePoint, ale nie ma wpływu na wykonanie przepływu pracy.

4. Sprawdziłem, że problem występuje w systemach 32-bitowych i 64-bitowych, Win2K3 i 2K8, WSS i MOSS z wersjami programu SharePoint aż do December 2009 Cumulative Update (6524).

5. Problem nie występuje, gdy przepływ pracy jest uruchamiany ręcznie.

6. Istnieje dozens od Notki na MSDN forum, hundreds w Google, one na StackOverflow i nikt na SharePoint przelewowy. Wygląda na to, że nie ma odpowiedzi.

Czy ktoś ma jakiś pomysł na temat tego, co się dzieje, co jest tego przyczyną i czy powinniśmy się martwić lub plik to pod „Red Herrings”.

Aktualizacja:Firma Microsoft potwierdziła, że ​​jest to znany problem, który można bezpiecznie zignorować. Nie zostanie naprawiony w SP2007, ale nie jest już problemem w SP2010.

Answer 1

Prześlij je do Red Herrings. Mówisz: "Błąd jest widoczny tylko w dzienniku śledzenia programu SharePoint, ale nie ma to wpływu na wykonanie przepływu pracy pod ręką." W dzienniku ULS znajduje się tak dużo błędów, że są poza naszą kontrolą i nie oddziałują bezpośrednio na nasze środowisko. Jeśli chcesz ulepszyć produkt, możesz spróbować zadzwonić do pomocy technicznej, która może nie być inkrementowana jako błąd. Co jednak, jeśli to nie błąd, ale po prostu pełna wiadomość na temat protokołu ULS?

Taka gadatliwość nie ogranicza się tylko do dzienników ULS. Czy widziałeś Microsoft Office SharePoint Server 2007 Management Pack for System Center Operations Manager 2007? Filtruje zdarzenia związane z hałasem z dzienników zdarzeń na farmie, dzięki czemu możesz skoncentrować się na zdarzeniach oznaczających rzeczywisty problem.

Answer 2

To jest naprawdę dobre pytanie, a ja pragnę zobaczyć dobre odpowiedzi na to pytanie. Widziałem ten błąd w moich przepływach pracy w bardzo różnych kontekstach.

Na przykład: W moim przypadku zdarza się to w przypadku niestandardowej czynności wypalanej w domu, gdy przechwycę zdarzenie "utworzone zadanie" i spróbuję "przełamaćinicjację" SPListItem (nowe zadanie).

Moja aktywność dostaje zwyczaj kontekst workflow poprzez właściwość wfActProps która jest typu SPWorkflowActivationProperties. Potem zwykle używam wfActProps.Web, aby uzyskać dostęp do obiektu WWW.

Pierwsza myśl, że może to zły sygnał, aby przejść SPWorkflowActivationProperties między różnymi zajęciami, jednak nie znalazłem jeszcze inny sposób.

Ustawiam "wspólnotową wiki" dla mojej odpowiedzi, ponieważ nie jest to faktyczna odpowiedź, raczej przykład sytuacji, w której ten błąd może być widoczny.

Answer 3

Kiedy patrzę na stacktrace (jestem zakładając osobę, która opublikowała tę wiadomość odnosi się do tego samego błędu), to wygląda jak odbiornik zdarzeń OOTB (Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver), który jest odpowiedzialny za autostarting workflows unieszkodliwia SPSite, który nie został utworzony przez kod odbiorcy zdarzenia.

Niestety metoda AutoStartWorkflow() jest zaciemniana, więc nie mogę zobaczyć w Reflectorze, który SPSite jest usuwany. Możesz poeksperymentować, pisząc własny EventReceiver, który pozbędzie się istniejącego SPSite, do którego może trafić i zobaczy, czy spowoduje to zarejestrowanie tego samego błędu.