幾個星期前描述如何創建 SharePoint 設計師工作流發送任務提醒電子郵件在日常的基礎上，我寫了一篇詳細的文章. 它一直 出版 在新的 SharePoint 雜誌 網站. 更普遍, 這篇文章顯示如何在 SPD 中創建一個迴圈的結構.

這本雜誌有各種各樣的物品包括, 除其他事項外, 非常技術性的東西, 訪談和行業新聞. 我建議你將它添加到您的 RSS 提要.

如果您有出售的產品或服務, 我還會考慮在網站上的廣告. 它是強有力的開端與幾千雙眼睛看著它已經. 那是一定會有增長.

最後, 如果你一直都很渴望寫點東西，就拿自己最大努力在更廣泛的受眾, 這是一個很大的時間和地點去抓它.

</結束>

訂閱我的博客.

在結束標記米勒 最終使用者 SharePoint 已發佈我最新的文章使用 SharePoint 設計師在他的網站上創建了偉大的工作流解決方案. 將其簽出.

在這篇文章, 我談的設計過程和, 更詳細地, 如何設置使用 SharePoint 功能可靠且可重複的測試過程 (自訂清單, 網站範本). 本文針對最終使用者, 但方法是有益於開發商太.

</結束>

訂閱我的博客.

上個星期, 我出如何工作 迴圈，並實現狀態機 使用 SharePoint 設計器，並提到, 順便提一句, 這很可能會寫一篇博客文章有關更好的工作流日誌記錄.

井, 桑吉拉其普特搶先. 看一看.

日誌資料保存到一個自訂清單中似乎比使用常規工作流歷史記錄:

• 它是只是一個自訂的清單, 因此，您可以將它能夠很容易地 excel 匯出.
• 您可以創建視圖, 動態篩選資料, 等.
• 它不受自動清除你經常工作流歷史記錄.

有一些風險 / 負面影響:

• 許多運行工作流中有很多的日誌記錄可能導致過多的資料被寫入到清單中.
• 也許你 * 做 * 個的想要自動清除. 你不要用這種方法的功能 (無需編碼).
• 安全是棘手. 為了寫到清單中, 使用者必須有權這樣做. 這意味著它可能不是適合任何一種"官員" 因為使用者可能發現清單和編輯它的審計. 這可以克服的一些自訂的程式設計.

</結束>

訂閱我的博客.

這過去的一周我完了概念專案證明用戶端在曼哈頓. 同時實施的解決方案, 遇到了青苔 Kpi 的另一個缺點 (在這裡看到的以前的 KPI 問題和我的解決方法。).

背景: 用於設計器 SharePoint 工作流模型相當複雜多月長業務流程. 作為它突突地前進, 它將更新清單中的一些狀態資訊. Kpi 使用此資料來做他們的魔力.

我們決定要創建一個新的網站每次一個新的這些業務流程揭開序幕. 工作流本身的旁白, 這些網站主機幾個文件庫, 使用訪問群體設定等等等等. 只是一堆的東西，説明內部員工之間的協作, 出差旅行的員工和用戶端參與商業夥伴.

我們還想要展示一些 Kpi，監視的整體健康情況這一特定的業務進程所提倡的工作流狀態資料並使用 Kpi 查看.

最後, 我們用做對網站中的清單視圖上計數的 KPI 清單項 (而不是從另一個資料來源, 像 excel 或 SQL).

問題: 你可以想像, 假設我們都攜帶進入生產世界前進的基本思想, 我們想要的網站範本. 提供基於"業務流程的新網站" 範本.

問題是你似乎無法得到這種方式運作的 KPI. 在創建基於範本的 KPI 清單與 KPI web 部件的新網站時, 新網站 KPI 資料都破了. 無論源新網站 KPI 清單點你定義當你第一次保存它作為一個範本.

舉個例子:

• 創建一個新的網站和它構建到完美. 該網站包含 KPI 資料.
• 作為範本保存，.
• 創建新的網站和基地如果關閉範本.
• 這個新網站 KPI 清單項’ 來源指向網站範本, 沒有當前網站.

具現化過程不正確的 URL.

我試著解決這個問題通過指定相對 URL 定義 KPI 清單項時. 不過, 我不能任何變化的為了工作.

我總是想要配對這些"問題" 博客文章具有某種解決方案, 但在這種情況下，我沒有一個好. 最好的我可以圖是你需要轉到新調配的網站和手動修復一切. 這種介面使得這更難的因為更改的源清單中的 URL 會導致刷新, 所以你真的要重新定義整件事從零開始.

如果有人知道更好的方法來處理這, 請張貼評論.

</結束>

最近學會它是可能，甚至相當輕鬆地創建使用 SharePoint 設計器的狀態機工作流. 必要性是發明和所有的好東西的母親又尋找發明需要這個星期. 巧合的是, 我偶然 這個 MSDN 論壇帖子 以及. 我個人的經驗這周和那"獨立確認" 借給我的信念的力量. 我打算寫關於這在更大的長度，一個完整的例子, 但這裡是它的要點:

• 該方法利用工作流可以更改清單項的事實, 從而引發了新的工作流. 我通常被認為這是令人討厭，甚至 有關使用信號量的博客 來處理它.
• SharePoint 允許多個獨立的工作流活動針對特定清單項.

要對其進行配置:

• 設計您的狀態機 (即, 各國和各國如何過渡到下一個).
• 作為單獨的工作流執行每個狀態.
• 這些狀態的工作流清單項中的任何變化的回應中執行的每個配置.

每個國家工作流遵循此粗糙的模式:

• 初始化時, 確定是否它真的應該運行通過檢查"當前專案"中的狀態資訊. 如果不，中止.
• 做這項工作.
• 更新的"當前專案" 與新的狀態資訊. 這會觸發更新到當前項和觸發所有狀態的工作流.

除了明顯的好處，可以創建聲明性狀態機工作流, 所有狀態資訊是建設 Kpi 和有趣的很棒的視圖.

它不會有一個相當大的缺點 — 標準工作流程歷史記錄追蹤比正常情況更無用 🙂 這很容易補救, 然而. 將您所有的審計類型資訊存儲在自訂清單. 這可能是一個好的主意，甚至為香草的順序工作流, 但這是另一篇文章的內容 🙂

稱之為"認錯" 因為我有, 不幸的是, 不止一次在論壇上表示，和其他地方那個必須使用 visual studio 創建狀態機工作流. 那只是不是真的.

</結束>

訂閱我的博客.

它是可能導致無限迴圈設計器 SharePoint 工作流中. 像這樣一種常見的執行模式導致的問題:

• 創建一個工作流和關聯清單.
• 表明，它應在開始創建新專案和現有專案的更新.
• 在工作流中的一個步驟更新"當前專案"中的一個欄位.
• 由於當前項更改, 重新開機工作流.

為了防止這種無休止的迴圈, 實現一個簡單的信號量:

• 添加網站列 (或清單/庫如果您不使用內容類型的列).
• 隱藏它從編輯頁 (容易做如果通過其屬性的網站列, 不一樣的情況下，很容易如果清單中的列).
• 在工作流中, 檢查信號量列的值為空.
• 如果它是空白, 將它設置為一個非空值和繼續執行.
• 如果不是是空白, 立即退出.

這可以成為一個相當微妙的解決方案, 如此等等取決於業務需求, 但我需要它的時候已經有一個可行的模式.

</結束>

訂閱我的博客.

正如許多人所知, 員工培訓範本 由 Microsoft 提供的在這裡 有一個 bug，我們可以複製下面的步驟:

• 創建類的一個最大大小 10 學生.
• 登記冊 –> 總正確就位遞減一. 結果: 9 可用座位.
• 登出: –> Bug. 總可用座位應增加 1. 它並不. 結果: 9 按照 SharePoint 可用座位, 但事實, 有 10 可用座位.

解決方案: 使用 SharePoint 設計器來更正工作流.

第一次, 打開網站. 我的資料夾清單中看起來像這樣:

如果我們看一看"出席者登記" 工作流, 我們看到有一個標記為"強制座位政策"的步驟. 它看起來像這樣:

此工作流中的步驟更新該專案通過遞增"填補席位" 在課程上的中繼資料列. 如果我們拉起，在更多的細節, 我們看到這:

這就是我們需要修復的登出工作流的所有資訊.

如果我們翻到登出工作流, 還有沒有類似的工作流步驟. 添加它，如下所示:

1: 展開"出席者登出" 和開放 XOML (請參閱第一個螢幕截圖如果你丟失).

2: 添加新的工作流變數, "新填充的席位" "數位"類型的.

3: 將一個值分配給"新填滿席位" 如圖所示:

4: 遞減的填充的席位由 1:

5: 更新相關的課程專案:

6: 請確保所有步驟都都正確的序列. 對我來說, 它看起來像這樣:

7: 完成工作流，以重新生成它.

8: 測試.

</結束>

訂閱我的博客.

找到中手工創建 SharePoint 解決方案的新興模式之一利用 SharePoint 設計器的工作流和事件接收器.

這裡是一個業務情形，把它放在上下文:

• 將文檔上載到文件庫.
• 我開球多級使用 SharePoint 設計器創建的工作流.
• 在這過程中一些點, 工作流將任務分配給某人 (通過從使用者那裡收集資料，或將一個任務分配).
• 我們想要使用 KPI 來跟蹤多久這項任務正在等待完成. KPI 顯示綠色為完成的任務或適當多 3 從現在起天. 它呈黃色，如果任務的截止日期明天或今天. 它顯示紅色任務是否過期.
• 出人意料的是: 我想要的磁碟機，KPI 假日意識到的日期.

我無法計算假期意識到到期日期在 SharePoint 設計師工作流很容易. 要創建自訂操作或使用協力廠商工具. 不過, 很容易計算中的事件接收器的日期. 將這兩個合併在一起，我們得到這樣的圖案:

• 定義隱藏是 / 無上的文件庫的網站欄標有"DoCalcualteDueDate".
• 將它初始化為 false.
• 在適當的時候在工作流中 (例如：. 只是之前的"收集資料" 行動), 將該值指定為 True.
• ItemUpdate() 事件接收器看上去看看"DoCalculateDueDate" 是真的. 由於在每次更新上運行的事件接收器, "DoCalculateDueDate" 是通常虛假.
• 當工作流分配 DoCalculateDueDate 為 true, 事件接收器計算假日意識到到期日期.
• 當事件接收器沒有這種計算, 它設置的 DoCalculateDueDate 標誌為 false.

在結束, SPD 工作流向事件接收器通過 DoCalculateDueDate 信號量的溝通，我們有假期意識到由於在工作流的生命完全正確時刻分配的日期. SharePoint 設計器控制項時分配的截止日期，但事件接收器執行實際的計算和分配.

</結束>

訂閱我的博客.

更新: 我一直在研究如何將 SPD 工作流嵌入到網站定義. 這個 MSDN 論壇鏈有一些有趣的資訊. 它不是決定性, 但在叢林路徑指向.

我給這篇文章有點古怪"遵守行為" 因為我有點詭異，從中得出的結論. SPD 工作流 … 喜怒無常.

人們常常會問 / 想知道 / 微動在 SPD 工作流從一個地方搬到另一個. 今天, 我遵循這些步驟，提出這些意見:

• 我創建了一個工作流在網站附加到文件庫中使用 SharePoint 設計器.
• 關聯的文件庫已經設幾個文檔.
• 該網站另存範本.
• 當我保存為範本的網站, 我保存的內容，以及.
• 在同一網站集合並使用該範本創建一個新的網站.

在這一點, 我試著運行工作流. 它迅速終止本身與日誌消息, "啟動時失敗".

我預期這. 我有低的期望，當它來到走動 SPD 工作流.

我繼續:

• 在 SharePoint 設計器中打開網站.
• 聚醚醚酮在工作流. 它看上去不錯.
• 點擊"完成".
• 我跑了工作流.

這一次, 它能正常工作.

我將添加此工作流使用的"收集資料從使用者" 這是一個相對複雜的操作引擎蓋下的行動.

我暫時得出這樣的結論的過程"整理" 引起 SPD 來正確地與新的文件庫關聯的 SPD 工作流的工作流. 我也得出結論 XOML 和其他 XML 工件是合理的"寬鬆". 他們未超緊密耦合到文件庫.

這是什麼意思? 假設它一個可靠，重現性好的過程, 還有至少一個粗糙的方法，我們可以使用來移動它們. 我不知道是否這會工作如果我們越過網站集合邊界或甚至更猛烈地, 整個新的農場 (例如：. 到階段督促 dev).

如果你正在讀這篇和傾斜, 請發表評論或 電子郵件通知我 你的 SharePoint 設計師移民故事. 我很樂意會更新這個貼子因而提供任何見解.

</結束>

訂閱我的博客.

它往往是將狀態資訊存儲在自訂清單，如批准代碼應由最終使用者永遠不會直接操縱非常有用. 這是一個常見的業務場景. 我一直在今年，生成通過 SharePoint 設計師的工作流，然後驅動 Kpi 和一般支援時間關鍵業務流程的各種狀態和提醒日期的專案.

使用網站內容類型 / 要實現此效果的列.

使用狀態列所示創建網站內容類型:

請注意"地位 (對於演示)" 在底部的欄位.

下一次, 按一下要訪問的列屬性的列名稱. 選擇"隱藏 (不會出現在表單中)" 在列設置部分所示:

這從標準編輯/更新表單中刪除欄位. 不過, it is still available in views, Kpi, the object model and anywhere else you want to use it, 包括 SPD 工作流.

</結束>

訂閱我的博客.