当前位置:文档之家› 工作流Activit介绍与应用

工作流Activit介绍与应用

工作流Activit介绍与应用
工作流Activit介绍与应用

工作流Activiti介绍与应用

工作流(workflow)就是工作流程的计算模型,即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模型进行表示并对其实施计算。我的理解就是:将部分或者全部的工作流程、逻辑让计算机帮你来处理,实现自动化。

1Activiti简介

Activiti是由Alfresco软件在2010年5月17日发布的业务流程管理(BPM)框架,它是覆盖了业务流程管理,工作流,服务协作等领域的一个开源,灵活的,易扩展的可执行流程语言框架。它实现了BPMN 2.0规范,可以发布设计好的流程定义,并通过api进行流程调度。

1.1A ctiviti基础编程框架

Activiti的基础编程框架如下:

Activiti基于Spring,ibatis等开源中间件作为软件平台,在此之上构建了非常清晰的开发框架。上图列出了Activiti的核心组件。

1.ProcessEngine:流程引擎的抽象,对于开发者来说,它是我们使用Activiti的外观(fa?ade),通过它可以获得我们需要的一切服务。

2.XXService(TaskService,RuntimeService,RepositoryService...):Activiti按照流程的生命周期(定义,部署,运行)把不同阶段的服务封装在不同的Service中,用户可以非常清晰地使用特定阶段的接口。通过ProcessEngine能够获得这些Service 实例。

1.2A ctiviti重要服务类

ProcessEngine:流程引擎的抽象,通过它我们可以获得我们需要的一切服务。RepositoryService: Activiti中每一个不同版本的业务流程的定义都需要使用一些定义文件,部署文件和支持数据(例如BPMN2.0 XML文件,表单定义文件,流程定义图像文件等),这些文件都存储在Activiti内建的Repository中。RepositoryService提供了对repository 的存取服务。

TaskService:在Activiti业务流程定义中每一个执行节点都被称作一个Task,流程运行过程中,与每个任务节点相关的接口,比如complete, delete,delegate等等都是TaskService提供的。

IdentityService: Activiti中内置了用户以及组管理的功能,必须使用这些用户和组的信息才能获取到相应的Task。IdentityService提供了对Activiti 系统中的用户和组的管理功能。FormService:Activiti中的流程和Task状态均可关联业务相关的数据。通过FormService可以存取启动和完成任务所需要的表单数据。RuntimeService:在Activiti中,每当一个流程定义被启动一次之后,都会生成一个相应的流程对象实例。RuntimeService提供了启动流程、查询流程实例、设置获取流程实例变量等功能。此外它还提供了对流程部署,流程定义和流程实例的存取服务。. ManagementService: ManagementService提供了对Activiti流程引擎的管理和维护功能,这些功能不在工作流驱动的应用程序中使用,主要用于Activiti系统的日常维护。HistoryService: HistoryService用于获取正在运行或已经完成的流程实例的信息,与RuntimeService中获取的流程信息不同,历史信息包含已经持久化存储的永久信息,并已经被针对查询优化。

关于ProcessEngine和XXService的关系,可以看下面这张图:

2Activiti深入

2.1A ctiviti配置类分析

ProcessEngineConfiguration类的结构图如下图:

正如上图所示,ProcessEngineConfiguration是全部配置类的父类,有一个ProcessEngineConfigurationImpl子类,ProcessEngineConfigurationImpl下面有三个直接的子类,其中ProcessEngineConfiguration和ProcessEngineConfigurationImpl都是抽象类。这个类是我们编程时第一个使用的类,有了这个类的层级结构,我们就比较容易理解通过该类获取各种具体实现的ProcessEngineConfiguration类的实例了。

ProcessEngineConfiguration.createProcessEngineConfigurationFromResourceDefa ult();

ProcessEngineConfiguration.createProcessEngineConfigurationFromResource("acti viti.cfg.xml");

ProcessEngineConfiguration.createStandaloneProcessEngineConfiguration();

通过上面的方法,可以获取流程引擎的配置类的实例,这些实例有的是通过配置文件进行配置的,有的则是通过程序的方法进行指定,比如:

ProcessEngineConfiguration.createStandaloneProcessEngineConfiguration();

生成这样的配置实例后,需要对该实例进行数据库连接相关的配置等等。

2.2Activiti命令执行器分析

ACTIVITI 所有执行过程都是采用命令模式,使用命令执行器进行执行,这个可是从RuntimeServiceImpl启动流程的代码可以看出来:

public ProcessInstance startProcessInstanceByKey(String processDefinitionKey, String businessKey) {

return commandExecutor.execute(new

StartProcessInstanceCmd(processDefinitionKey, null, businessKey, null));

}

为了了解命令执行commandExecutor,特分如下几节来说明它的构造,传递,以及命令执行执行的过车过你。

2.2.1命令执行器的构造

命令执行器是一个采用拦截器链式的结构,这个可以从如下的分析得出:commandExecutor对象是首先在ProcessEngineConfigurationImpl的初始化方法中产生:

protected void initCommandExecutor() {

if (commandExecutor==null) {

CommandInterceptor first = initInterceptorChain(commandInterceptors);

commandExecutor = new CommandExecutorImpl(getDefaultCommandConfig(), first);

}

}

而这个命令执行器commandExecutor的构造过程中跟commandInterceptors中的第一个命令

拦截器有关,而commandInterceptors是命令拦截器的列表。

protected void initCommandInterceptors() {

if (commandInterceptors==null) {

commandInterceptors = new ArrayList();

if (customPreCommandInterceptors!=null) {

commandInterceptors.addAll(customPreCommandInterceptors);

}

commandInterceptors.addAll(getDefaultCommandInterceptors());

if (customPostCommandInterceptors!=null) {

commandInterceptors.addAll(customPostCommandInterceptors);

}

commandInterceptors.add(commandInvoker);

}

}

protected Collection< ? extends CommandInterceptor> getDefaultCommandInterceptors() { List interceptors = new ArrayList();

interceptors.add(new LogInterceptor());

CommandInterceptor transactionInterceptor = createTransactionInterceptor();

if (transactionInterceptor != null) {

interceptors.add(transactionInterceptor);

}

interceptors.add(new CommandContextInterceptor(commandContextFactory, this));

return interceptors;

}

同时每个拦截器又是通过next域的方式将不同的拦截器进行链接形成一个链接结构,这个可以从initInterceptorChain方法可以看出来:

protected CommandInterceptor initInterceptorChain(List chain) { if (chain==null || chain.isEmpty()) {

throw new ActivitiException("invalid command interceptor chain configuration: "+chain);

}

for (int i = 0; i < chain.size()-1; i++) {

chain.get(i).setNext( chain.get(i+1) );

}

return chain.get(0);

}

2.2.2命令执行器的传递

命令执行器commandExecutor对象在ProcessEngineConfigurationImpl的初始化方法中生成,那么为什么它会在RuntimeService等service对象中获取呢?

依然回到ProcessEngineConfigurationImpl初始化过程,初始化过程会调用initServices方法,将runtimeService等Service实例与该命令执行体commandExecutor进行绑定。

protected void initServices() {

initService(repositoryService);

initService(runtimeService);

initService(historyService);

initService(identityService);

initService(taskService);

initService(formService);

initService(managementService);

initService(dynamicBpmnService);

}

protected void initService(Object service) {

if (service instanceof ServiceImpl) {

((ServiceImpl)service).setCommandExecutor(commandExecutor);

}

} protected void initService(Object service) {

if (service instanceof ServiceImpl) {

((ServiceImpl)service).setCommandExecutor(commandExecutor);

}

}

2.2.3命令执行器执行命令过程

这个可以从CommandExecutor的具体实现类CommandExecutorImpl的execute方法进行分析:

public T execute(Command command) {

return execute(defaultConfig, command);

}

public T execute(CommandConfig config, Command command) {

return first.execute(config, command);

}

从中可以看出其实是将命令的处理交给命令拦截器first去处理

其中这个first就是LogInterceptor对象的引用,它执行的逻辑如下:

public T execute(CommandConfig config, Command command) {

if (!log.isDebugEnabled()) {

// do nothing here if we cannot log

return next.execute(config, command);

}

log.debug("\n");

log.debug("--- starting {}

--------------------------------------------------------",

command.getClass().getSimpleName());

try {

return next.execute(config, command);

} finally {

log.debug("--- {} finished

--------------------------------------------------------",

command.getClass().getSimpleName());

log.debug("\n");

}

}

CommandContextInterceptor顾名思义,它是一个拦截器,拦截所有命令,在命令执行前后执行一些公共性操作。比如CommandContextInterceptor的核心方法:

LogInterceptor对象主要是打印一下日志,最后执行next.execute(config, command); 将命令交给下一个拦截器处理,依次类推。这种将命令依次交给一条链表中的不同节点的执行体

执行的设计模式就是责任链模式。最后一个拦截器CommandInvoker的处理逻辑如下:

public T execute(CommandConfig config, Command command) {

return command.execute(Context.getCommandContext());

}

上面Service中定义的各个方法都对应相应的命令对象(xxCmd), Service把各种请求委托给xxCmd,xxCmd来决定命令的接收者,接收者执行后返回结果。

比如processEngineConfiguration.buildProcessEngine()操作

=命令:SchemaOperationsProcessEngineBuild。

runtimeService.startProcessInstanceByKey()启动流程操作

=命令:StartProcessInstanceCmd

2.3Activiti重要表结构描述

2.3.1逻辑结构设计

Activiti的后台是有数据库的支持,所有的表都以ACT_开头。第二部分是表示表的用途的两个字母标识。用途也和服务的API对应。

1)ACT_RE_*: 'RE'表示repository。这个前缀的表包含了流程定义和流程静态资源(图片,规则,等等)。

2)ACT_RU_*: 'RU'表示runtime。这些运行时的表,包含流程实例,任务,变量,异步任务等运行中的数据。Activiti只在流程实例执行过程中保存这些数据,在流程结束时就会删除这些记录。

3)ACT_ID_*: 'ID'表示identity。这些表包含身份信息,比如用户,组等等。ACT_HI_*: 'HI'表示history。这些表包含历史数据,比如历史流程实例,变量,任务等等。

4) ACT_HI_*: 'HI'表示history。这些表包含历史数据,比如历史流程实例,变量,任务等等。

5)ACT_GE_*: 通用数据,用于不同场景下,如存放资源文件

2.3.2资源库流程规则表

2.3.2.1部署信息表( act_re_deployment)

2.3.2.2流程设计模型部署表( act_re_mod el )

1)简要描述

流程设计器设计流程后,保存数据到该表

2.3.2.3流程定义数据表( act_re_procdef )

1)简要描述

业务流程定义数据表。此表和ACT_RE_DEPLOYMENT是多对一的关系,即,一个部署的bar包里可能包含多个流程定义文件,每个流程定义文件都会有一条记录在ACT_REPROCDEF表内,每个流程定义的数据,都会对于ACT_GE_BYTEARRAY表内的

2.3.3运行时数据库表

2.3.3.1运行时流程执行实例表( act_ru_execution )

2.3.3.2运行时流程人员表( act_ru_identitylink )

2.3.3.3运行时任务节点表( act_ru_task )

2.3.3.4运行时流程变量数据表( act_ru_variable )

2.3.3.5运行时定时任务数据表(act_ru_job )

2.3.4历史数据库表

2.3.4.1历史节点表(act_hi_actinst)

2.3.4.2历史任务实例表( act_hi_taskinst )

2.3.4.3历史变量表( act_hi_varinst )

2.3.5通用数据表

2.3.5.1二进制数据表(act_ge_bytearray)1)简要描述

保存流程定义图片和bpmn文件,即保存所有二进制数据。

3开发前准备

3.1下载Activiti

下载的官方网站的地址:https://www.doczj.com/doc/5d9179687.html,/download.html。下载后解压(我所使用的是activiti-5.21.0版本的),看到如下目录:

1) database:里面存放的是Activiti使用到的数据库信息的sql文件,它支持主流的数据库类型,使用时只需执行你自己的数据库类型的文件即可。如:你的数据库是MySQL,那么就执行activiti.mysql.create.*.sql即可。

2) docs:毫无疑问,api文档是也。

3) libs:使用Activiti所需要的所有的jar包和源文件。

4) wars:官方给我们提供的示例Demo,通过使用Demo可以更加快速的了解Activiti。

3.2下载安装流程设计器(eclipse插件)

下载activiti-designer-5.18.0.zip工作流设计插件,在eclipse安装该插件,安装后,我们可以在eclipse里面很方便的设计出流程图。

安装完成后在菜单选项中会出现activiti的目录选项

工作流系统功能列表

工作流系统功能列表 流程运转功能 1. 串行路由(Sequence Routing) 这个一般都比较容易理解,就是按照顺序的任务执行 2. 并行路由(Parallel Routing) 企业内部有许多作业必需平行处理以提高效率,举例来说:有5 位部门经理需要提出年 度预算报告,每一部门之报告为独立提出,故可将五位经理定义在同一步骤内,各自处理后再统一送到下一步骤。 3. 聚合路由(Merge Routing) 多个分支需要聚合成一个完整的流程 工作流系统功能列表系列 4. 条件路由(Conditional Routing) 在企业处理日常工作时,有许多步骤只有在特定条件成立时才会执行。工作流程自动化 软件因此必需提供此功能。 5. 条件跳跃(Conditional Jumps) 条件式跳跃指满足某些特定条件时,必须自动跳过中间数个步骤至指定人员处理。这也 是企业工作程序里屡见不鲜的状况。 6. 条件终止(Conditional Aborts) 在企业内常发生当遇到某些状况时,则整个流程实例便取消而不再流转。工作流程自动 化软件也必需相对提供这项功能。 7. 回退(Process Returns) 这项业务因为各种原因(文档不全、发送错误等等),当然处理人要求上一处理人重新 办理,或重新发送 8. 取回(Process Rollback) 业务人员依照客户要求填写订单后,订单送出往下继续传递,隔了一天后,客户临时决 定要更改订货的内容,您可以在不删除订单流程的情况下,使用反向回传的功能,可从有问题的步骤(订单输入)直接「取回」已流到后面数个步骤的该张订单,修改完毕后再送至下一步骤. 一般这种情况,实际系统实现中,会强制在后续处理人未处理的情况下可做出[取回]动作,否则不能取回。 9. 自循环(Self-Cycle) 在电子政务办公系统中,经常出现的“多处长联合审批”过程。多个处长(个人)属于 同一个处长角色(角色单元)。针对同一个审批过程,采用自循环(审批这个过程重复执行)就可以基本解决问题。 10. 发散路由(Emanative Routing) 一个任务拆分成多个任务,其分支状态基本相等,同时流程也因为发散操作而分为多个 分支流程 11. 抄送路由(Copy Routing) 比如一个发文,在交司局会签的时候,可能会抄送一份给另外的司局备案,这个过程就 或额外的激活一个不影响主会签流程的“抄送任务” 流程运转扩展功能 12. 关系路由(Relationship Based Routings) 大部分企业流程是构建在从属关系上的:申请差旅费需由部门经理核准、员工绩效由上

Workflow Design 工作流设计

Toward Workflow Block Activity Patterns for Reuse in Workflow Design Lucinéia Heloisa Thom and Cirano Iochpe Federal University of Rio Grande do Sul, Brazil; Vinícius Amaral and Daniel Viero, iProcess, Brazil 1.I NTRODUCTION Research on both business process modeling and implementation issues re-lated to workflow technology have quickly increased over the last years. The most significant initiatives are in the field of standardization [1], [2], [4], specification [5] and workflow definition languages [6], [7], [3]. However, since it is a relatively new and still evolving technology, workflow design pre-sents some challenges, especially with respect to techniques that can en-force correctness as well as efficiency during both the requirements analysis and the modeling phase of the workflow project. Within this context, research on workflow patterns has attracted increasing attention mainly because of the advantages of reusing patterns [8], [9]. The most extensively studied are in the field of control/data flow patterns [10], [11] as well as resource and application–oriented patterns (12). Such pat-terns are being used not only in business/workflow process modeling but also in critical evaluations of workflow languages and workflow tools (13). However, a lot less research can be found relating workflow design to a set of recurrent business process “pieces” or “parts” that must be atomically exe-cuted by the workflow process (e.g., an activity request execution and a noti-fication activity). Although one can precisely characterize the semantics of such business process “pieces” [14], [15], [16] and they have to be recur-rently re-designed in practically every workflow modeling process, there is no known research relating these business process structures to workflow pat-terns. 1.1 Approach Our approach applies the concept of block activity to well-known business processes. An activity set is a self-contained set of activities and transitions [7]. Transitions in the set should refer only to activities in the same set and there should be no transitions into or out of the set. Activity sets can be modeled as block activities. The block execution starts at the first activity in the set and executes the next activities by following the partial order im-posed upon them by the transitions until an exit activity is reached. Work-flow execution then returns to the next activity following the block. In this paper, we apply the block activity concept in order to represent a set of business (sub-)process types (e.g., logistic, financial, information and de-cision) that we call “workflow block activity patterns”. These patterns are re-lated to a set of specific atomic structures that are frequently found in busi-ness processes and have already been identified in the literature [14], [15],

慧正工作流系统使用入门简明教程

慧正工作流系统 设计器使用简明教程 目录 1.模块定制 (2) 1) 打开设计器 (2) 2) 新建模块 (2) 3) 创建数据表 (3) 4) 创建表单 (5) 5) 创建视图 (8) 6) 创建模块内部导航菜单 (13) 7) 添加应用菜单 (15) 8) 测试模块的增、删、改、查功能 (16) 9) 导出定制模块 (17) 10) 删除定制模块 (18) 11) 导入定制模块 (19) 2.定制工作流 (20) 1) 创建流程表单 (20) 2) 新建流程 (20) 3) 填写流程属性 (21) 4) 表单设置 (21) 5) 绘制流程图 (23) 6) 测试流程 (23) 7) 待办处理 (24) 8) 流程导出 (25) 9) 流程删除 (26) 10) 流程导入 (26)

1.模块定制 1)打开设计器 (登录时选择“设计端”,或登录后点击页面右上角的“设计”,均可进入设计器页面) 点击“应用设计” 2)新建模块 1.在这里点击鼠标“右键” 2.在弹出菜单点击 “新建模块”

在弹出的模块属性窗口进行如下操作: 3)创建数据表 1.模块名称录入“模块定制练习” 2. 模块分类录入“练习” 3.点击保存(弹出提示框选择OK) 4.关闭 1.点击“新建”

在弹出的“库表属性”页面,执行如下操作: 在“字段属性”页面执行如下操作:3.点击“字段属性”标签2.填写中文名称“练习表” 1.填写表名“tz_mytest” 1.点击“新增” 2.字段名录入“MYTXT” 3.数据类型选择“大文本” 4.中文名称录入“内容” 5.录入类型选择“大文本” 6.点击“确认” 7.点击“创建表”(弹出 提示框选择“是”) 8.点击“关闭”

工作流程的定义及工作流系统如何开发(精)

工作流程的定义及工作流系统如何开发 时间:2004-10-10 工作流就是: 在一个工作群组中,为了达成某一个共同目的而需要多人协力以循序或 平行工作的形式来共同完成的任务” 关于工作流的几个名词解释: 工作的流动性是一个人接着一个人执行,或同时由多人分开执行,或是上 述两类工作合并之后的混合性工作 泛指各种事务上所 必需执行的流程性 工作 循序或平行工作 若是单人就可以完 任务 多人

成的工作,则不能

归类为流程工作。 凡是一件工作必须 经由两个或更多人 来协力完成的工作 才能称为流程工作 多人参的流程性工 作,必须是以完成 共同目的为前提。 如果一群人是分别 共同目的 针对不同的专案来 执行各别的工作, 并不算构成一个工 作流程 工作流程的应用范围 在一般的组织活动中,有相当多数量的事务性工作可以被归类到流程性工作的范围里面,举例如下: 工作报表呈报流程

采购单 流程贷款审核流程 员工绩效考核 流程

各类报 表会签 流程 如何架构一个工作流程 首先要定义出在一个群组工作的环境下,所需要执行或控管的事务性工作性质 及其内容 根据所定义的工作内容,再将它分成许多子工作,或称为步骤。每个步骤都都 包含了在这个阶段所需要完成的项目清单,而且这些步骤内的项目应当是在逻 辑上适合在同一步骤内完成的。任何一件流程工作都会有许多不同的方法来分 解成许多子工作,而如何切割一个流程工作,则要根据实际的情况来做判断;决定各个步骤需要那些专业背景的人员来执行; 决定各个步骤在流程执行时的顺序; 在执行的过程中,有些步骤的执行会因为某些条件不同而产生不同的结果,进而影响到下一个步骤的执行。所以我们必须要找出这些特定的步骤,并且将相关的执行状态条件定义清楚; 将工作流程中的所有执行步骤及每个步骤之间的关系图画出来,并且根据这份关系图来验证流程的可行性。 根据各个步骤的不同需求,分别建立各阶段所需要的表单,工作指令,文件……等项目。 工作流系统开发一般的工作流管理系统由三个部分组成:工作流引擎、流程管理工

工作流引擎技术白皮书

工作流引擎产品功能介绍

目录

1.1工作流引擎简介 1.1.1产生背景 随着我国信息化建设的不断深入,越来越多的政府部门和企事业单位都清醒地认识到信息化对于自身的生存与发展的重要性,以IT 系统建设为基础提高工作效率,增强竞争能力,已经成为共识。 在过去的若干年中,许多企业以当时的IT 发展水平为基础,针对不同的业务需求搭建了种类繁多的应用系统。回顾这一阶段,我们可以发现长期以来IT 系统的建设一直跟随着技术的革新和业务需求的增长而被动地发展着。不论技术手段如何变化,企业仍旧习惯于沿着功能分析的思路为特定的需求开发专有应用。随着时间的推移,企业内部逐渐积累了许多相互孤立的筒仓式应用系统。不可否认,正是这些应用系统共同构成了当今企业的主要IT 运行环境并有效地支撑了企业早期的业务发展,但是我们也必须清醒地认识到,在这些缺乏前期规划、互连性极差的应用系统之间信息不能被有效地共享且难于保持一致,业务过程也无法顺畅地流转,它们是造成“信息孤岛”现象的根源。一些企业也曾经尝试采用整理、合并各种需求、统一数据接口、规范业务过程等方式来降低集成的复杂度,但是在经过一番实践后,人们又发现仅仅依靠规范静态信息的交换格式,集合局部的需求等方法并不足以支持更大范围内的应用整合。因此当前的企业迫切需要一个能够支持在不同的应用系统之间完成协作任务的具有前瞻性的应用集成框架。 当前,企业面对的是一个多变且难以预测的市场,要在这样的环境中生存和

发展,就必需具备对外部变化做出迅速响应的能力。同样,政府部门也面临着转变工作职能,适应市场经济发展要求的压力,需要不断地为大众提供各种高效的公共服务。各项独立调查表明: 对业务系统和IT 基础设施进行快速调整和扩展一直是政府部门和企事业单位应对外部环境变化的重要手段。然而在早期的IT 系统设计过程中,人们往往更加关注于系统的稳定性而不是迅速应对变化的能力,原先那种僵硬的基于硬编码实现的系统功能扩展和集成方式已远远不能满足要求。“采用什么样的技术来搭建能够实现跨部门、跨企业、跨地理范围的支持流程协作和流程自动化的IT 基础设施”,“如何能够从被动地应对变化到预见变化进而实现前瞻性地主动变化”…这些都是当前每一个政府部门和企事业单位必须面对的挑战。 通过工作流系统把各业务部门的孤立应用系统整合起来是IT技术发展的必然趋势,而我国从上实际八十年代大量建设基础信息系统至今,工作流技术的发展可以分成以下几个阶段。 1.1.2发展阶段 1.1. 2.1EDF(电子数据流)阶段 此阶段的工作流在信息技术中的应用,仅着眼于利用信息技术减轻人们在流程中的计算强度最主要的特点是仅对企业单项业务进行处理,基本不涉及管理的内容。国内最早成功的产品是财务管理产品,为了配合产生正确的数据,可能要设计一个流程用来协调多个会计统计帐目。 此阶段仅仅停留在诸如文档处理、公文流转以及信息发布等这些简单的业务

工作流配置

1. a. b. c. 2. 1. 1. 工作流配置 工作流范例 工作流快速配置 更多工作流程配置 工作流功能列表 触发条件 (并行审批) 用户在待审批人字段 中 只有当前用户在 ‘待审批人’ 字段中,才会显示当前工作流动作按钮。 '待审批人字段' 在 下面处理结果中三个并行审批设置中的任一个设置中指定: 章节(并行审批) 批准 (并行审批) 拒绝 (并行审批) 反馈 (并行审批)隐藏工作流动作 用于对所有用户隐藏当前工作流动作按钮。一般用于系统自动执行。例如:当所有审批人都审批完成后,工作流动作自动执行 '完成' 的动作。 校验条件 (并行审批)备注必填 用于检查用户是否填写了备注。备注可以被复制到 ‘审批意见’ 字段,以便于集中展示所有审批人的审批意见。 处理结果 (并行审批) 批准 执行并行审批的 批准 动作。 执行这个工作流动作后,都会把当前用户从 ‘待审批人’ 字段移动到 ‘已审批人' 字段,当 待审批人 字段 为空时(即所有人都审批完成),自动执行 ‘审批完成’ 的工作流动作。 如果用户填写了审批意见,那么在JIRA 问题查看页面,就会标注审批意见类型为 目录工作流范例工作流功能列表 触发条件 校验条件处理结果

2. 3. 4. 同意 (并行审批) 拒绝 执行并行审批的 拒绝 动作 如果用户填写了审批意见,那么在JIRA 问题查看页面,就会标注审批意见类型为 拒绝 (并行审批) 反馈 仅用于只添加反馈意见的多人并行流程。 执行这个工作流动作后,都会把当前用户从 ‘待审批人’ 字段移动到 ‘已审批人' 字段,当 待审批人 字段 为空时(即所有人都审批完成),自动执行 ‘审批完成’ 的工作流动作。 如果用户填写了审批意见,那么在JIRA 问题查看页面,就会标注审批意见类型为 反馈 (并行审批) 复制项目角色成员到自定义字段 如果每次申请的审批人都相同,不希望用户每次都手动选择审批人,就可以使用这个功能。通过用户角色维护审批人,然后插件会将项目角色成员复制到审批人字段,。 将指定项目角色中用户复制到指定多用户类型自定义字段 这个设置与 ‘(并行审批)批准’ 的区别在于,填写的 ‘审批意见’ 的类型不同。

原型设计及工作流实现总结

关于双鸭山市煤炭局信息化子系统原型设计及工作流实现总结 在近一个月的工作时间里,主要针对双鸭山市煤炭局信息化子系统进行了基本模块的概要需求分析,其中针对建设项目管理和生产技术管理模块进行了具体的需求分析并实现了此两个模块的原型。对详细需求分析的过程了解到实现建设项目及其它各种审批使用工作流实现较符合。对于工作流的使用进行了两方面的接触,一方面是使用.NET中的Workflow Foundation(简称WF)进行自行开发,另一方面是使用现在市场上已经成行的工作流配置产品。 使用WF实现工作流主要用到了三个类库System.Workflow.Runtime; System.Workflow.Activities; System.Workflow.Activities.Rules。其中System.Workflow.Runtime包含的类和接口用于控制工作流运行时引擎和工作流实例的执行。System.Workflow.Activities定义一些活动,可将这些活动添加到工作流,以便创建并运行工作过程的可执行表示形式。程序员也可以实现自定义的活动。System.Workflow.Activities.Rules中的类定义了组成规则的条件和操作。.Net FrameWork提供工作流持久化服务,对SQL数据库的持久化提供了完全的支持与实现,对于其它类型的数据库在完成持久化服务的时候要由程序员编程继承WorkflowPersistenceService 类来实现。 在使用WF进行编程时可分为业务逻辑实现、具体数据库访问、自定义活动三个部分,程序员在进行实现时无须对三个部分全部熟悉,只要针对具体的部分熟悉其它部分了解即可。比如对工作流的流程熟悉的程序员可以实现业务逻辑部分,这部分主要是根据用户的业务流进行绘制工作流,对工作流各活动进行配置相应的参数的关联即可。目前对于在VS开发过程中如何配置工作流的操作基本可以完成,但如何把VS中工作流制作模块移植到B/S页面中还未操作过。

web应用框架-活字格工作流功能详解(下)

概述 本章节讲述了实际应用场景下如何灵活使用活字格工作流,包括工作流流程条的使用,以及工作流命令与批量工作流命令的设置。 业务场景描述 为了让大家能够在实际应用场景中理解工作流中的状态,普通流程,审批流程,以请休假管理模块为例,企业员工在提交请假申请单时,根据部门的不同判断是否需要经过人力资源部核准剩余年假,然后根据请假天数提交部门领导审批,部门领导审批状态为审批流程:小于3天,提交到部门副经理,小于5天,提交到部门经理,小于7天,公司副经理,小于10天,公司经理,大于等于10天,集团董事长,部门领导审批结束后提交人力资源部扣除年假流程结束。在流程流转到人资部结算时,设置提醒,要求提交给人资部结算1个小时以内每20分钟提醒一次,直到人资部结算提交流程。管理员可以随意将流程撤转到对应的环节上。 流程图如下: 请休假申请流程(包含普通流程+部门领导审批流程)

部门领导审批流程

工作流设置

通过上一章节流程功能点的讲解,配合流程图,我们可以将请休假流程在活字格中得以体现。在学习应用场景时,建议大家先学习了解下工作流中所有的功能,那样更方便大家针对特定流程去设计。 表和页面的创建在这里我就不为大家一一介绍了,直入主题,开启请休假表的工作流。在请休假表开启工作流时,表名后会带一个工作流的小图标。操作步骤如下: 1. 新建状态,整个工作流包含了起草,人资部核准,部门领导审批,人资部结算以及结束5个状态。其中起草,人资部核准,人资部结算,结束均为普通流程,部门领导审批为审批流程。

2. 如流程图所示,起草环节根据创建者的部门区分流转环节,若创建者部门=活字格开发部,提交人资部核准,担当者为人力资源部经理,,若创建者部门=活字格业务部,提交部门领导审批。此时就需要在条件中添加不同的分支。条件中选择创建者的扩展属性部门。 3. 当创建者属于活字格开发部时,提交给人资部核准,人资部正常提交给部门领导审批。普通流程后跟审批流程,不用设置担当者。

工作流数据库设计

工作流设计参考(包括PHP实现) 本文关键词:php工作流,workflow 工作流设计的工作流很少有让人满意的,即便是国内用的比较多的jbpm,用起来也会觉得很便扭。再加上PHP中没有什么好用的工作流,于是干脆自己设计一个,设计的原则如下: 1 根据80/20原则,只使用wfmc模型中最符合自身应用的20%功能 2 充分吸收国内使用jbpm开发BOSS中遇到的问题,工作流引擎只负责参数的收集和流程的流转,具体和业务的控制,交给每个流程定制的控制类去实现。 3 表单采用简单的html+控制标签的方法实现 4 权限和模板引擎,以及其它辅助函数直接使用办公系统自带的框架 5 充分利用PHP语言的特点,流程设计是基于数据库的,程序上使用OO设计,但采用重对象的方法 6 不把可视化设计流程的工作交给最终客户,而且由设计时完成,因此不考虑流程版本更新的问题 一、工作流数据表设计

二、常见流程人工决策 领导传阅 部门领导审批填写表单

结束 放弃 提交 同意 重填(退回) 不同意 完成 外部响应 发送支付信息 接收支付成功响应(外部WS触发该流程) 三、PHP设计 运行的函数由结点在设计时候决定,如果没有设定,就使用默认的函数。利用了PHP语言的以下特性

使用前可以用method_exists来检查。 WorkflowService.php WorkflowService $defination $process $node $thread $input 用户输入的和流程有关的变量 list_defination(){ } init_process(defination_id){ global user; 取得$defination,得到业务的handler,例如WorkflowProposalHandler 建立$process行记录 } start_process(){ 调用WorkflowProposalHandler->start($process)//新建业务对象,并把业务类的参数例如proposal_id放到$process[‘context’]里面 init_thread(1); //默认调用第一个结点 } list_ my_thread (){ global user; } init_thread(node_index){ 取得$node 取得$process 修改$process为运行到当前结点 Switch($node[‘node_type’]) Case 1: 人工决策 建立$thread WorkflowProposalHandler-> init_function ($process,$node,$thread) 发送提醒 Case 2: 自动处理 建立$thread WorkflowProposalHandler-> init_function ($process,$node,$thread) 调用run_thread(thread_id) Case 3: 等待外部响应 建立$thread WorkflowProposalHandler-> init_function ($process,$node,$thread) Case 4: 分支 取得所有分支的子结点

工作流系统功能介绍简化版

工作流系统功能介绍 目录 1概述 (2) 2流程系统设计总图 (4) 3建模工具 (4) 3.1组织机构管理 (5) 3.1.1主界面 (6) 3.1.2岗位管理界面 (7) 3.1.3部门管理界面 (8) 3.1.4员工管理界面 (9) 3.2权限管理 (10) 3.2.1主界面 (11) 3.2.2权限组管理界面 (12) 3.2.3权限设置界面 (14) 3.3流程管理 (14) 3.3.1流程管理主界面 (15) 3.3.2启动节点配置界面 (15) 3.3.3处理者配置界面 (19) 3.3.4流转条件配置界面 (19) 3.3.5控制节点配置界面 (20) 3.3.6子流程节点配置界面 (21) 3.4表单管理 (21) 3.4.1表单管理主界面 (22) 3.4.2选择用户控件界面 (23)

4工作流引擎 (23) 4.1基本功能 (23) 4.2任务节点类型 (25) 4.2.1启动节点 (25) 4.2.2结束节点 (26) 4.2.3交互节点 (26) 4.2.4子流程节点 (26) 4.2.5控制节点 (26) 4.2.6查看节点 (26) 5业务平台 (26) 5.1业务平台主界面 (27) 5.2例子:差旅费报销流程 (27) 5.3未认领任务 (29) 5.4已认领任务 (30) 5.5已完成任务 (30) 5.6查看流程图 (30) 6与门户sps系统的整合 (31) 7流程监控服务系统(即时消息和Email) (32) 1概述 随着计算机软件应用的普及,信息化系统发挥的作用也越来越大,企业信息化建设的不断深入,对系统功能和自动化程度要求越来越高。客户要求系统功能与实际的工作情景紧密结合,对每个业务环节的控制要求越来越精确。如何让我们的信息化系统更加贴近客户需求,满足客户不断变化的业务流程成了我们软件开发商不得不面对的问题。

jira自定义工作流操作手册

jira自定义工作流配置 在介绍jira自定义工作流配置之前先介绍一些概念性的知识: 1.工作流:是一个问题经过进过其生命周期的若干个步骤和阶段的变迁。工作流通常代 表实际的业务处理流程。 一个工作流是由步骤和变迁组成的,一个工作流的步骤标识着一个问题的一个阶段或者叫“状态”,变迁是工作流中两个步骤之间的连接。 2.当定义一个变迁的时候,可以选择性的指定一下选项: Conditions(条件)——用于控制哪些用户能够执行一个变迁。 Validators(校验)——在执行变迁之前,用于检查任何用户的输入是否合法。 Post Functions(后续操作)——在变迁完成之后,用于执行特定的动作,如:将问题分配给特定的用户,发送通知email,更行问题的某个字段。 Screen(显示给用户的界面)——这对于用户输入信息之后才能完成变迁的情况是有用的。 3.在jira中的默认工作流程图中,5个方框表示工作流的步骤/状态(open、in progress、 resolved、reopen、closed),箭头代表变迁(transitions)。这个从网上查一下。 4.在jira中可以用不同的方式来创建一个新的工作流: 页脚内容1

1)通过“Add New Workflow”来创建一个空白的工作流。用这个方法创建的工作流有 一个默认的步骤open,该步骤有一个进入的工作流变迁:“create”。 2)通过点击“copy”链接,拷贝已经存在的工作流(如果您准备新添加的工作流和已 经存在的工作流类似,则可以使用此方法)。用这种方法您的工作流将会包含所拷贝的工作 流的所有步骤和变迁。 1.创建工作流 Jira安装完成以后地址栏中输入:http://10.7.101.25:8080/secure/Dashboard.jspa进行平台配置。 在创建新的工作流时一般先将全部步骤定义好,再创建变迁将步骤连接起来,所以首先要自己定义一个工作流程图。 1.以jira管理员的账户登录系统。 2.在jira的导航菜单上点击“Administration”链接。 3.点击左侧导航菜单中的Global Settings—>Workflows,如下图: 页脚内容2

(工作分析)国内外主流工作流引擎及规则引擎分析

国内外主流工作流引擎及规则引擎分析2013年2月创新研发部

目录 国内外主流工作流引擎及规则引擎分析 (1) 一.背景 (4) 二.原则 (4) 三.工作流功能分析点 (6) 4.1.标准类 (6) 3.1.1BPMN2.0标准支持 (6) 4.2.开发类 (7) 3.1.1业务模型建模工具 (7) 3.1.2工作流建模工具 (7) 3.1.3人工页面生成工具 (8) 3.1.4仿真工具 (9) 4.3.功能类 (9) 4.1.1流程引擎 (9) 4.1.2规则引擎 (10) 4.1.3组织模型与日期 (10) 4.1.4对外API的提供 (11) 4.1.5后端集成/SOA (11) 4.1.6监控功能 (12) 四.中心已有系统工作流功能点分析 (13) 4.1.备付金系统工作流分析 (13) 4.1.1联社备付金调出流程 (13)

4.1.2联社备付金调入流程 (16) 4.1.3资金划入孝感农信通备付金账户业务流程 (18) 4.1.4备付金运用账户开立流程 (20) 4.1.5备付金沉淀资金运用流程 (23) 4.1.6备付金沉淀资金支取流程 (26) 4.2.多介质项目工作流分析 (28) 4.1.1开卡审批流程 (28) 4.3.新一代农信银资金清算系统工作流分析 (29) 4.4.电子商票系统工作流分析 (29) 4.5.OA系统工作流分析 (32) 五.工作流产品分析 (32) 六.分析结论 (44) 4.4.对比 (44) 4.5.建议 (45)

一.背景 目前中心建成的“一大核心系统,七大共享平台”以及OA系统,对工作流应用程度高,但各系统实现工作流程管理没有建立在统一的工作流平台上,导致流程割裂、重复开发、不易于管理等问题。 备付金管控项目涉及多个岗位之间工作的审核步骤,同时还要与多个系统进行交互,因此,为了提高管理效率,降低业务流转时间,同时还要结合农信银中心的总体IT战略规划,备付金管控项目技术组决定选择一款先进的工作流引擎和一款规则引擎,作为备付金管控项目的核心技术架构。 二.原则 备付金管控项目组通过梳理各信息系统流程现状和未来需求,形成农信银中心工作流平台的发展规划,从而更全面的满足农信银各项关键业务、更好的支撑现有和未来的信息系统建设。项目组充分研究国内外领先的工作流产品和案例,同厂商交流。从用户界面生成、流程建模、流程引擎、规则引擎、组织模型、模拟仿真、后端集成/SOA、变更及版本管理、移动设备解决方案、监控分析能力等多方面考察工作流产品,进行工作流产品选型。 目前国内外的工作流引擎层出不穷,行业标准多种多样,通过对比不同工作流公司产品,本次工作流技术选型决定分析商业工作流引擎4款,开源工作流引擎2款。其中国际知名厂商的商业工作流引擎2款,本土厂商的商业工作流引擎2款。由于本次技术选型是以工作流引擎为主,选型工作将不再单独分析规则

泛微工作流程

特殊说明,均属虚构。 本手册以及本手册所提及的任何产品的使用均受适应的最终用户许可协议限制。本手册由上海泛微软件有限公司制作。本手册中提及的所有商标、商标名称、服务标志及徽标均归其各自公司所有。

目录 五、工作流程(e-workflow) 工作流管理是提高组织效率的有效工具。与传统的纸张上的操作相比,在电子化的流程当中,每个请求不会丢失,而且在工作流的每个阶段由谁来负责处理请求也都有了明确的定义。 工作流管理模块同时也提供了可定制的浏览和报告的功能,从这些报告中可以清晰的了解哪些请求是创建最频繁的,哪些人处理的请求最多,以及每一个工作流完成所需要的时间周期。 通过电子化的方式,可以很方便的根据一个工作流相关的政策信息和手续对工作流进行定义,每一个请求的创建和批准都是基于一个规范,这将有助于按照统一、合理、高效的方式处理各种请求。 在系统中通过工作流管理模块可以按照组织的需求设置所需的工作流类型。 工作流管理模块与系统其他模块的链接关系,下图是一个示意图: 由于每一个请求都对应了一个系统定义的工作流,所以所有同类型的请求都将由一种工作流类型的方式来完成。这种类型的所有请求包括了同样的信息类型,同时在请求中明确了每一步由哪些人负责处理这些请求。 定义一个请求类型指创建这种类型的请求时,相应的工作流的表现方式。例如,一个缺席请求应该由该员工的经理和人力资源部门来进行批准。这样当一个员工递交缺席请求时,这个请求将自动流转到该员工经理那里。这些信息需要在定义该请求类型时进行设置。 当建立一个请求类型时,与之相关的选项和必要条件也就相应的确定。因此建议在建立和使用新的请求类型之前,用户需要参考和此请求类型相关的政策和文档。 这样做的原因是,并不是要等到需要递交某个请求时再去对请求类型进行设置,而是通过一个统一的方式,进行集中的定义。 5.1类型设置 工作流类型设置用于将工作流进行分类,如按照流程的使用性质,我们可以将流程分为日常工作、人事管理、费用相关等。 (图5-1-1) 具体操作为: 1)工作流管理员在(图5-1-1)所示页面选择【工作流程】->【类型设置】,进入如(图5-1-2)所示页面,这里显示的是已有的流程分类; 2)在(图5-1-2)所示中右键点击新建按钮后显示如(图5-1-3)所示的页面,在说明栏中输入流程分类名称后点击保存,一个流程分类就设定好了。 (图5-1-2) (图 5-1-3)

PeopleSoft工作流配置

AWE: STEP BY STEP 概述 该文档描述一个简单的AWE配置流程,所有步骤均采用最简单而有代表性的配置。 为了更详细地描述一个AWE例子程序的编写过程,该文档将完成一个简单的费用报告报销需求,具体需求描述如下: 1、提供一个页面供员工输入费用报告明细,包括时间、金额、用途等; 2、提供一个页面供经理审批费用报告,审批是需要显示费用报告明细; 3、根据费用报告中的金额,确定如下审批规则:金额小于500,只需部门经理审批, 金额超过500时,部门经理审批后,还需副总裁审批;所有审批人审批完成后,费用报告的状态变为“已审批”,后续操作省略。 开发说明 该文档技术来源:Approval Workflow Engine (AWE) for HCM 9.0(HCM Shared Components Team)。 该文档技术平台:PT8.50+FSCM9.1+Oracle。如果在HCM环境中开发,如果EOAW_开始的对象不存在,均可找到一个PTAFAW_或者PTAF_开始的相对应的对象代替。 所有PeopleCode和SQL语句均在附录中。 具体步骤 一、创建许可权列表、角色、用户概要 根据需求描述,设置三个许可权列表,分别代表员工、部门经理、副总裁;设置三 个角色,分别包含三个许可权列表;再设置三个测试用户分别代表三种角色,每个 用户概要需要绑定一个员工ID。用户权限设置如下图: 用户概要角色许可权列表 XTEST1 X_1010(Employee) X_1010 XTEST2 X_1020(Department Manager) X_1020 XTEST3 X_1030(Vice President) X_1030 注:为了避免测试过程中出现其他与AWE无关错误,建议以上三个用户概要从VP1 拷贝,再加上相应角色。 二、创建基础Project 1.创建Record 该步骤创建的Record如下:

工作流需求说明书

第 1 页 工作流需求说明书 1 前言 为构架完整EDM 产品,更好满足特定用户需求,需要进行项目管理和工作流管理模块的开发。 此需求计划由公司内部提出,在需求讨论和编写过程中,总结PDM 组在“863”项目中开发工作流原型的经验,吸收部分企业对工作流的需求意见,参照国内外同类产品的现有系统,确定了我公司开发的要求和目标。 此工作流需求说明书作为项目组内部开发指导文件。 1.1 目的 开发项目管理和工作流模块,所有的过程逻辑控制在工作流中实现,并通过项目管理进行任务分发、任务提交、过程跟踪等。工作流系统中的服务模块(如工作流引擎)基于DCOM 实现,作为组件提供给系统使用。 本文档的预期读者为项目组开发人员、质量保证人员、市场销售人员及公司领导层。 1.2 范围 实现的项目管理(ProjectManage )和工作流管理(WorkflowManage )作为CEDM 的两个模块,不单独包装为产品。 工作流管理实现WfMC 定义的基本功能:工作流引擎、图形化定义工具、工作流客户端、工作流管理平台。但实现的功能为WfMC 定义功能的子集,不考虑异构工作流系统间的交互,不考虑数据对象在工作流上的传递,不考虑工作流结点上脚本的实现。 项目管理以工作流管理为核心。项目加载工作流模板后,对任务进行描述,包括设定项目承担人、任务截止日期、任务优先级等,进行工作流的启动、流转、操作。项目管理不包括对设备等其他非人力资源的调度,不负责对项目进度排程的优化和组合。 1.3 定义、缩写词、略语 WfMC(Workflow Management Coalition)工作流管理委员会,有关工作流的国际标准化组织。

金蝶HR自定义工作流设置步骤

自定义工作流设置步骤 本操作步骤以“加班申请表”为例,描述如何定义以及使用自定义工作流: 一、登录HR系统,在系统设置-工作流设置中,自定义加班申请类型的工作流类型 在菜单中可以看到添加工作流类型的按钮如下图: 2、添加自定义流程的时候,业务名称可以自己来定义,比如员工加班申请审批,处理方式可以选择“员工请假业务处理”,表示员工加班申请审批的流程运转方式、流程关键字、流程统计方式等类似请假工作流的处理方式。 另外也可以选择“默认处理方式”,此方式下,工作流的业务数据比较少,只有“职员”一项业务数据,使用起来限制比较少。 3、自定义的工作流类型,在业务流程树中的按钮是绿色的圆圈,如果工作流的流程类别比较多的话,右边的流程类型列表中很有可能会显示在第二页

据名称列表页面,表示在员工加班申请中,能够看到的业务数据 5、选中“员工加班申请审批”的流程类别,点击“导入数据字典”,将员工加班申请审批工作流的流程数据以及数据表、字段都导入数据字典中供管理,这样以后可以出自定义报表等 多项的处理数据的操作。

导入后的提示 6、导入数据字典成功后,在员工加班申请审批的工作流类型下,新建工作流。

下图表示二级的工作流审批,业务类型为员工加班申请审批,拥有者类型为员工,表示在指定谁遵守工作流的时候是指定在某个具体姓名的员工,也可以将拥有者类型定义为职 位、组织单元等。 下图表示工作流的审批关系为发起流程的本人――直接上级

新建成功 辑好的员工加班申请表(注:自定义的表单可通过Frontpage等工具来制作)。

申请人属性定义,表示申请人这个字段的信息可以被二个节点看到,并且申请人的业务数据属性为姓名,在统计工作流数据时,该输入框中的数据就被统计到姓名的字段中。

工作流需求说明书

工作流需求说明书 1 前言 为构架完整EDM产品,更好满足特定用户需求,需要进行项目管理和工作流管理模块的开发。 此需求计划由公司内部提出,在需求讨论和编写过程中,总结PDM组在“863”项目中开发工作流原型的经验,吸收部分企业对工作流的需求意见,参照国内外同类产品的现有系统,确定了我公司开发的要求和目标。 此工作流需求说明书作为项目组内部开发指导文件。 1.1 目的 开发项目管理和工作流模块,所有的过程逻辑控制在工作流中实现,并通过项目管理进行任务分发、任务提交、过程跟踪等。工作流系统中的服务模块(如工作流引擎)基于DCOM实现,作为组件提供给系统使用。 本文档的预期读者为项目组开发人员、质量保证人员、市场销售人员及公司领导层。 1.2 范围 实现的项目管理(ProjectManage)和工作流管理(WorkflowManage)作为CEDM的两个模块,不单独包装为产品。 工作流管理实现WfMC定义的基本功能:工作流引擎、图形化定义工具、工作流客户端、工作流管理平台。但实现的功能为WfMC定义功能的子集,不考虑异构工作流系统间的交互,不考虑数据对象在工作流上的传递,不考虑工作流结点上脚本的实现。 项目管理以工作流管理为核心。项目加载工作流模板后,对任务进行描述,包括设定项目承担人、任务截止日期、任务优先级等,进行工作流的启动、流转、操作。项目管理不包括对设备等其他非人力资源的调度,不负责对项目进度排程的优化和组合。 1.3 定义、缩写词、略语 WfMC(Workflow Management Coalition)工作流管理委员会,有关工作流的国

际标准化组织。 DCOM(Distributed Component Object Model)。微软的分布式计算平台。1.4 参考资料 1.罗海滨.工作流技术综述.软件学报.2000(11),7:899-907 2.范玉顺.基于工作流的CIMS应用集成支持系统研究.计算机工程与应用. 2000,2:9-10 3.范玉顺.工作流管理技术基础.清华大学出版社.2001.4 4.Wil.M.P. Van Der Aalst. Verification of Workflow Task Ttructures: a Petri-net-based approach information systems. Vol.25 No.1 pp.43-69 5.Ellis C.A. Null. G.J..Modeling and Enactment of Workflow System Application and Theory of Petri Net Lecture Notes in Computer Science 691,Berlin Springer-Verlag,1993 1-16 6.卢正鼎.面向并行工程的产品设计过程管理的抽象模型.计算机辅助设计与 图形学学报. 2000,Vol12. No.2:123-124 7.刘铁铭.基于工作流的企业过程建模与仿真. 清华大学学报. 2000 ,Vol.40 No.1:109-110 …… 参考的应用系统 1.SmartTeam4.0 以色列Smart Solution公司 2.开目PDM 武汉开目公司 3.大恒PDM2.0 北京大恒公司 4.LOTUS workflow 美国IBM 5.workflo 上海新视界 2 项目概述 2.1 产品描述 系统要求实现项目管理和工作流管理两部分,重点是工作流管理,项目管理的调度通过调用工作流系统中的方法来实现。

相关主题
文本预览
相关文档 最新文档