流程设计器的界面设计

  现在的业务分工越来越细，很多客户指定要求上工作流系统，就一定要包含流程设计器。而很多开源的工作流系统，都只注重流程引擎部分，或更注重和各种开源的框架,orm等的集成，流程设计器或者根本就没有。这使得很多找开源的工作流系统的系统集成商，不得不面临着要自己写一份工作流设计器，常常在论坛中见求xx流程设计器的。
    
    通常一套工作流系统，流程引擎是核心，灵魂部分，体现了工作流的运转设计思路。流程设计器，就相当于表现部分，利用流程设计器可视化的设计流程，客户不管自己是否会设计流程，都需要开发商提供设计器。有了流程设计器，就可以不了解流程的基本模版定义文件，也能设计出业务流程。
    
    为了能更方便的体现业务流程，更方便的理解工作流系统，流程设计器的操作和属性设置一定要做的简单，让人一看就知道如何操作。
    
    流程设计器是体现流程引擎，所以，一定要能快递方便的制作出，顺序流节点，条件跳转，循环，分支，合并，子流程等等。
    
    
    流程设计器的界面部分一定要有工作流引擎支持的那些基本节点。如步骤，分支，合并，子流程等等。（步骤有的工作流系统叫任务，主要看流程引擎是如何定义这些节点的）
    
    再通过拖拉的方式，能快速的在界面上放置这些节点，画上连线使得这些节点能连贯起来，组成顺序流，循环等等，使人一目了然。
               
    如我们公司的eworkflow工作流系统：
    

    
    当然，流程设计器还要包含一些基本的，打开，保存，流程属性页面等，流程属性页面中录入流程的名称，版本等信息。
    

   

    

    

    
    有了这些基本的节点和功能，就能给业务流程建模了，类似把业务流程的流转单独抽出来了，但具体的业务办理，每个节点的办理人等等的设置，还需要在每个节点的属性页面上设置。
    
    节点上办理的具体业务，我们通常是集成业务表单来完成，在表单中提交业务数据的同时，再调用流程引擎提供的api，使得流程流转到下一步个节点。
    
    
    节点上的属性页，提供这些基本属性的设置。
    如设置节点上办理的业务表单，
    节点的办理条件，
    节点的结果条件设置，
    任务节点的选择办理人，
    任务设置超时提醒
    节点上的一些备注信息
    

    

    

    

    
    
    比较重要的是，通常在流程的节点上，都要设置有一些前置后置的事件，前置事件，就是当流程运行到这个节点之前自动触发执行，后置事件就是当流程流转离开这个节点的时候，自动触发执行。
   

    

    
    前置后置事件体现工作流系统的扩展性，可以将一些业务过程业务处理等外挂到这里。如，当员工的报销审核不通过，打回给填写报销单的人重新填写时候，就可以在节点的后置事件中找  填写报销单的执行人。

 

最近有好几个客户都提出，需要实现在上一个流程节点办理的时候，由用户去选择下一步任务的执行人。

这种需要在我们的工作流系统中，早就有相关的实现。是在下一步节点任务的参与人先设置一个虚拟的审核人checker。然后用户在上一个节点办理的时候，将选择的用户id存到这个checker中，再将这个checker以变量的形式送到流程引擎中，流程引擎在创建下一步任务的时候，就将用户选择的人生成到任务的参与人了。也可以多选，多选的用户id以逗号分隔的方式存到checker变量中，选择后的值为 USR_0000001,USR_0000002,USR_0000003... 这样。

但是又有客户提出，需要在上一个节点办理的时候，由用户去选择下一步骤任务的执行人，并且这个选择范围是在流程设计器中圈定，如审核报销单的时候，审核人必须是部门经理，再在每个流程实例运行的时候，由上一步填写人提交的时候，去选择一个部门经理来审核。

这种需求还是按上面那种方式来处理，在下一步节点任务参与人先设置一个虚拟的审核人checker，然后在上一步节点办理的表单中，选择下一步任务的参与人列表，只列出部门经理来。这样也能达到客户的要求。

但是，又有客户提出了，圈定的范围必须要在流程设计器中定义任务的时候，先圈定好，在上一步节点办理的表单中，读出这个范围，再由用户去选择，这样就不必在表单中固定好选择范围

这种需求我们现在的产品中没有，客户是上帝，提出的又是合理的需求，我们必须要想想怎样去实现了.....

开始总想着在流程设计器任务节点属性中，加上定义范围的功能，但这样太繁琐了，要定义任务参与人，又要定义任务可选择的范围，而且可能是按用户，按角色，按群组等等。。。。。太繁琐了，不是好方案

应该借助任务参与人的这个范围，而且客户提出的也是，在任务定义的时候，定义的任务参与人就是可选择的范围，增加表来存储用户的选择结果也不是好的方案，会使得得复杂和繁琐。

还是利用一个临时变量appoint_nexttask_operator来处理又简单又能解决问题，在上一步节点的办理表单中，读出下一步任务节点的参与人列表（利用流程引擎的API来获取），将用户选择的结果存到appoint_nexttask_operator这个变量中，将此变量送到流程引擎中，流程引擎在生成任务之前，先判断这个变量是否有值，有值，就将此变量中的值生成到任务参与人，没有则用流程定义时的参与人。也可以多选，用逗号分隔。

^_^，这样，也不用额外增加定义的表等，就能完美的解决这个需求了，读出下一步任务节点的参与人，我们利用api写一个通用的方法，在表单中只要调用进来，就可以了。

在定义的时候，可以加用户，角色等

在第一个节点办理的表单中，读出任务定义的参与人

选择后，就是下一步的审核人了。

 

 在工作流系统中，通常流程的流转是以任务的传递来实现的。以顺序流为例，一个节点办理完成后，到达下一个节点，产生下一个节点办理人的任务信息，任务有待办，已办，待签收，任务参与人，执行人，任务开始日期，完成时间等等。任务滞留长时间未处理，还会有催办，任务提醒等等。

工作流引擎主要是处理抽象的业务流程的流转，不是处理这些任务的基本信息，但是对这些任务的基本信息的管理确是工作流软件产品中必须处理的。任务办理完成后的结果是流程流转到下一个节点，流程实例的下一步的办理通常也是从我的待办任务列表中链接进入，对已办任务的管理，也可以查询和监控曾经的工作情况。

    因此，工作流系统中，当一个任务产生后，在任务参与人的待办任务列表中，就能查看到了，点击就能办理此项任务。对于重要的任务信息，工作流软件系统还应该设置提醒，或手机短信或电子邮件等方式来通知用户及时办理任务。提醒的方式有多种，也可以是即时通讯工具的方式来提醒。
    
    在工作流系统中，应该设计好这些接口，在任务信息定义的时候，就应该做好提醒的设置，每条任务信息可设置不一样的提醒方式。
    如，A任务是一般性的任务，只发送电子邮件，就可以了。
        B任务比较紧急，任务到达后，需要每天都提醒用户去处理，直到处理完成。
        
    在任务创建的时候，需要发送提醒
    在任务完成时候，需要对另外一组用户做提醒，如通知流程发起人这个节点已经处理完成了。
    在任务超期未完成时，需要不断的去提醒他登录系统，处理超期的任务。或者当任务超期后，可选择性的退回到上一个节点，重新分配。
    
    
    这些设置在流程设计器的任务属性中，需要有定义的界面。
   

    
    
    
    有的任务提醒，可能是发送系统消息＋手机短信＋电子邮件 这几种都需要有。
    
    当设置好提醒的参数后，在流程实例流转时，到达节点，产生任务，再根据这些设置的参数产生提醒，需要不间断的发送提醒，还需要启动任务提醒定时器，按设置的时间间隔，触发发送提醒。
    
    在我们eworkflow工作流系统中，集成任务定时器的发送开启和关闭。当任务节点设置了提醒功能后，任务创建后，提醒定时器开启，当任务完成后，会关闭提醒定时器。

    
    触发提醒Job后，可以发送系统消息，手机短信，电子邮件等。每种job对应一个后台类，在类中做相应的处理，取任务参与人的手机号，电子邮件等，再集成发送邮件短信，发送电子邮件等的功能。用户也可以实现Job接口，自己编写实现的处理类，然后在流程设计器中，将处理类挂接到任务提醒设置上，使得A任务的提醒 用A处理类；B任务的提醒用B处理类。

java的发送系统消息的job实现类：

标签:  web开发平台,  java工作流,  流程设计器,  自定义工作流,  web工作流,  自定义表单,  工作流引擎,  .net工作流,  .net工作流系统,  工作流软件产品,  java电子表单