几个星期前描述如何创建 SharePoint 设计师工作流发送任务提醒电子邮件在日常的基础上，我写了一篇详细的文章. 它一直 出版 在新 SharePoint 杂志 网站. 更普遍, 文章演示如何在 SPD 中创建循环结构.

这本杂志有各式各样的物品，包括, 除其他外, 技术性很强的东西, 访谈和行业新闻. 我建议你将它添加到您的 RSS 提要.

如果您有要出售的产品或服务, 我还会考虑在网站上的广告. 它是强有力的开端与几千双眼睛看着它已经. 那是一定会有增长.

最后, 如果你一直都很渴望写点东西，并把它出来面对更大的观众, 这是一个很大的时间和地点去抓它.

</结束>

订阅我的博客.

在对马克米勒 最终用户 SharePoint 已发布我最新的文章使用 SharePoint 设计师在他的网站上创建了伟大的工作流解决方案. 将其签出.

在这篇文章, 我谈的设计过程和, 更详细, 如何设置使用 SharePoint 功能可靠且可重复的测试过程 (自定义列表, 网站模板). 本文针对最终用户, 但方法是有益于开发商太.

</结束>

订阅我的博客.

上个星期, 我就在想如何 循环并实现状态机 使用 SharePoint 设计器，并提到, 顺便提一句, 我大概会有关日志记录工作流更好写一篇博客文章.

井, 桑吉拉其普特抢先. 看看.

将日志数据保存到一个自定义列表中似乎比使用常规工作流历史记录:

• 它只是一个自定义列表, 所以你可以将其导出到 excel 很容易.
• 您可以创建视图, 动态筛选数据, 等.
• 是不受你与经常工作流历史记录自动清除.

有一些风险 / 不好的一面:

• 许多正在运行的工作流与大量的日志记录会导致太多的数据都被写入到列表中.
• 也许你 * 做 * 个的想要自动清除. 你不要用这种方法的功能 (无需编码).
• 安全是棘手. 为了写到列表中, 用户必须有权这样做. 这意味着它可能不是适合任何一种"官员" 因为用户可能发现列表和编辑它的审计. 这可以克服的一些自定义的编程.

</结束>

订阅我的博客.

这过去的一周我完了概念项目证明客户端在曼哈顿. 同时实施的解决方案, 我跑进了 MOSS 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 和一般支持时间关键业务流程的各种状态和提醒日期的项目.

使用网站内容类型 / 要实现此效果的列.

使用状态列所示创建网站内容类型:

请注意"状态 (对于演示)" 在底部的字段.

下一步, 单击要访问的列属性的列名称. 选择"隐藏 (不会出现在窗体中)" 在列设置部分所示:

这从标准编辑/更新窗体中删除字段. 不过, 它是在视图中仍然可用, Kpi, 对象模型和其他任何你想要使用它的地方, 包括 SPD 工作流.

</结束>

订阅我的博客.