品高工作流开发前准备

工作流数据库准备

数据库表创建好之后

其中：

• SEC_前缀的是KissU的【组织架构表】；
• TMS_前缀为【时间提醒服务表】；
• WF_前缀为【工作流相关表】；

品高工作流SDK安装

解决方案新建好后：

• 修改Web.config中的连接

• DefaultDB为解决方案和业务表单数据默认使用的站点。
• WorkflowDB为流程引擎默认使用的数据库。

其他目录详解：

• App_Themes：里面的default目录下包含工作流的css和图标文件。

• Historymap.ashx：获取静态流转图图片的后台服务。

• HistorymapSL.aspx：显示Silverlight动态流转图的页面。

• JumpToAnyActivity.aspx：跳转到任意环节的选择和确定页面

初始P1流程定义工程

工作流定义工程是一种Visual Studio扩展工程类型，用于组织和管理流程定义。

工作流设计器会自动关联.wdfproj工程类型。

• 流程定义工程扩展名 .wdfproj。
• 流程定义文件扩展名 .wdf。

流程定义的开发

说明

1.如果您是第一次做流程开发，则需要先到工作流产品的安装目录下的DesignerVSIP目录中找到WorkflowDesigner.dll.config文件，由于在设计流程时会需要读取工作流数据库的部分数据如用户、角色、部门等以方便设计，所以需要修改其中的数据库链接串以确保正确。默认路径为C:\Program Files (x86)\Bingosoft\Procez One SDK\DesignerVSIP\WorkflowDesigner.dll.config。

2.

流程中的步骤：

每一个步骤都需要有特定的人来执行，这些人被称为步骤的参与者。

设置步骤的参与者有多种方式，在这个例子中我们采用为步骤指定角色的方式。角色可以理解为一个用户组，这个组中的用户具有对某一操作的权限。

流程图画完后：

流程就完成了。我们需要将这个流程部署到工作流数据库中。在工作流项目的项目节点处点右键-->“部署”：

会弹出FlowProvider转换工具，工作流项目用的是FileProvider，需要用DBProvider把流程定义导入到数据库中，另外需要选择ID冲突时的处理方式，这里由于数据库中已有ID为1的流程定义，所以请选择“自动更新ID”，并勾选该流程定义

最后点“执行”即可把该流程定义导入数据库中。

流程表单的开发

完成了流程的开发，我们还要开发流程表单。

参与者类型

用户选择参与者（UserSelectActor）

流程中经常会出现当前的环节参与者指定后续环节参与者的情况，尤其是OA类型的应用。如果流程出现这种情况时可以使用用户选择参与者，其中InnerUser的指定是供用户选择的范围。

当前环节的参与者是由当前环节的上一个环节的参与者指定时候，就要用到这种参与者类型。

上面的选项中”Attribute”、”Parameter”、”Prefix”、”XPath”一般保持默认就行了，只需要选择下面三个。

“允许任意选人”是指可以从系统中的所有用户中选择，这一项选择了“True”的话，那“供选择的参与者”中的限制条件就没有意义的了。“只允许单选”指定在选择用户时只允许选中一个用户。

4.2中新增加了一个属性：

部门ID属性名，在会签直接选人时用于过滤本部门的用户，在用户选择的XML数据中用户节点的所属部门ID有个属性名，在4.2中一般设置为：ParallelKey

用户角色参与者（RoleActor）

通过指定角色名称来获取该角色的所有成员。具体的某个角色都是属于其中一个部门的，如：开发服务部的“经理”角色，行政部的“经理”角色是有区别的，所以在指定角色参与者的时候都需要指定一个基准用户，通过该用户所在部门来求解出该部门的对应角色成员。也可以通过指定部门名称(DeptName)来获取该部门的对应角色成员。

在使用这种参与者方式的时候，我们要在设置的过程中明确两点：

1）角色类型是什么？

2）角色所属的部门是什么？

只有在明确了角色类型和角色所属的部门之后，我们才能求解出一个唯一的角色，然后根据这个角色去求解出拥有该角色的所有用户，求解出的结果就是该环节的参与者。

在选择了“用户角色参与者”时，下面会弹出如图所示的几个选项

如果该环节参与者的角色类型与角色所在部门都比较明确的话，那么这里的设置是非常简单的，直接指定“角色”和“角色部门”就行了（在会签流程内除外，这点稍后再说）。

如果只明确角色类型，而角色所属部门不清楚的情况下，比如“要让张三所在部门的部门经理来做这个环节的审批”就属于这种情况，在这种情况下就需要一个“基准参与者”，而张三就是这个“基准参与者”。当你选中了一个“基准参与者”后，而且没有选择“基准角色”，工作流引擎就会根据“基准参与者”所在的部门来确定“角色部门”。

但如果你还设置了“基准角色”，那么工作流引擎就会根据“基准参与者”与“基准角色”来确定“角色部门”。那什么情况下才会要设置“基准角色”呢？比如张三是A部门的部门成员，但同时张三又担任B部门的业务经理，如果你“要让张三担任业务经理的那个部门的部门经理来做这个环节的审批”就需要设置“基准角色”了，此时的“基准角色”需要设置为“业务经理”。

最后来看“并行内”这个选项，这个选项是在当前环节属于会签流程内的一个环节时才会用得到，因为在会签流程内时，通常是由几个部门来并行完成的，所以“角色部门”不会是任意的一个部门，而是由当前环节的上下文来决定，所以当前环节如果属于会签流程内的一个环节，就要把“并行内”设成True，并指定一个“角色”即可。

当有几种确定“角色部门”的方式时，就会有优先级之分，优先级从高到低如下：

• A．并行内设为True

• B．直接指定“角色部门”

• C．指定了“基准参与者”与“基准角色”

• D．只指定了“基准参与者”

流程步骤参与者（ActivityActor）

通过指定环节名称来获取参与过该环节的用户。

将当前步骤的参与者设置为同一流程中另一步骤的参与者。

比如某一流程有：A，B，C，D四个步骤。你想指定C步骤的参与者跟A步骤参与者一样，你就可以在C步骤中使用“流程步骤参与者”，并把步骤名称设置为“A”。注意：只有处理完的步骤才能求解出参与者，正在处理或未处理的参与者是不会求解出来的。（如果是没有处理过的步骤，求解的参与者为空。第一次需要使用复合参与者的或运算来求解第一次参与该步骤的参与者）

流程实例参与者（FlowActor）

流程参与者包含以下三种类型:

• 创建人：Creator，流程的创建者
• 代理人：Agent，流程创建的代理者

• 当前用户：CurrentUser，当前用户，

指定用户（AssignActor）

通过指定某个系统用户的登录帐号来指定某个环节的参与者。

扩展规则求解参与者（ExctendRuleActor）

步骤的参与者由外部程序集的一个类的一个方法提供，则可用此参与者类型。比如A步骤的参与者由一个叫“YouAssemblyName.dll”的程序集里的“YouAssemblyName.UserProvider”类的“GetUserLoginId”方法提供，则可设置如下：

返回IList<IPancitant>对象

业务数据求解参与者（DataTableActor）

很多情况下，在处理业务表单时，业务表单上已经包含了下一环节的参与者的信息，如：出车单上面指定了出车司机信息，这时候只需要指定环节参与者为业务数据参与者，流程核心就可以将该用户求解出来。

如果你想用你的业务表单中的一个DataSet里的数据来求解参与者的话，就可以用到这个业务数据求解参与者，假如有一个如下所示的DataSet：

可以通过以下设置来获取到在DataSet中的用户来做为参与者：

XML参与者（XMLActor）

如果工作流的表单数据包含了复杂应用，用户信息存放于XML数据中，则可以使用XML参与者。

当某个步骤的参与者从一个XML文件或一串XML格式的字符中获取时，就可以用到XML参与者，使用示例如下：

代码中主要是将XML格式的字符串插入到工作流参数中去，然后在XML参与者中获取，设置如下：

注意两张截图中红色圈的部分一致就行了。

（XML参与者只能返回用户的ID，返回LoginId无效）

对象参与者（ObjectActor）

使用程序中的一个对象的属性或方法返回的用户ID（Guid类型）或用户的LoginId（字符串）作为参与者。

假如在程序中有一个User类的如下：

而你希望设置某个步骤的参与者是由这个类的一个实例返回的值来指定，则可以把这个类的一个实例保存到Parameters对象中，参数名为“a”，保存代码示例如下：

然后在步骤的参与者类型中选择“对象参与者”，并做如下图所示的设置：

你可以指定从这个对象的一个属性或一个方法返回用户的LoginId或ID，如果是同时指定了方法或属性，则返回的值将同时作为这个步骤的参与者，最后一个“Scope”选项是指定你的方法或属性返回的是一个用户还是一个部门还有既有用户又有部门。

复合参与者（CompositeActor）

复合参与者可以看作为一个参与者的容器，通过与和或的关系，组合不同的参与者以实现复杂的参与者获取。

脚本参与者（ScriptActor）[Bingosoft.Workflow.Dynamic.dll]

通过Python脚本，来确定一个或多个参与者，看下面截图：

注意红圈中的两个值一致就行了，结果一般以一个数组的形式返回。

（只能返回IUser对象）

更多的资料在：

http://www.cnblogs.com/briankfc/archive/2010/10/12/1848780.html

SQL参与者（SQLActor）[Bingosoft.Workflow.Dynamic.dll]

SQL参与者是通过SQL语句直接求解出所需参与者。而SQL语句的写法如下：

1. select id from sec_user where OrgId = '{Parameter.CurrentUser.Department.ID}'
2. select id from sec_user where loginId = 'admin'

要注意的是，这里要select出来的是所有参与者的ID（GUID格式）。如果需要使用到一些系统变量作为过滤条件，则可以通过表达式的方式给出，如上面表达式中的{Parameter.CurrentUser.Department.ID}，表示当前用户所在部门的ID，所以这条SQL语句是要求解出当前用户所在部门下的所有成员。其他则可以此类推。

（参与者的设置对流程的启动步骤而言是没有意义的）

迁移类型

业务迁移（BusinessTransition）

业务迁移只是在基本迁移增加了扩展属性而已。在用户选人界面，可以通过接口获取到包含有迁移的扩展属性的XML，通过这些扩展属性，可以实现一些特殊的需求，例如可排序迁移还有筛选迁移都可以通过扩展属性里面增加一个Key和Value的键值对，在用户选人界面编写相应的业务逻辑。有扩展属性。

选择迁移（ChoiceTransition）

为了设计方便，选择迁移只是在业务迁移上面默认绑定了选择条件而已。具体用途请参照“选择条件”（ChoiceCondition）。继承自业务迁移，有扩展属性。

可回退迁移（BackwardTransition）

在设置迁移条件时可以根据需求灵活设置是否回退选项，以便在流程流转过程中，根据流程要求，选择将流程回退到上一步骤。继承自业务迁移，有扩展属性。

可排序迁移（SortableTransition）（v4.2中已移除）

用于在UI界面上用户选择后续环节迁移和人员时，能够按一定的顺序对环节进行排序。需要UI界面的支持。

筛选迁移（TransitionExtend）（v4.2中已移除）

用于在UI界面上用户选择后续环节迁移和人员时，能够过滤掉一些不希望用户看到的环节迁移（后续的自动步骤）。需要UI界面的支持。

条件类型

步骤条件（ActivityCondition）

最常用的条件类型，因为工作流里面常用到的流程分支，某个环节的判断结果不一样就会影响后续环节的走向，如：某个审批环节同意走向结束，不同意打回到开始。

使用环节条件可以由两种方式，一种就是判断环节结果，另外一种就是使用CheckFinish属性，判断某个环节是否执行过。

上面的流程同样可以通过步骤条件来完成，但跟选择条件不同的是，步骤条件的源环节必须要有“选择项”，步骤条件还可以判断某个步骤是否被执行过，如下图：

当你需要在“审批步骤”走向结束前必须要往“审批步骤（1）”流转一次，你就可以在“审批步骤”的两条迁出条件上用步骤条件，设置如下：

以上设置为两条迁移线上的设置，注意红线圈的部门为设置的不同之处。

另外，选择项中有百分比和优先级的设置，这些设置是用于投票的，比方说这个步骤有多人参与，60％以上同意才算同意，则“同意”的“Percent”就设置为60，另外那项就设置为40即可。所以当存在“选择项”时，最好采用“步骤条件”，特别是在投票场合下。对了，如果是投票的，还需要设置步骤的响应方式为“基于百分比”，关于更多步骤条件与选择条件的资料，请参考：

http://www.cnblogs.com/briankfc/archive/2010/08/31/1813680.html

选择条件（ChoiceCondition）

在流程中有时候需要用户选择下一步的走向时，通常会在UI中列出当前环节所有的后续环节以供选择，UI层会将用户选择的值放置于Choice的流程参数中。选择条件，就是通过该参数来判断条件是否成立的。

如果当前环节后续有超过一个的后续环节，而且流向哪个后续环节可由当前环节参与者自由选择时可以用选择条件的迁移，如下图流程：

这里默认是只能单选的，因为业务上通常是这样的，如果需要可多选，则在“启动”步骤的“扩展属性”里设置一个叫“OpStepMultiple”的属性，值设为“True”即可。

另外，选择条件的“选择结果”一般是目标环节的环节名。当然，如果源环节上有“选择项”，也可以是选择项中的某一项，如“同意”、“不同意”等。不过一般建议有选择项时就采用步骤条件，这样就不会混淆。

属性条件（PropertyCondition）

如果业务数据绑定的不是一个DataSet而是某个对象(常见于各种ORMapping的系统)，这时候就可以使用对象属性条件来直接通过比较该对象的某一属性来判断条件是否成立。

当条件的迁移与表单中的某个数据项有关时，就可以用属性条件作为迁移条件。比如说根据请假表单中的请假天数来决定是需要审核还是直接备案，如图所示：

需要特别强调的是：当使用了属性条件时，就要确保这个流程关联的表单里有这样一个属性，否则流程的运转可能会产生错误。

• 1. 属性条件如何使用

属性条件可用于以下两种场合：

1. 用于比较表单上某个字段值的大小，通过比较结果来决定条件是否成立。如比较合同金额或请假天数等。请把字段名设置到“属性名”中。

1. 如果要比较的值非表单上某个字段值时，可以把这个值通过参数的方式传入，并在属性条件上设置相应的“参数名”即可。

那如何以参数的方式传入呢？例如：

1. int flag = 3;

在表单的BeforeDataSave方法中加入如下代码：

1. Parameters.Add(“Flag”, flag);

那么，在表单承载页面AffairDetail页面的RunWorkflow方法中会提取这些Parameters，并通过WorkflowHelper.SetParameter方法把参数设置好，这样这个参数就可以在属性条件中提取得到了，进而比较其值以决定条件是否成立。

注意：“属性名”与“参数名”这两个属性是对应于两种不同的用法的，所以只需填一个即可，另一个可留空。

• 2. 流程模拟器中如何设置才能跑属性条件

因为属性条件中有时需要传入参数值做条件判断的依据，在表单上可以通过Parameters.Add方法传入，但模拟器中如何做呢？同样地也需要写代码传入，下面举个例子说明下。

这里我们把流程示例中的属性条件例子中的“启动”环节后面的两条迁移线上的属性条件改下，把属性名挪到参数名那里，如下：

流程模拟时，由于在“启动”环节时就要传入这个参数值，所以在模拟器的命令行窗口中加入如下代码行：

然后先点“运行命令”以让该行代码生效，然后再继续点“运行”即可。

XML条件（XMLCondition）

XML条件适用于各种复杂的计算，当流程绑定的业务数据或者参数是XML数据时，可以通过指定XML的XPath来计算。从而计算出条件是否成立。

数据表条件（TableCondition）

当业务数据绑定的是ADO .NET的DataSet的时候我们可以通过计算某个数据表中的某些数据是否大于等于某个固定的数据值来判断条件是否成立。

复合条件（CompositeCondition）

复合条件可以看作为一个条件的容器，通过与和或的关系，组合不同的条件以实现复杂的条件计算。

脚本条件（ScriptCondition）[Bingosoft.Workflow.Dynamic.dll]

利用Python脚本返回的值（只能返回布尔值）来指示迁移条件是否成立

注意上面的DataItems，里面的值可以是你在代码中加入Parameters属性中的值，也可以是由上一个脚本环节或Webservices返回的结果参数值。例如上图中的DataItems[“ScriptResult”]就是由上一个脚本环节返回结果来判断的，如图：

（步骤中返回的结果参数只能用于该步骤的后续迁移，不像在表单中加入Parameters的值一样能整个流程使用）