調查SharePoint的「在TrackedRequests中找不到請求」的根本原因

Question

我們在我們的bug跟蹤系統中存在一個長期存在的問題，關於令人害怕的「錯誤：請求未找到TrackedRequests」。我們可能正在創建和關閉網站不同的線程。「SharePoint的跟蹤日誌中的消息。

隨着我們爲SharePoint市場開發Workflow software，我們不時研究這個問題，以確保它不是由我們的產品引起的。我個人得出的結論是，這是SharePoint中的一個問題，但也許別人可以證明我錯了。

這是我所知道的：

1. 根據數百個搜索結果由谷歌關於這個主題返回，這個問題似乎主要涉及到SharePoint工作流，兩者的SharePoint Designer和Visual Studio的基於工作流程。

2. 假設ULS日誌記錄設置爲可監視，最簡單的重現此問題的方法是創建一個新的SharePoint Designer工作流，將其附加到文檔庫，將其設置爲自動啓動添加/更新，不添加任何操作，保存工作流並將文件上傳到文檔庫。

3. 該錯誤僅在SharePoint跟蹤日誌中可見，它似乎不會影響手頭工作流的執行。

4. 我已驗證問題發生在32位以及64位系統，Win2K3和2K8，WSS和MOS版本，SharePoint版本最高爲December 2009 Cumulative Update（6524）。

5. 當手動啓動工作流程時，不會發生該問題。

6. 在MSDN論壇上有dozens的相關帖子，Google上的hundreds，StackOverflow上的one，以及SharePoint溢出中沒有。似乎沒有答案。

沒有人有是怎麼回事，是什麼原因造成這一點，我們是否應該擔心或文件，該下「Red Herrings」的想法。

更新：Microsoft已確認這是一個可以安全忽略的已知問題。它不會在SP2007中修復，但在SP2010中不再是問題。

Answer 1

把它歸檔在Red Herrings下。您說：「錯誤只在SharePoint跟蹤日誌中可見，但看起來不會影響手頭工作流程的執行。」 ULS日誌中記錄的錯誤太多，超出了我們的控制範圍，並且不會立即影響我們的環境。如果你想改進產品，你可以嘗試一個可能不會增加的支持電話作爲錯誤。但是，如果它不是一個錯誤，但只是一個詳細的ULS日誌消息呢？

事實上，這種冗長並不僅限於ULS日誌。你見過Microsoft Office SharePoint Server 2007 Management Pack for System Center Operations Manager 2007嗎？它過濾掉場中事件日誌中的噪音事件，以便您可以專注於標記實際問題的事件。

Answer 2

這是一個非常好的問題，我渴望看到對此的良好迴應。我在非常不同的環境中看到了我的工作流程中的這個錯誤。

例如，在我的情況下，它發生在自制自定義活動中，當我捕獲「任務創建」事件並嘗試SPLiteItem（新任務）的「breakroleinheritance」時。

我的自定義活動通過類型爲SPWorkflowActivationProperties的屬性wfActProps獲取工作流上下文。然後我通常使用wfActProps.Web來訪問網絡對象。

我首先想到的是，在不同的活動之間通過SPWorkflowActivationProperties可能是一個不好的語氣，但我還沒有找到任何不同的方式。

我將「社區維基」設置爲我的回答，因爲這不是一個實際的答案，而是可以看到此錯誤的情況的一個示例。

Answer 3

當我看着stacktrace（我假設發佈該消息的人引用了相同的錯誤），它看起來像一個OOTB事件接收器（Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver），它負責自動啓動工作流正在處置可能尚未由事件接收器代碼創建的SPSite。

不幸的是，AutoStartWorkflow（）方法被模糊處理，所以我無法在Reflector中真正看到正在處理哪個SPSite。你可以嘗試編寫你自己的EventReceiver，它可以處理任何現有的SPSite，它可以得到它的手，並看看是否導致記錄相同的錯誤。