Fire workflow1.0的模型和引擎架构给这个开源产品长远发展奠定了一个较为扎实的基础。现在是时候考虑一下后台管理功能了。主要琢磨如下问题
1、设计目标
后台管理的设计目标当然首先是好用,因为这个功能是针对最终用户的所以必须傻瓜化。让人一看就知道怎么用。
2、功能列表
a)实例查询:任何一个实例,当前的执行状态
b)实例管理:如实例的挂起、恢复、强行中止
c)图形化的流程跟踪与回放:通过图形描述当前执行路径,并且图形可以和界面javascript交互。图形可以回放,动态显示流程执行历史。
d)流程实例数据管理:将已经结束的流程实例数据导入到历史表中,提高系统性能。
e)流程自调整:很多人向我强调“流程自定义”,我认为Fire 是比较适合“流程自调整”,而不是完全从无到有的“自定义”,当然经过ISV的封装之后,一定程度的自定义还是可以做到的。Fire 的自调整主要体现在,可以把业务逻辑随时挂接到流程上去运行,调整流程逻辑后系统可以立即运行,等等。Fire workflow的模型在这一点上做了针对性的设计。
f)查询统计,如当前未完成的实例数量、超时的工单数量、工作量统计等等。
3、技术选型
初步考虑用Flex技术。
诚挚欢迎大家提建议,更多信息请访问www.fireflow.org
1、设计目标
后台管理的设计目标当然首先是好用,因为这个功能是针对最终用户的所以必须傻瓜化。让人一看就知道怎么用。
2、功能列表
a)实例查询:任何一个实例,当前的执行状态
b)实例管理:如实例的挂起、恢复、强行中止
c)图形化的流程跟踪与回放:通过图形描述当前执行路径,并且图形可以和界面javascript交互。图形可以回放,动态显示流程执行历史。
d)流程实例数据管理:将已经结束的流程实例数据导入到历史表中,提高系统性能。
e)流程自调整:很多人向我强调“流程自定义”,我认为Fire 是比较适合“流程自调整”,而不是完全从无到有的“自定义”,当然经过ISV的封装之后,一定程度的自定义还是可以做到的。Fire 的自调整主要体现在,可以把业务逻辑随时挂接到流程上去运行,调整流程逻辑后系统可以立即运行,等等。Fire workflow的模型在这一点上做了针对性的设计。
f)查询统计,如当前未完成的实例数量、超时的工单数量、工作量统计等等。
3、技术选型
初步考虑用Flex技术。
诚挚欢迎大家提建议,更多信息请访问www.fireflow.org