web工作流管理系统开发2125文档格式.docx
- 文档编号:22368990
- 上传时间:2023-02-03
- 格式:DOCX
- 页数:19
- 大小:409.51KB
web工作流管理系统开发2125文档格式.docx
《web工作流管理系统开发2125文档格式.docx》由会员分享,可在线阅读,更多相关《web工作流管理系统开发2125文档格式.docx(19页珍藏版)》请在冰豆网上搜索。
此处如果写入业务从表的是流程节点id是不行的,流程回退,取回,一个节点重复执行时,就标识不了了。
此为流程轨迹主键id的另一种用法。
流程轨迹主键id还有一种更为巧妙的用法,作为流程主动取回后,再次发送,流程下一节点是否可执行的判断标志。
流程实例的每次执行操作之前将流程轨迹id传递到前台,等待用户执行操作。
提交操作时,取道页面传递回来的轨迹主键id,和流程轨迹表中当前步骤的轨迹id相比较,如果一致,则可以继续操作,如果不同,则表示流程轨迹已经发生了变化,需要再次打开链接重新执行此节点的操作。
二十二dotnet版工作流引擎
工作流管理系统为实现流程的自动化,必须包含一个工作流引擎,工作流引擎负责流程的定义,解释和运转。
流程引擎是对业务流程的一个抽象,因此工作流引擎的设计模型是决定流程功能的重中之重,将直接影像流程的各个环节。
一套工作流管理系统还包含很多个必须要实现的部分,如:
事件处理,任务处理,组织机构的适配,自定义表单等等。
以及很多中国式的“动态会签,回退,自由流”等等变态需求。
但抛开这些,只关注每个流程的最基本的部分,即解决一个过程运转的问题,从一个环节到另一个环节,使得流程能够运转起来。
这应该就是流程引擎要实现要关注的基本问题,即流程引擎的抽象。
工作流引擎模型有很多种,FSM、PetriNet、EPC、ActivityDiagram等等,不论采用那种流程引擎模型,最终都需要能将业务流程用流程引擎的符号或元素表述出来。
我们公司的eworkflow自定义工作流系统dotnet版,流程引擎采用C#语言实现了FSM有限状态机的流程引擎模型。
有限状态机是一种数学模型,广泛应用于流程引擎,rpg游戏等领域。
是表示有限个状态以及通过执行动作使得状态发生转移的数学模型。
状态转换图:
工作流引擎的模型正是利用这种定义的有限个状态和动作,动作的结果导向另外一个状态来达到流程的流转。
工作流引擎的每一个状态=一个业务环节+业务环节的状态
业务环节:
即为一个虚拟的业务操作场所
业务环节的状态:
即为一个具体的流程运转到此业务环节的实际状态。
流程引擎对流程的描述通常是采用xml格式的文档来描述,xml文档中的每个节点都赋予了一定意义,各节点作为流程定义的基本元素,流程引擎能够定义、解释和应用它们来描述尽可能多的业务流程。
一个简单的流程描述xml文件:
上图xml流程的图解状态过程如下:
开始节点-》初始化动作--》步骤节点-》动作节点--》结束
xml文件中基本元素即工作流引擎的基本元素:
步骤(step)
一个step描述的是工作流所处的位置。
可能从一个steptranstion到另外一个step,或者也可以在同一个step内流转(因为step可以通Status来细分,形成多个state)。
一个流程里面可以有多个step。
状态(status)
状态status是用来描述工作流程中具体step(步骤)状态的字符串。
eWorkFlow中预置了三种步骤的状态Underway(进行中)、Queued(等候处理中)、Finished(完成),用户可以任意扩展自己的状态。
而工作流的状态state则是由step(步骤)+status(步骤的状态)组成的。
工作流状态state的升迁来达到工作流实例的推进。
流转(transtion)
一个工作流实例状态state到另一个状态state的转移。
动作(action)
action触发了发生在step内或step间的流转,或者说是基于state的流转。
一个step里面可以有多个action。
action和step之间的关系是,step说明“在哪里”,action说明“去哪里”。
一个action典型地由两部分组成:
可以执行此action(动作)的condition(条件),以及执行此动作后的result(结果)。
任务(task)
任务是当工作流状态发生转移的时候,产生的任务。
任务可以指定为一个具体的角色,人,或者群组。
任务具体,待办,已办,竞争办理,代理待办等多种功能。
条件(condition)
类似于逻辑判断,可包含“AND”和“OR”逻辑。
比如一个请假流程中的“本部门审批阶段”,该阶段利用“AND”逻辑,判断流程状态是否为等候处理中,以及审批者是否为本部门主管。
结果(result)
Result代表执行action(动作)后的结果,指向新的step及其stepstatus,也可能进入split或者join。
result分为两种,contidional-result(有条件结果),只有条件为真时才使用该结果,和unconditional-result(无条件结果),当条件不满足或没有条件时使用该结果。
分支/合并(split/join)
流程的分支和合并。
分支是指流程下一步可以同时分发给多个步骤,分支split提供多个unconditional-result(无条件结果);
join则判断多个currentstep的状态提供一个result(结果)。
子流程(subflow)
子流程,动作的结果可以指向一个子流程,子流程是一个独立的流程,可以单独启动也可以嵌套在另外的流程中启动,和主流程有同步或异步衔接的属性。
工作流程引擎利用这些基本的元素,能够实现各种类型的路由。
1、串行:
就是一个步骤流向下一个步骤的基本路由方式。
2、并行:
一个步骤下可以执行多个动作,动作的结果可以流向不同的步骤,这是并行路由的一种方式。
3、条件:
步骤的动作结果可以设置条件,满足条件的则流向条件结果。
4、分支:
动作结果可以流向一个分支,分支可以同时流向多个不同的结果步骤,这也是并行路由的一种方式。
5、合并:
多个结果流向一个合并节点,合并节点满足一定条件后,就可以流向下一步骤。
6、循环:
动作的结果指向本步骤或上一步骤,形成循环路由。
7、子流程嵌套:
在工作流中嵌套执行另一工作流,叫子流程嵌套路由,子流程可以是同步执行和异步执行两种属性,主子流程可设置输入输出参数来达到信息的传递。
8、自由跳转:
流程实例运行当中,正常的流程是按照流程定义的节点往下执行,自由跳转就是可以跳转到任意的步骤,执行过和未执行过的步骤。
9、回退:
回退是指当流程实例运行过程中,由于某些原因回退到已经执行过的某个步骤,并辅助执行业务补偿,使得业务数据也回退到已经执行过的步骤状态。
要了解一个工作流系统,必须要先理解流程引擎的模型,理解了流程引擎的原理,模型,就如同掌握这套工作流系统的灵魂,然后再去理解它的全部。
否则,一套工作流系统对你来说,可能只是一些复杂的结构,丰富多彩的示例,眼花缭乱的功能等等。
二十三图解工作流的基本路由方式
上一篇主要说明dotnet工作流引擎的基本原理和引擎的基本元素。
这篇主要以图解的方式说明工作流引擎的运转模型,路由方式。
一个业务流程包含一序列的处理过程,以及他们的相互顺序关系,还包括过程的启动条件,过程循环,同时还会辅助一些相关的事件消息处理等。
工作流引擎负责创建,定义,解释和运行业务流程,首先需要将业务流程的处理过程转化为流程的基本元素、基本节点,然后将业务处理过程之间的顺序关系用流程引擎支持的路由方式表达出来,再设置好一些相关的事件消息处理等,业务流程就创建完成。
然后再运行流程,启动流程实例,运行业务流程,流程引擎负责解释流程的各节点以及按路由方式运转业务流程。
因此流程的运转模型,支持的路由方式也是工作流引擎的核心内容。
常见的运转模型,基本路由方式:
串行路由:
最简单,也是最容易理解模型,一个步骤接着一个步骤的基本路由方式。
eWorkflow中的图例:
并行路由:
一个步骤接下来分出多个同时可以执行的步骤,通常会由分支节点分出。
条件路由:
满足条件后导向一个步骤,不满足条件的导向另外一个步骤,就如同代码中的
if(条件1)
步骤1
elseif(条件2)
步骤2
elseif(条件n)
步骤n
...
else
步骤n+1
eWorkflow中的图例:
分支路由:
分支路由平行分支出多条线路,多条线路之间是并行的关系。
eworkflow中的图例:
合并路由:
并行的多路分支集结到一个点的路由方式。
eworkflow中的图例:
循环路由:
下一步返回到原来的任意一个步骤,这之间形成的回路就是一个循环路由。
可以由多个步骤构成一个循环路由,也可以自己返回到自己,这样的自循环路由。
子流程嵌套:
在工作流中嵌入另外一个独立的流程,主流程的下一步为启动另外一个流程,这样的结构为嵌套自流程。
子流程可以是同步执行和异步执行两种属性,主子流程可设置输入输出参数来达到信息的传递。
自由跳转:
这种是很特殊的路由方式,在流程实际运行时跳出原来定义的线路,自由跳转到任意的步骤。
回退:
和自由跳转类似,在流程实际运行时跳出物理的回退方式,可以任意的回退到曾经运行过的步骤。
动态多路分支路由:
在流程定义的时候只定义一条分支后的运行线路,在流程实际运行时根据实际情况动态创建出n条分支线路。
标签:
自定义工作流,工作流,工作流引擎,dotnet工作流引擎
二十四如何构建支持多数据库的.net工作流系统
主流数据库有,sqlserver,oralce,db2,mysql。
产品级的.net工作流系统必须要能支持这多种数据库,同时还需要能方便的扩展支持新的数据库。
在做数据库操作方面,java和.net的各不一样,java是利用jdbc的一套类库来做数据库的读写。
但.net的就比较多了,微软提供的就有oledb,sqlclent,oracleClient,odbc等,还有一些第三方提供的访问类。
所以在做多数据库支持方面,.net工作流系统,就需要考虑这些方式都支持,并且能很容易的切换。
C#数据库多种访问方式类框图
首先按上面的类框图,设计好类接口关系。
DbProvider:
为数据库类实现方式的接口,提供有打开数据库,关闭,启事务,事务回滚,事务提交等方法。
OleDbProvider:
为oledb方式的连接数据库的实现类,实现DbProvider接口;
OracleDbProvider:
为oralceClient方式的连接数据库的实现类,实现DbProvider接口。
SqlDbProvider:
为SqlClient方式的连接数据库的实现类,实现DbProvider接口。
DbProviderFactory:
负责创建具体的实现类,根据传入的参数来创建具体的数据库操作实现类。
Environment:
为需要获取数据库连接的类。
具体的数据库连接参数,在bin\fcconfig.xml文件中,fcconfig.xml文件如下:
第一个ds子节点为工作流系统的默认连接(注:
fcconfig.xml文件.net工作流系统和java工作流系统一致,只是具体的属性值设置不一样。
)
type属性="
sqlclient"
则为使用SqlDbProvider类创建的DbProvider。
oracleclient"
则为使用OracleDbProvider类创建的DbProvider.
oledb"
则为使用OleDbProvider类创建的DbProvider.
在对外的操作中屏蔽了sqlClient,OracleClient,oleDb等的差异。
一个简单的使用实例如下:
Environmentenv=newEnvironment(Session);
DbProviderdb=env.getDbProvider();
env.beginTransaction();
stringsql="
"
;
sql="
insertintowf_user(user_id,user_code,user_name,user_password,user_status)"
sql+="
values('
1'
'
xx'
)"
db.ExecuteNonQuery(sql);
sql="
selectuser_code,user_namefromwf_userwhereuser_id='
;
System.Data.IDataReaderds=db.ExecuteSqlReader(sql);
if(ds.Read())
{
stringusercode=(string)ds["
user_code"
];
stringusername1=(string)ds["
user_name"
}
ds.Close();
deletefromwf_userwhereuser_id='
mitConnection();
env.closeConnection();
当如果没有写数据库操作时,则不需要env.beginTransaction();
和
直接使用db就可以了。
二十五.net工作流系统开发体会
.net工作流系统开发体会
公司的eworkflow自定义工作流系统,最初是开发了java版的。
待java版的功能稳定后,就开始开发.net版的。
java版的eworkflow工作流系统,我们没有依赖于任何框架,如struts,spring等,也没有用hibernate,ibatis等orm映射工具。
在支持web方面也有一套自己的mvc框架,都是纯java的代码。
因为工作流系统,比较注重的是工作流引擎核心的实现,其他的表现形式,人机交互等都相对不是工作流系统的重要部分,并且业务模块的自定义表单采用的是eform自定义表单,所以在mvc的框架中,我们只需要注重M部分的流程引擎的开发。
在用.net实现工作流系统的时候,只需要将java版的后台纯java的代码,用.net的c#来实现。
java和c#就象孪生兄弟,长的太象了。
都是纯面向对象的,有类,接口,继承,多态等。
只是关键字的写法不一样。
我们只需一点一点的将java实现的流程引擎代码用c#翻译过来即可,保留所有的java设计思路,设计模式,包名类路径等。
为实现同样的功能,c#的语法有的更简单、方便一些。
因为java版的eworkflow没有依赖于任何开源的框架,所以在实现上少了这些开源框架代码的移植。
工作流系统框架图:
用c#实现eworkflow工作流系统主要需要修改如下方面的代码。
java版:
基本的语法,类定义,包名等
c#版:
改用c#的语法,关键字等。
c#的命名空间比java的package更灵活。
数组,集合等方面的实现
翻译成对等的数组,集合等。
xml的实现采用jdk1.4自带的包
c#:
xml的实现采用System.xml
在所有涉及xml节点部分的代码全部转换过来。
数据库操作采用jdbc
c#:
数据库的实现比较麻烦。
有oledb,sqlclient,oracleclient。
这部分的实现与java版的不同,但仅限于实现方面不同,.net工作流系统的数据库实现采用了工厂模式封装了oledb,sqlclient,oracleClient的不同,对外表现形式和java工作流系统一样,在所有涉及数据库操作的部分代码逻辑还是一样。
(.net工作流系统的数据库实现见上一篇文章:
如何构建支持多数据库的.net工作流系统
反射部分有反射包
翻译成c#的反射实现。
流程定义时自定义脚本,采用了beanshell。
.net方面没有类似的软件,自己开发了一个支持自定义脚本功能,脚本语法是c#(和java版的一样,java版的beanshell脚本语法是java),实现动态编译和加载。
还有很多细节方面的修改,散布在各处。
总之,java版的eworkflow工作流系统和.net工作流系统也象孪生兄弟一样,功能是一样的,只是实现方式不同。
java工作流,自定义工作流,工作流引擎,dotnet工作流引擎,.net工作流,.net工作流系统
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- web 工作流 管理 系统 开发 2125