工作流开发
1. 自定义工作流，自定义活动
2. 运行时服务
自定义工作流和活动
先看工作流设计器的界面
从界面中可以看到，需要做的工作有以下几点
1. 工作流定义保存方式 File下面的Save命令，将工作流定义保存到数据库中，以xml格式存在；同时也提供另存为，保存为xoml文件，以提供发人员设计的工流，直接发送到客户的电脑中。存成xoml文件的另一个好处是，方便调试诊断，以发现问题。
2. 设计器寄宿，rehosting designer，查阅MSND即可实现
3. 自定义活动，.NET 3.0/3.5的内置活动，涉及到很多编程的内容。因为自定义工作流，肯定不会考虑用来二次开发，而是给普通用户来设计，并且实现，所以.NET内置的所有活动都派不上用场。即使是简单的IF else活动，也要自己独立实现。
如图中所示，新建一个顺序工作流，拖动SendMessageActivity到设计器中，双击该活动，弹出窗口
这是一个撰写消息的窗体，和Outlook发送邮件的窗体非常相似。如果做成直接发送邮件，不容易追踪和查找历史记录，于是做成自定义消息的方式，并且提供一个option,让用户决定是否也同时当成邮件发送出去。
再来看判断活动
这个活动是根据值的不同，运行不同的分支，和If Else语句很相似。这里的关键是条件的设计，评估(Evaluate)，和运行时传值。
回忆SQL语句中条件的写法，SELECT Employee_NAME FROM EMPLOYEE WHERE EMPLOYEE_NO=’007’
一个方法是，用UI界面，把用户输入的条件转化为SQL语句的WHERE部分，让数据库帮忙评估求值，作判断。
使用这种办法，要想尽办法，既要让用户输入条件的方式直观易懂，又要让自己解析成SQL条件容易做。
另一种办法是CodeDom，这也是Workflow内置rule的生成方式。这里，为什么没有直接用Workflow的rule 编辑器和rule格式？ 我是这样理解的，Workflow 内置的rule,适合于以编程方式来使用，比如条件Amount>13, (金额大于13)，这个条件要求使用这该活动的Workflow具备变量Amount才行，否则这个条件是无效的，验证时会出错，这一点不可以接受。
在自定义工作流中，会传一个变量(一般是class)到当前运行的工作流中，类型变量的值，属性，就是我们在自定义条件中需要使用的大部分内容，额外的条件属性还包括一些环境变量。
比如上图的条件，我们是这样假设的，如果采购单的总金额小于10000，审核通过，如果大于10000，拒绝批准.
Approval和Reject活动撰写起来很容易，直接将字段Status更新的Approval或Reject即可。
问题的难点，还是在条件的判断。请查看如下图的条件判断窗体
字段TotItemAmt相当于前面的Amount，它是指物料总金额。采购的最终金额还包括税金，运输费用等。
运行时，将这个条件，转化为CodeDom语句，评估求值。
因为要放到Workflow中去，重写一个ActivityCondition，重写它的方法
public class CustomActivityCondition : ActivityCondition
{
public override bool Evaluate(Activity activity, IServiceProvider provider)
{ }
}
即可，在上图可以看到，那里有Insert Remove二个命令，可以新增加或删除条件，很明显，这是一组条件的集合
private List<EpnIfElseCondition> _conditions;
运行时服务
1. 提供SQL数据库，以持久化工作流。添加SqlWorkflowPersistenceService即可。
2. 如果是ASP.NET应用，要提供MannualWorkflowSecheduleService。
3. 将WF的WorkflowRuntime，暴露成WCF服务，以支持跨AppDomain的Workflow应用。
4. 窗体绑定
在窗体的接口一节中，提到过，窗体已经提供了标准的接口Save, Post,在窗体框架中，可以判断到当前窗体和当前操作命令(Save,Update,New,Post)是否有绑定工作流，如果有，启动工作流。
5. Workflow追踪, 可参考MSDN中的程序。
6. 动态变更, 参考MSDN中的程序.
Workflow定义了一套工作流的开发方式和规则。我们需要对它override一下，就可以实现自定义的应用,而不适合直接用来做应用。