锁定老帖子 主题:业务系统如何集成工作流系统
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2012-07-26
常常有人会问业务系统如何集成工作流系统,在最初接触工作流系统的时候,确实会有些困惑,下面就从几个方面说明集成的过程。
业务表的准备: 额外增加一个流程实例id字段(wf_id),存流程实例id,用于和建模好的业务流程关联上。
主业务表的界定: 采购单申请《--》一审--》二审--》结束
业务模块的创建: 不论是定制的模块,还是可视化的表单工具,都需要将启动流程,执行流程的流转等过程集成到表单中,通常是调用流程引擎提供的api来达到启动流程和执行流程的流转。 将创建好的业务模块挂接到业务流程的节点上,就完成了流程和业务模块的关联了。
当集成了工作流系统后,启动业务流程,可以放到一个菜单模块中,例如,在制定采购单,填写完成后,点击提交,就启动了采购流程。 如:一审是采购主任来审核的,那么采购主任的待办任务列表中,就有审核采购员提交来的采购单的任务列表了。采购主任通过办理任务,审核完成后,就提交二审了。
业务过程的监督: 每个运行轨迹上办理的业务,也可以通过业务表和流程的关联展现出来,前面说的业务表中增加轨迹id字段,就是用于将业务表的记录和轨迹更紧密的关联在一起的。
通过上面这些过程,就能将业务系统集成工作流系统了。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2012-07-28
或许可以反过来问,工作流如何集成业务系统
|
|
返回顶楼 | |
发表时间:2012-07-30
kjj 写道 或许可以反过来问,工作流如何集成业务系统
呵呵,其实工作流集成业务系统,可能考虑的方向就不一样。要更多的考虑工作流的扩展性了,如做好一些接口和事件,便于集成业务规则和业务事件。 |
|
返回顶楼 | |
发表时间:2012-08-05
反过来,反过去,应该是两种不同的思路,另一种说法,所谓的推模式和拉模式,业务驱动流程,或者流程驱动业务。
以下是个人理解。 业务驱动流程:用户访问业务逻辑接口(例如:“创建新客户”或者“更新客户资料”等),在业务逻辑处理的过程中,调用流程引擎的接口,推动流程流转。这种模式中,流程引擎更多充当“业务实体状态管理服务” 流程驱动业务:用户访问流程引擎接口(例如:“创建流程”或者“流转”等),流程引擎流转时,通过事件机制或者其他别的方式调用业务逻辑接口,例如osworkflow中的prefunction、postfunction等 |
|
返回顶楼 | |
发表时间:2012-08-24
cucumber 写道 反过来,反过去,应该是两种不同的思路,另一种说法,所谓的推模式和拉模式,业务驱动流程,或者流程驱动业务。
以下是个人理解。 业务驱动流程:用户访问业务逻辑接口(例如:“创建新客户”或者“更新客户资料”等),在业务逻辑处理的过程中,调用流程引擎的接口,推动流程流转。这种模式中,流程引擎更多充当“业务实体状态管理服务” 流程驱动业务:用户访问流程引擎接口(例如:“创建流程”或者“流转”等),流程引擎流转时,通过事件机制或者其他别的方式调用业务逻辑接口,例如osworkflow中的prefunction、postfunction等 赞同,呵呵,主要是看以那个方向为主的问题,以业务为主,集成工作流的话,流程更多的是默默的运行,在业务过程中调用流程的api, 以流程来驱动业务,则主要是走流程流转,在流程的节点上或节点前后调用业务模块。 |
|
返回顶楼 | |
发表时间:2013-04-26
我有一点关于 在工作流平台集成规则引擎的想法,呵呵,大家一起讨论讨论
基于web应用来说,通常分为三部分:界面层、业务逻辑层和持久层。在制作开发平台是,我们都是在这三方面做工作。由于这三层的特点有些不同,因此我们会采用不同的实现方式来实现。 界面层,强调的是操作界面,因此我们注重采用所见即所得的方式来调整界面布局以及界面样式。更多的我们可以会做一个表单设计器。 业务逻辑层,我们强调逻辑调整的便利性,我们会采用动态语言或者规则引擎来实现逻辑的配置。 在持久层,我们会采用领域模型,根据定义MetaData来定义结构,从而实现和持久层的访问。当然持久层不全代表是数据库。 所有的开发平台都是在这三方面做工作,本文主要研究业务逻辑层的实现,我们在国内出现的开发平台中,看到基本都是用代码来实现业务逻辑层的。不过是动态语言还是连接外部程序。比如工作流中一些前续事件和后续事件等。很少看到采用规则引擎来实现业务逻辑的配置。 究其原因就是基于推理方式的规则引擎并不适合普通业务逻辑的编写。 因此我们需要制作一个不采用推理方式的规则引擎,而采用我们传统的编码逻辑方式的规则引擎。我们可以称之为简单规则引擎。 没有了冲突推理后的规则系统,将更加简单的来实现业务逻辑。因此其不用再考虑规则优先级,冲突、关联之类的事情,无需再担心某处的一个简单的改变带来了大量无发确定的后果。实现了易用以及灵活性的完美结合。 由于目前并没有成熟的开源项目来满足这类需求,因此我们需要自己来实现这类引擎。 如何来实现呢,我们可以从当前已经实现的基于语言的配置入手。 当前我们已经实现编写脚本来实现业务逻辑。我们现在要做的就是规则的配置界面,可以自动生成这类脚本。 因此,第一步,我们需要建立一个业务语言和脚本语言的映射,如果我们是基于java的项目,就可以直接采用java语言作为脚本语言,然后利用java的动态加载机制,实现规则实时应用。 第一个java中的对象和业务语言的对应,这在目前各类商业的规则引擎已经做的很好,可以参考。实现BOM和XOM的对应关系。 然后我们只要做一个配置界面,可以来定义调用这些java的对象,由于已经建立了java对象和业务语言的对应关系。因此配置后的逻辑界面其描述就是以业务语言来描述。 最后,我们就是将配置的逻辑,存储到我们的业务系统中,供工作流的某个节点调用。工作流的节点中只要指定了规则名称以及需要传递的对象,就可以将数据传递到规则中进行处理。 如果能够将当前工作流的脚本编辑界面直接替换成规则的开发界面,当然更加好一些。 |
|
返回顶楼 | |
发表时间:2013-05-10
业务通过数据来驱动流程的流转,流程的流转又反过来影响业务数据的产生和定义。。这个设计比较有趣。。。。。把这个设计做好了,一个流程系统才具备真正的业务处理能力,想请教楼主一下,eworklfow在这方面是怎么设计的呢?
|
|
返回顶楼 | |
发表时间:2013-05-11
eworklfow是不是收费的?
|
|
返回顶楼 | |
浏览 4249 次