基于WF设计业务流程平台_消息收集、通知接口
2008-12-06 16:38
549 查看
基于WF设计业务流程平台_消息收集、通知接口
如果有非系统用户需要与业务流程的某些结点有信息交互行为,如以下业务需求
![](http://images.cnblogs.com/cnblogs_com/foundation/120608_0836_WF1.png)
设计方案A
![](http://images.cnblogs.com/cnblogs_com/foundation/120608_0836_WF2.png)
这种方案的问题:
接件人与审批人都有需要通知申请人的业务职责,
但申请人是非系统参与人员,审批人与申请人的信息交互比审批人与接件人的通信要困难很多。
而且接件人或审批人的通知行为系统无法有效控制
另外,申请人要想查询事项进度,也没有一个有效的查询点
为了解决以上问题,可以使用以下两种方案之一,或混合使用
设计方案B
将申请人纳入系统边界,申请人享有的权力:
拥有一个与具体事项对应的用户名,可以登录系统查询事项进度与办理人员的各种通知。
申请人的义务:
定时查看事项进度与各种通知,如果因为没有及时查看,所带来的后果由申请人自已承担。
![](http://images.cnblogs.com/cnblogs_com/foundation/120608_0836_WF3.png)
在这种设计中,如果有事项的其他关系人,办事人员与其他关系人的联系方式有两种
1.由申请人做中介,办事人员将通知发给申请人,由申请人联系其他关系人
2.办事人员直接联系其他参与人,与设计方案A办事人员直接联系申请人一样
其他关系人对事项的了解只能通过申请人进行
设计方案C
申请人在系统边界以外,设立专门的通知部门,通知部门负责与申请人联系,
接件人,审批人只要将事项通知传递给通知部门就完成任务
申请人只能到通知部门查询事项。
通知部门可以主动联系其它事项参与人
其它事项参与人也可以主动与通知部门联系
![](http://images.cnblogs.com/cnblogs_com/foundation/120608_0836_WF4.png)
设立窗口部门的方案
将通知门部的职责,与接件人的职责合并窗口是申办人员与办事部门的唯一接口
窗口负责所有事项的接件,通知,查询,以及事项的分配
![](http://images.cnblogs.com/cnblogs_com/foundation/120608_0836_WF5.png)
非电子资料的收集、管理方案
由窗口部门或专门的非电子资料管理部门管理申请人向非电子资料管理部门提交,
各事项审批人、参与人从非电子资料管理部门申请调出,使用完后归还非电子资料管理部门
非电子资料管理部门维护资料安全,安排资料的使用顺序
事项完成后,资料归还当事人或由非电子资料管理部门归档保管理
资料的收集也可由该部门完成,或由需要人向该部门提出,该部门再向其他部门收集或安排专业部门进行
![](http://images.cnblogs.com/cnblogs_com/foundation/120608_0836_WF6.png)
向非系统参与者提供通知服务的方案
关于信息同步的问题
![](http://images.cnblogs.com/cnblogs_com/foundation/120608_0836_WF7.png)
传统方案,双方式事先约定好日期
双方式事先约定好日期,申请人,在约定好的日期去取通知![](http://images.cnblogs.com/cnblogs_com/foundation/120608_0836_WF8.png)
方案A,将申请人纳入系统
见[平台的信息收集、通知接口]的[设计方案B]方案B,推信息
系统以如下方式将信息推送给申请人![](http://images.cnblogs.com/cnblogs_com/foundation/120608_0836_WF9.png)
方式 | 说明 |
人到人签通知单 | 办事人员主动告之申请人,并由申请人签收通知单, 办事人员将签收结果录入系统 |
电子邮件 | 系统发送电子邮件后,系统完成事项 |
系统发送电子邮件,申请人收到并发回执后,系统完成事项 | |
短信 | 系统发送短信后,系统完成事项 |
系统发送短信,申请人收到并发回执后,系统完成事项 | |
电话 | 系统自动拨打有声电话,指定号码提听后,系统完成事项 |
系统自动拨打有声电话,指定号码提听,并按语音提示完成操作后,系统完成事项 | |
传真 | 与电子邮件同 |
方案C,拉信息
申请人主动查询,如果申请人没有主动查询,在规定的时间内,系统将安默认操作处理事项![](http://images.cnblogs.com/cnblogs_com/foundation/120608_0836_WF10.png)
方式 | 说明 |
人到人询问 (非电话方式) | 申请人找相关人员询问事项,如果事项处于需要申请人参与状态,即时告之申请人事项状态,并要求申请人签通知单,并将签收结果录入系统 |
短信查询 | 申请人发事项识别码短信到指定系统,系统将事项状态以短信发回后事项进入下一状态 |
电话查询 (人工提听或系统提听) | 申请人打电话,接通后提供事项识别码,工作人员或系统将查询到的结查语音告之, 事项进入下一状态 |
网络 | 参见[方案A,将申请人纳入系统] |
方案D,发公告
办理人员向媒体发公告,当事人看到公告后,到办理人员处取通知,
通常用在法定情形,或具有众多当事人的的事项,如资格申抱,录取发榜
![](http://images.cnblogs.com/cnblogs_com/foundation/120608_0836_WF11.png)
参与系统业务行为的方式
系统登录电子邮件回复
电话操作
短信回复
事先设定规则
相关文章推荐
- 基于WF设计业务流程平台_参与者与任务列表
- 基于WF设计业务流程平台_功能列表
- 基于WF设计业务流程平台_同一流程多种状态
- 基于WF设计业务流程平台-架构
- 基于WF设计业务流程平台_特定群体与特定人
- 基于WF设计业务流程平台-架构
- 基于WF设计业务流程平台-权限体系
- 基于WF设计业务流程平台_参与者的权限
- 关于[一个基于WF的业务流程平台]表设计的说明
- 基于WF设计业务流程平台_工作域与一人多部门多职能
- 基于WF设计业务流程平台_权限在流程模板外部映射
- (WF索引)基于WF设计业务流程平台
- 基于WF设计业务流程平台_流程的层次
- 基于WF设计业务流程平台_数据冲突
- 一个基于WF的业务流程平台
- 研读《基于Hadoop的海量业务数据分析平台的设计与实现》----flume的数据收集系统的设计
- 一个基于WF的业务流程平台
- 一个基于WF的业务流程平台
- 基于Wxwinter.BPM 的MEF 接口开发业务流程
- 基于.NET平台的分层架构实战(五)——接口的设计与实现