摘要：自定义活动(三) 锁定处理 在前面的文章我已经讲过，把用户数据的收集同工作流实例中分离出来。数据的存储也就很可能地进行了分离。这种数据的分离会要求我们去做更多的工作： l 维护工件（如稿件，任务等要在工作流中进行加工的东西）与工作流实例的关系。我们用WF自带的SqlWorkflowPersistenceService来完成工作流实例的存储。那么工件、工件与WF实例的关系及相关的处理情况应交给应用系统来维护。有关这方面的内容请看后面的“工作流的工件维护框架”。 l 保持工件与WF实例的状态一致性。这部分的解决请后后面的有关“状态一致性”的话题。 l 独占式处理。这是本节的重点内容。 独占式处理，其实处理过程很简单，就是在处理时对数据加把锁，就象进厕所把门锁上一样：）。这里不讲怎样去加锁，而是讲对哪些数据进行加锁以及何时进行加锁。 阅读全文

摘要：数据交换 要想使自定义活动能够通用，那么活动所需要的数据来源也必须遵循一定的规范才可以，然而这很难做到。那自定义审核活动来讲，它可能需要在三个方面的数据（实际还要多）： l 用户设计工作流时指定用于审核的人员列表，指定那些人可参与这个审核活动。这里有一个技术点，就是如何实现自定义属性编辑器，这里不多讲。 l 工作流实例运行时获得当前用户信息，根据当前用户自定义审核活动可以判断此人是否可以执行此活动，即此人是否在用户列表中存在。如果不可以则中断活动的运行。有关如何中断活动的运行请看后面的文章。 l 活动执行时所需要的数据。业务工作流平台设计(四)中的“尽可能减少占有时间 ”中讲到将用户数据的收集从工作流中分离出来，以节省占有时间，同时也应将数据同工作流进行分离。工作流不负责这些数据的存储和查询，但自定义审核工作流会应用这些数据进行处理以决定该活动是否运行到下一步去；或是继续等待其它用户的审核；或是退回（可经修改再次提交审核）；或是不被采用（不能再次提交审核）。 阅读全文

摘要：这一小节要讲的东西，目前我认为是最重要的东西。这是业务工作流平台中非常重要的一部分;；也是模板的重要组成部分。我们将从以下几个方面讲述自定义活动： 尽可能减少占有时间 数据交换 锁定处理 保持状态的一致性及完整性 中止活动的运行 以下是针对自定义审核活动特有的设计 功能逻辑的设计 回退与重新递交 跨审的实现 阅读全文

摘要：这里的要说明的重点是如何设计一个通用的最终用户可自行设计的编辑器，也就是说这个编辑器不只是应用于前篇文章所说的新闻系统。这里的技术点在于，每个应用系统都有自己特定的自定义活动，而这个设计器又如何去识别这些自定义活动。对于这个技术点来讲其实现还是比较简单的，那就是用“反射”。 来看一下我们的应用系统会有什么样的要求？ 阅读全文

摘要：的确正如别人所说的那样，WF只是一个foundation而不是一个platform，如果要实现完整的业务工作流平台支持，就这个平台的实现来讲，从技术上说不是很难，我想微软应该可以实现这一点，也许是下一个版本：）。或许就platform和foundation来讲，微软更看中的是foundation。总之现在的应用还是比较麻烦的事情。 阅读全文

摘要：如何有效地让客户自已去灵活地、随时随地地设计使用这些流程，而不需要工程人员或售后人员的干预是一个非常棘手的问题。客户关心的是流程中有几个环节。如果让用户自己去用IFELSE或WHILE去设计每一个环节的详细内容，则客户很快会否决这套系统，即使是技术熟练的工程人员也会皱眉的，维护成本会大幅的攀升的，而且开发人员还要为工作流设计器中的每一个条件做一些复杂和额外的工作。 阅读全文