[MOSS开发]:WSS中的工作流

     WSS中的工作流定义:

          组织和管理一组工作单元或活动,形成工作流程的可执行文件表示形式。该流程几乎可控制 WSS中项目的各个方面,包括项目的生命周期。

     工作流的启动方式:

         1:由用户启动;

         2:根据某些事件(例如创建或更改项目时)自动启动。

     工作流的使用用户:

          WSS工作流程对于列表或文档库级别的最终用户可用。可以将工作流程添加到文档或列表项。也可将工作流程添加到内容类型。

      工作流和项目的关系:

            对于某个给定的项目,可以使用多个工作流程。可以对同一项目同时运行多个工作流程,但在任何给定时间内只能对特定项目运行特定工作流程的一个实例。

      SharePoint 工作流程技术体系结构:

           1:可以使用 Visual Studio 2005 Designer for Windows Workflow Foundation 创建工作流程。将每个工作流程编译为其自身的动态链接库 (.dll)。

           2:通过自定义工作流程表单可以将工作流程与用户直接交互。使用工作流程表单,可以在工作流程的每个阶段收集用户提供的信息。

           下图阐明 WSS 中总体的工作流程体系结构。场中的每个内容类型、列表和文档库都将链接到通过工作流程关联表为其添加的工作流程。每个工作流程都具有一个工作流程定义。此 XML 定义指定实际工作流程程序集的标识、该程序集中的类以及工作流程必须运行的任何工作流程表单的位置。



     工作流宿主体系结构:

         WSS 中的工作流功能构建于WF 基础之上,WF 是 Microsoft Windows 平台上的一个组件,它为开发和执行基于工作流的应用程序提供编程框架和工具。具体来说,WSS 使用由 WF 提供的两个组件:Visual Studio 2005 Designer for Windows Workflow Foundation 和 WF 运行时引擎。


      工作流程表单概述 :

           通过向工作流程添加表单,可以使工作流程更加动态和灵活。表单使您能够在工作流程生命中的预定义时间收集用户的信息,并可让用户与该工作流的任务进行交互。

      工作流程表单技术:

         1:WSS 工作流程是不可知的表单。只要表单支持,就可以使用所选的任何表单技术;
         2:调用 WSS 对象模型;
         3:生成要发送给 WSS 对象模型的必需数据;
         4:接收并分析 WSS 对象模型的所需数据。

      工作流程表单的类型:

         1:关联和初始化表单。在任何工作流程实际开始之前,将为用户显示关联和初始化表单以供其填写。可以使用这些表单以让用户能够在工作流程开始之前为其设置参数和其他信息。

         2:修改表单。修改是为用户显示的一些选项,以供其在针对某个项目运行工作流程时更改此工作流程。然后,可以创建使用户能够指定修改参数的修改表单。

         3:任务表单。也可以为工作流程中的任务指定自定义表单。不过,由于任务是分配了内容类型的 SharePoint 项,因此实际上是由内容类型来决定用于任务类型的自定义表单。   

       工作流程定义架构:

            每个定义工作流程的元素指令清单必须遵循工作流程定义架构。工作流程定义是一个 XML 文件,它包含 Windows SharePoint Services 实例化和运行工作流程时所需的信息,如下所示:

            1:工作流程的名称、GUID 和说明;

            2:此工作流程中使用的任何自定义表单的 URL 。

            3:工作流程程序集的名称和该程序集内要调用的类;

            4:(可选)工作流程要运行的任何自定义元数据。

          在MOSS中,工作流是做为一个Feature来安装的,所有创建个SharePoint的工作流工程后会生成两个XML文件:

            1:Feature.xml。这是安装工作流的,下面是一个具体的示例代码;

Code

 

            2:workflow.xml。示例代码如下:

Code

         

           上面的两个文件,最重要的是第二个,因为Feature文件只需要修改工作流安装后显示的Title,Description就行。而工作流的配置文件主要在workflow.xml文件中。最基本的要设置两个节点:

          1:Workflow 元素(元素):定义一个工作流程。详细参数如下:

属性 说明

Title

可选属性,类型为 Text

Name

必需属性,类型为 Text。指定 Windows SharePoint Services 界面中显示的工作流程名称。工作流程名称的长度最多可以为 256 个字符。

CodeBesideAssembly

必需属性,类型为 Text。指定程序集旁边的代码的强名称。

CodeBesideClass

必需属性,类型为 Text。指定用于生成工作流程程序集的代码旁置文件中的工作流程类的名称。此名称应包含类的命名空间。

Description

可选属性,类型为 Text。指定要在 Windows SharePoint Services 界面中显示的工作流程说明。此工作流程说明的长度最多可以为 256 个字符。

Id

必需属性,类型为 Text。指定工作流程的全局唯一标识符 (GUID)。

EngineClass

保留为将来使用。

EngineAssembly

保留为将来使用。

AssociationUrl

可选属性,类型为 Text。指定此工作流程的关联表单的 URL。将 AssociationURL 属性的值设置为要用于工作流程关联的自定义表单页。例如:

AssociationURL = "MyWkflAssociationPage.aspx"
注释注意:
Windows SharePoint Services 支持工作流程模板定义中的绝对路径或服务器相对路径。所有表单路径 URL 必须按照这些格式中的某一种格式表示。例如,绝对路径(如 "http://site/library/page.aspx");或服务器相对路径(如 "/layouts/page.aspx")。Windows SharePoint Services 不支持工作流程模板定义中修复的链接。

若要为工作流程的实例化和关联使用同一表单,请为该表单设置这两个元素。

有关关联表单的详细信息,请参阅工作流关联表单和初始表单 (Windows SharePoint Services)

InstantiationUrl

可选属性,类型为 Text。指定此工作流程的初始表单的 URL。例如:

InstantiationURL = "MyWorkflowInitiationPage.aspx"
注释注意:
Windows SharePoint Services 支持工作流程模板定义中的绝对路径或服务器相对路径。所有表单路径 URL 必须按照这些格式中的某一种格式表示。例如,绝对路径(如 "http://site/library/page.aspx");或服务器相对路径(如 "/layouts/page.aspx")。Windows SharePoint Services 不支持工作流程模板定义中修复的链接。

有关初始表单的详细信息,请参阅工作流关联表单和初始表单 (Windows SharePoint Services)

ModificationUrl

可选属性,类型为 Text。指定此工作流程的处理修改的表单的 URL。如果工作流程包含多处修改,可以使用此属性对指定的表单进行编程以:

  • 基于传递给此表单的修改标识符显示表单的不同视图。

  • 基于传递给此表单的修改标识符重定向到单独的表单。

有关修改表单的详细信息,请参阅工作流修改表单 (Windows SharePoint Services)

StatusUrl

已过时。不得使用。

TaskListContentTypeId

可选属性,类型为 Text。指定分配给工作流程任务列表的内容类型的内容类型 ID。

有关任务表单的详细信息,请参阅工作流任务表单 (Windows SharePoint Services)

 

          第二:Metadata 元素:

            1):Instantiation_FormURN。初始表单地址;

            2):Task1_FormURN。任务表单1;

            3):Task2_FormURN。任务表单2。

            4):上面2和3的任务表单编号是和后台代码相关联的:

//指定Task1使用的表单编号 
Task1_Properties.TaskType = 1;

 

     工作流阶段 :

           若要更好地了解什么是工作流以及如何在 Windows SharePoint Services 3.0 中使用工作流,讨论用户与工作流进行交互的各个阶段很有必要。下面是从管理员和最终用户角度对工作流程进行的描述。

           1:工作流关联。工作流安装在服务器级别上。网站集管理员仍必须启用工作流以将其用于服务器上的特定网站集。然后,网站管理员可以将特定工作流与列表、文档库甚至内容类型关联。他们可以选择与给定的列表、文档库或内容类型相关联的可用工作流。然后,他们通过设置一般工作流参数信息来自定义工作流。

          2:工作流启动。相应角色(管理员和参与者等)中的任何用户都可以启动配置为手动启动的工作流。

          3:工作流状态。用户可以查看所选项上的工作流的进度。主文档库或列表项页显示项上运行的当前状态工作流。此外,每个项都有用户可以在其中查看以下信息的工作流页:

             1):当前在此项上运行的所有工作流;

             2):以前在此项上运行的所有工作流;

             3):可用于此项目的所有工作流。


          4:工作流任务完成。工作流阶段显示为工作组网站任务列表上的任务。设计工作流时,工作流作者可以指定任务架构。例如,任务列表可能包括:任务标题;向其分配任务的用户的名称;任务状态;任务优先级;任务过期日期;指向引用的项的链接。

      工作流程类型 :

            1:顺序工作流程。顺序工作流程以按顺序执行直到最后一个活动完成的一系列步骤的形式表示工作流程。但是,顺序工作流程并不是完全按顺序执行的。由于它们可以接收外部事件并包含并行的逻辑流,因此活动执行的准确顺序会稍有不同。

            2:状态机工作流程。状态机工作流程表示一组状态、转换和操作。将一种状态指示为开始状态,然后可基于一个事件对另一种状态进行转换。状态机可以具有确定工作流程结束的最终状态。

      设计工作流流程图:

          1:顺序工作流按预定的活动顺序执行。为了实现这一个可以循环的过程,我们可以利用WhileActivity活动。每一个活动跳出循环的条件是审批通过。

          2:WhileActivity活动的条件分为两种:1:代码;2:代码规则。

          3:活动容器:一个WhileActivity活动只能包含一个子活动,子活动可以利用SequenceActivity。

          4:SequenceActivity的生命周期:

              1:CreateTask;2:onTaskChanged;3:CompleteTask;4:DeleteTask。

          5:任务的退回操作?例如一个审批的任务,总共有两种操作,批准和不批准,我们希望当审批者不批准些任务时把任务返回给原始提交用户,这种情况我们可以利用IfElse来完成。下面是示例图:


          6:并发的实现则需要借Windows Workflow选项卡中的ParallelActivity,当所有分支都结束后它才会结束。下面是示例图:


        7:创建日志记录的工作流程:我们可以从工具箱中拖放一个logToHistoryListActivity,如果在后台代码中想手工调用它,可以在代码中声名变量:

public String HistoryDescription1 = default(System.String);

 

           调用:

if (task2Approved == true)
            {

                
this.HistoryDescription1 = "二级审批通过";
            }
            
else
            {

                
this.HistoryDescription1 = "二级审批不通过";

            }

     开发工作流时新手特别需要注意的地方:

           1:工作流程表单,在提交表单时,对提交按钮的规则设置上有一定要求,一定要有一个关闭表单的动作,具体如下图所示,如果没有,无论你怎么提交都没有反应。

 

          2:用VS创建工作流时要注意选对模板。下图创建的是一个SharePoint顺序工作流。

 

         3:同一组的任务活动都必须设置相同的CorrelationToken,TaskId属性,不同组的这两个属性要不同;

         4:onTaskChanged的afterProperties属性设置为和CreateTask活动的TaskProperties属性相同的变量(这样做的目的是默认保存用户对Task的修改)。

       学习过程中遇到的问题:

           我看了园友笑煞天以及《案例实战开发》关于多级审批的文章。我拿笑煞天的说一下。工作流中不同级别的审批者需要不同的表单:

           1:送审者则需要两张,一张用于启动工作流(Init),一张用于在审批被拒绝时修改(Task0);

           2: 第一级审批者需要一张(Task1);

           3: 第二级审批者需要一张(Task2);

          4: 两个第三级审批者使用同样的表单(Task3)。

        在上面多级审批的工作流中,用户A提交一个任务给用户B审批,用户B通过状态页_layouts/WrkStat.aspx进入到任务查看页面,此时页面需要读取用户A提交的表单(Init)中的内容,文章是在onWorkflowActivated_Invoked事件中处理,代码如下:

Code


        当审批者用户B进入到审批页面后,在createTask1_MethodInvoking事件中读取Init表单信息。代码如下:

Code


       我在开发实践中发现,用户B进入到审批页面并不能读取到Init表单信息,如果想读取Init表单信息需要通过反序列化Init来读取,onWorkflowActivated_Invoked事件中设置Task1的标题和分配对象,好像没起到作用。即task0_Properties.ExtendedProperties["comments"] = init.comments;赋值后,在createTask1_MethodInvoking访问不到。

      我的解决方案:不在onWorkflowActivated_Invoked直接赋值,而是在createTask1_MethodInvoking中加一个判断。代码如下:问题是解决了,但总觉的这样写和大家写的不太一样,本人才疏学浅实在不太明白其中的原因,如果哪位朋友知道请指教。

Code

 

      总结:

           整理了WSS中的工作流的部分基本知识,在开发WSS工作流之前这是非常重要的基本知识。知道WSS工作流是什么,能做什么才好在项目中应用它。

注:

   本文参考:WSS SDK

                 《MOSS 07案例实战开发》

posted on 2009-02-05 14:52  min.jiang  阅读(3306)  评论(5编辑  收藏  举报