普元EOS工作流引擎设计原理
工作流引擎七大原理

工作流引擎七大原理在当今快节奏的商业环境中,高效的工作流程对于企业的成功至关重要。
工作流引擎作为一种自动化流程管理工具,能够有效地提升工作效率和准确性。
要理解工作流引擎的运作原理,我们需要了解其中的七大原理。
一、自动化流程管理工作流引擎的核心原理是自动化流程管理。
它能够将企业的复杂业务流程转化为可管理的步骤和规则,实现自动化的流程执行和监控。
通过预定义的流程模板,工作流引擎可以自动分配任务、通知相关人员、自动触发下一步操作,从而简化流程管理,提高效率。
二、灵活的流程设计工作流引擎具有灵活的流程设计能力。
它可以根据企业的需求和业务逻辑,自定义流程模板,包括任务的分配、执行顺序、执行条件等。
这种灵活性使得工作流引擎能够适应各种不同的流程需求,满足企业的特定要求。
三、实时的流程监控工作流引擎能够实时监控流程的执行情况。
通过集成数据库和报告系统,工作流引擎可以追踪任务的状态、执行时间、执行人员等关键信息,并生成详细的流程报告。
这些实时的监控数据为企业的决策提供了重要的依据,帮助企业管理人员及时了解流程的进展和问题所在。
四、灵活的协作环境工作流引擎提供了灵活的协作环境。
它可以通过电子邮件、即时通讯工具等多种渠道,将任务和相关信息发送给指定人员,并收集他们的反馈。
这种协作环境使得企业内部各个部门之间能够高效地协同工作,提升整体工作效率。
五、可定制的规则引擎工作流引擎通常配备了强大的规则引擎。
规则引擎能够根据预定义的规则和条件,自动判断流程中的分支条件,并触发相应的操作。
这使得工作流引擎能够根据不同情况自动调整流程的走向,提供更加灵活和智能的流程管理。
六、数据集成和交换工作流引擎具有良好的数据集成和交换功能。
它可以与企业现有的ERP系统、CRM系统等进行集成,实现数据的共享和交换。
这种数据集成和交换能力使得工作流引擎能够更好地与企业的核心业务系统进行对接,实现信息的无缝传递和共享。
七、易用性和可扩展性工作流引擎通常具有良好的易用性和可扩展性。
流程引擎的工作原理

流程引擎的工作原理流程引擎是一种用于管理和执行工作流程的软件工具。
它通过定义和控制任务、活动和决策之间的顺序和依赖关系,帮助组织优化业务流程,提高效率和准确性。
下面是流程引擎的工作原理:1. 流程建模:流程引擎首先需要通过建模工具或界面来描述业务流程,包括任务、活动、决策、条件、人员和角色等元素,以及它们之间的顺序和依赖关系。
这些描述形成了一个执行流。
2. 流程执行:流程引擎根据建模所定义的流程规则,按照指定的顺序和条件执行各个任务和活动。
它会自动分配任务给指定的人员或角色,并根据一定的优先级和规则进行调度和执行。
流程引擎还可以处理并发执行的任务,确保它们按照正确的顺序和依赖关系完成。
3. 数据管理:流程引擎通常需要读取和处理相关的数据,以便在流程执行过程中进行决策和判断。
它可以将数据存储在数据库中,并在需要时进行查询、更新和删除操作。
流程引擎还可以与其他系统进行数据交换和集成,以实现数据的共享和协同处理。
4. 事件触发:流程引擎可以根据事先定义的事件来触发和驱动流程的执行。
这些事件可以是外部条件的变化,比如用户提交了一个订单或者支付了一个账单,也可以是内部的通知或提醒。
5. 异常处理:流程引擎还需要处理异常情况,比如任务超时、决策错误或资源不足等。
它可以根据预定义的规则和策略,自动进行异常处理,比如重新分配任务、发送通知或记录日志。
6. 监控和报告:流程引擎可以提供监控和报告功能,用于跟踪和分析流程的执行情况。
它可以实时显示每个任务和活动的状态和进度,以及整个流程的效率和效果。
流程引擎还可以生成各种报告和分析结果,帮助组织做出相应的决策和改进。
综上所述,流程引擎通过建模、执行、数据管理、事件触发、异常处理和监控报告等功能,实现了业务流程的自动化管理和执行。
它可以提高组织的工作效率和准确性,减少人为错误和重复劳动。
《普元EOS开发入门》课件

03
eos智能合约开发
eos智能合约开发
编写智能合约: 根据EOS区块链的规则和要求,编写智 能合约。这可能涉及到编写一些关键的函数,如部署、 交易、投票等。 首先,选择一个安全的合约地址,这个地址应该是经过 充分测试和验证的。
编译和部署智能合约: 使用EOS提供的编译工具将智能 合约编译为可执行代码,然后部署到EOS区块链上。
04 根据架构设计,使用相应的编
程语言和框架进行编码实现。
测试与调试
05 对dapp进行测试和调试,确
保其功能和性能符合要求。
上线部署
06 将dapp部署到eos主网上,供
用户使用。
使用eosjs进行dapp开发
安装eosjs
创建智能合约
部署智能合约
调用智能合约
在开发环境中安装eosjs 库,以便使用其提供的 API进行dapp开发。
eos的核心技术
01
02
03
跨链技术
阐述eos如何通过跨链技 术实现不同区块链之间的 互操作性。
共识算法
介绍eos采用的共识算法 及其特点,如DPoS等。
智能合约
解析eos支持的智能合约 语言和开发工具,以及智 能合约在eos生态中的重 要地位。
eos 用,如去中心化交易、数 字货币等。
使用eosjs提供的API编 写智能合约代码,实现
dapp的功能。
将智能合约部署到eos主 网上,供用户使用。
通过eosjs提供的API调 用已部署的智能合约,
实现dapp的功能。
使用vue.js进行dapp开发
01
02
03
04
安装vue.js
在开发环境中安装vue.js框架 ,以便使用其进行前端开发。
EOS工作流

EOS工作流(Workflow)是与EOS平台无缝集成的业界第一家完全构件化的工作流管理系统(Workflow Management System),能够支撑在大并发用户量、大数据量的企业级应用环境下高效、稳定运行。
EOS工作流符合工作流管理联盟(WfM C)规范,同时,根据中国软件业的具体行情,还整合了国内众多的电信、政府、金融等行业特殊需求在遵循规范的基础之上而进行了扩展。
EOS工作流(Workflow)是具有中国特色的工作流。
它溶入了国内电子政务与电信等行业的特征要求。
在流程定义中支持包括串行,并行、同步、独占式选择、同步归并、子流程嵌套、自由流、活动回退业务补偿等都多种流程模式;对于流程动态调整,又根据具体的行业需求实现了“特事特办型”、“一刀切型”,“分水岭型”等流程调整方式,从而实现灵活的业务调整。
EOS Workflow由工作流开发环境(Workflow IDE)(与Studio集成)、工作流引擎(Workflow Engine)、客户端、监控与管理工具以及工作流构件库(Workflow C omponent Library)五个部分组成。
通过开发环境快速构建业务流程以及业务处理表单;依托引擎实现流程流转;采用基于Web的缺省客户端和管理监控工具完成对流程的调整、监控与审计。
应用丰富的构件库快速定制用户自己的应用,随需应变。
【工作流开发环境(Workflow IDE)】与EOS Studio无缝集成,提供基于流程的应用开发、调试环境;包括可视化的业务流程定义、基于向导和工作流页面控件的可视化表单开发与调试、以及业务流程部署功能。
一个工作流(Workflow)应用的开发过程就是业务流程开发加上基本的EOS应用开发过程,EOS工作流开发环境提供了一体化的工作流应用开发环境,包括业务逻辑、展现逻辑、数据逻辑、页面、业务流程的拖拉式开发与调试。
● 可视化业务流程建模EOS可视化业务流程建模提供基于拖拉式的业务流程定义工具,具有如下特色:·灵活的活动参与者设置支持组织机构、角色、人员、工作组作为参与者支持流程启动者、活动执行者作为参与者支持运行时动态指定参与者·任务分配策略的灵活性按实际参与者或操作员的的个数分配主动领取、派工、代理、流程启动者、某活动的执行者、运行时按规则动态指定·自由流支持支持在整个流程范围内的自由流支持在指定的活动范围内的自由流·多种事件支持支持同步和异步两种方式触发事件流程事件:启动、创建、超时、结束、超时提醒时触发自定义业务逻辑构件活动事件:启动、创建、超时、结束、超时提醒时触发自定义业务逻辑构件·严密的安全机制支持基于组织机构和角色的流程启动权限控制针对工作项的严格权限控制,避免由于应用开发的疏忽造成可以通过输入ID提交别人任务的情况·支持多种活动启动与结束方式支持人工或者按用户自定义规则启动活动支持人工或按指定数量或工作完成的百分比方式结束活动·支持活动回退以及业务补偿支持回退到任意已执行的活动支持多种业务补偿方式:所有活动自动补偿或按指定活动补偿·活动处理时限支持支持直接指定相对时间支持运行时动态指定时限支持超时前以及超时后的邮件自动提醒支持自定义的超时提醒方式·与EOS构件紧密结合可以将EOS业务逻辑构件、JSP页面拖拉至业务流程,分别自动生成自动和人工活动。
工作流引擎的原理

工作流引擎的原理
工作流引擎是一种用于自动化组织、协调和监控业务流程的技术。
其原理基于以下几个关键概念:
1. 流程定义:工作流引擎通过定义工作流程,将业务流程抽象为一系列任务、步骤和决策节点的组合。
流程定义通常使用特定的建模语言(如BPMN)来描述。
2. 执行引擎:工作流引擎包含一个执行引擎,负责执行流程定义中定义的任务、步骤和决策。
执行引擎通常是一个状态机,能够根据当前流程状态和输入条件决定下一步的动作。
3. 任务分配和执行:工作流引擎负责将需要执行的任务分配给相关人员或系统,并跟踪任务的执行过程。
这包括任务的创建、分配、完成和关闭等操作。
4. 事件驱动:工作流引擎通常基于事件触发执行,即通过监听特定事件(如任务完成、超时等)来推动流程的执行。
这样可以实现异步、灵活和自适应的流程控制。
5. 数据持久化:工作流引擎需要将流程定义、任务状态和执行记录等信息进行持久化存储,以便在需要时进行查询和回放。
这可以使用关系型数据库、文件系统或其他持久化技术来实现。
6. 监控和优化:工作流引擎通常提供监控和报告功能,用于实时跟踪工作流程的执行情况,并提供性能指标和分析结果以供优化和改进。
总的来说,工作流引擎通过定义、执行和监控业务流程,实现了业务流程的自动化和可视化管理。
它可以提升业务流程的协同效率、可靠性和可扩展性,同时也提供了监控和优化的能力。
普元EOS工作流引擎设计原理

普元EOS工作流引擎设计原理一、状态机模型的概念状态机模型(State Machine Model)是一种描述系统行为和状态变化的模型。
它由一组状态(State)、一组过渡(Transition)和一组事件(Event)组成。
状态表示系统的工作状态,过渡表示状态之间的变化,事件表示触发状态变化的条件或动作。
在状态机模型中,每个状态都有相应的过渡条件和动作,当触发条件满足时,状态将根据过渡条件进行转移,并执行相应的动作。
状态机模型可以用于描述复杂的系统行为,包括流程控制、状态监测和事件处理等。
二、普元EOS工作流引擎的设计原理1.状态定义在普元EOS工作流引擎中,每个工作流都可以被定义为一个状态图。
状态图由一组状态节点和一组过渡节点组成。
每个状态节点表示一个工作流状态,可以包含一组子状态节点,形成状态层次结构。
状态节点可以包含多个过渡节点,每个过渡节点定义了触发状态转移的条件和动作。
条件可以是一个表达式,用于判断是否满足触发条件。
动作可以是一个函数,用于执行状态转移时的操作。
2.事件触发在普元EOS工作流引擎中,事件用于触发状态转移。
事件可以是外部事件,如用户的操作或系统的消息;也可以是内部事件,如定时器的到期或状态节点的完成等。
当一个事件触发时,工作流引擎将根据当前状态和触发条件判断是否需要执行状态转移。
如果触发条件满足,则执行相应的动作,并将状态转移到新的状态。
3.状态转移在普元EOS工作流引擎中,状态转移是指从一个状态节点转移到另一个状态节点的过程。
状态转移通过触发事件和满足过渡条件来实现。
当一个事件触发时,工作流引擎将根据当前状态和过渡条件进行判断。
如果过渡条件满足,则执行相应的动作,并将状态转移到新的状态。
状态转移可以是顺序转移,即从一个状态直接转移到下一个状态;也可以是条件转移,即根据不同的条件选择不同的下一个状态。
三、普元EOS工作流引擎的特点和应用1.灵活可配置:普元EOS工作流引擎支持状态节点和过渡节点的自定义定义和配置,可以根据实际需求定义不同的状态和转移条件,实现灵活的工作流控制。
EOS6.0讲解

Working目录
working目录是应用真正的加载目录
cache:cache的工作目录 config:配置文件和应用级资源文件目录 lob_temp: CLOB和BLOB字段的临时目录 logs:应用级日志目录 temp:页面流、逻辑流的等临时编译的java
文件目录 upload:上传文件的目录 work:构件包的工作目录
开发技巧一
创建项目:默认添加基础构件库,如需要报表和工作流,需 另外添加。
页面名称:系统自动创建的页面可以重命名,注意选择“更 新引用”;也可以自己创建的jsp页面。
页面标签:直接拖拽;输入“<”显示提示;借助“属性”视 图;标签空白处使用“Alt+/”。
自定义构件库:直接显示SDO对象对应的基础操作,或者是 java对象在JDK1.5中的基本操作。
system:系统构件包目录 user:用户构件包目录
META-INF:构件包配置和资源文件目录
谢谢!
EOS数据处理过程—逻辑流
数据总线(Bizlogic Runtime Context)
MUO上下文数据区:将会话上下文数据区中的部分数据构造成受 控的用户数据对象,当前实例下用m:XPATH_EXPRESSION访问
逻辑流上下文数据区:当前实例下可访问
目录
1 EOS基本概念介绍 2 入门案例示例开发 3 数据流转原理剖析 4 EOS单表多表开发 5 EOS扩展内容介绍
请求上下文
会话上下文
数 据
页面流上受下控用文户对象上下文简称
为MUO(Managed User Object)
上
上下文
下
MUO上下文
文
逻辑流上下文
工作流程引擎

工作流程引擎
工作流程引擎的基本原理是将企业的工作流程抽象成模型,然
后通过软件工具来执行和管理这些模型。
工作流程引擎通常包括以
下几个核心组件,流程建模工具、执行引擎、监控和报告工具。
通
过这些组件的配合,工作流程引擎可以实现工作流程的设计、执行、监控和优化。
首先,流程建模工具是工作流程引擎的核心组件之一。
它允许
企业用户通过图形化界面来设计和建模工作流程,包括定义流程步骤、规则和条件、参与者等。
流程建模工具通常支持多种流程建模
标准,如BPMN(Business Process Model and Notation)等,用
户可以根据自己的需求来选择合适的建模标准。
其次,执行引擎是工作流程引擎的另一个核心组件。
它负责根
据流程模型的定义来执行和管理工作流程,包括任务分配、执行顺
序控制、异常处理等。
执行引擎通常支持灵活的流程执行方式,如
串行、并行、条件分支等,以适应不同的业务场景。
另外,监控和报告工具是工作流程引擎的重要组件之一。
它可
以实时监控工作流程的执行情况,包括任务状态、执行时间、参与
者等信息,并提供丰富的报告和分析功能,帮助企业管理者了解工
作流程的运行情况,及时发现和解决问题。
总的来说,工作流程引擎是一种强大的工具,它可以帮助企业
实现工作流程的自动化和优化,提高工作效率和质量。
在当今竞争
激烈的商业环境中,企业需要不断提升自身的管理水平和运营效率,工作流程引擎无疑是一个不可或缺的利器。
希望企业能够充分利用
工作流程引擎,实现数字化转型,提升竞争力,取得更大的成功。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
EOS工作流引擎工作原理作者:Gocom注册用户dogreet(李国生)1. 工作流基础知识……略2. EOS工作流引擎工作原理本文是我在工作之余写的一点我对EOS工作流的了解,我的理解不一定全是对的,可能会与引擎的真正的面目有出入。
所以只能提供给大家一点参考。
2.1. EOS工作流引擎核心调度算法EOS工作流最重要的组成部分是它的核心调度算法,在我们没有深入研究它的工作原理之前我们认为它的工作原理是在工作项,活动和流程实例对象上加了一些标志位来驱动流程的运转。
认为其引擎完全是个由数据库来驱动流程的引擎(安徽二期的工作流平台好象就是以库表来驱动流程的运转),其实它是由事件来驱动流程运转的引擎,数据库只是把引擎运转前后的状态持久化。
在我近来在工作之余对其引擎的工作原理进行跟踪才弄明白在EOS帮助文档上介绍的“事件驱动”的工作流引擎。
2.1.1. EOS工作流引擎的事件类型以上的每个事件都是原子的不可分割的。
其中一系列事件的集合通过EOS引擎事件调度机制实现我们平时在工作中经常遇到的如启动流程,结束工作项等等。
(在事件类型类中EOS定义了29种事件,但在事件工厂类中EOS定义了26种类型。
)1.1.1. EOS工作流事件调度机制EOS事件的调度服务是在工作流引擎初始化时通过服务工厂类加载到内存中(ServiceFactory.initEventService())。
用户可以通过服务工厂类(ServiceFactory)取得JVM的唯一事件服务实例进行事务调度。
所有的事件程序入口都是事件类(EventService),这个类其实是个接口,其有两个实现类,一个是单线程的实现类SingleThreadEventService (在实现代码中其实不是单线程,而是单例的对象),一个是多线程的实现类MulThreadThreadSvc,(其实现方式不在这里详细说明,多线程的类后面又跟了一大堆的线程池实现代码),在事件服务类中有一个属性类是WFEventDisposer,这个类包含了事件的注册,事件的发布,事件的注册是一个静态代码块实现的。
注册了上节描述的29种事件,其实就是把相应的事件代码注册到相应的处理类,事件处理类共用5个(ProcessScheduler,ActivityExecuter,ExceptionHandler,WorkItemHandler,ApplicationHandler),对应事件代码的前5个数字;共有事件的发布有两种,一种是正常发布,一种是无异常的发布(即在具体执行事件时关闭了异常处理)。
所谓的事件发布是给事件服务类传递一个事件对象(WFEvent类),这个事件对象包含了事件类型,线程名,事件ID,流程定义ID,活动定义ID,活动实例ID,和工作项ID等等。
以上简要的描述了事件模型,下面来拿我们平时用的最多的一个构件:结束工作项来详细跟踪它的事件处理。
结束工作项可能是最具有代表性的一个流程动作,因为在做这个时间后遍历了整个流程实例的流程:1,用户通过引擎的API调用WorkItemManager类的finishWorkItem方法,该方法通过服务工厂取得持久层的数据访问服务,并根据workitemID取得WFWorkItem对象。
做相关的判断后通过事件工厂类的createFinishWorkItemEvent方法创建个事件代码为3004的事件对象(WFEvent)。
然后通过服务工厂类取得事件服务类把该事件对象发布给事件处理服务。
从此刻就开始了EOS事件调度服务的运转。
2,事件服务类(拿单线程事件服务类做例子)拿到这个事件类后把该事件通过WFEventDisposer发布该事件。
具体的发布过程很简单,即判断该事件类型是否已注册,如果已经注册则取到改事件代码的注册类。
该代码是3004,则应取WorkItemHandler。
然后调用WorkItemHandler的invoke()方法,3,WorkItemHandler类invoke()中写到:if(event.getType() == 30004) {finishWorkItem(event);}则找到该方法,该方法开始做了相关的判断后做相关标志位的修改:置当前工作项的状态为12,然后判断当前活动是否结束。
(大概的算法是取得已经结束的工作项和该活动总的工作项,取得活动定义的多工作项是否启动。
如果是多工作项则判断完成个数策略:是按百分比还是按操作员个数等等,做一系列的判断后得到应该结束的工作项,如果小于等于已经结束的工作项则该活动结束,没有启动多工作项则相应的处理要简单点),如果该活动已完成,则调用事件服务的结束活动实例事件createFinishActivityEvent;如果没有结束则判断工作项启动的策略是“at_the_same_time”还是“one_by_one”,如果是“one_by_one”则找本活动实例下的工作项状态为1的工作并启动它。
4,结束活动实例是调用事件工厂的方法createFinishActivityEvent,新建一个事件代码为2004的事件。
用createFinishWorkItemEvent的方法发布该事件。
到ActivityExecuter 类中找到finishActivity,该方法修改活动实例状态为7,填写活动结束时间。
如果该活动注册了时限则取消活动时限的注册。
如果该活动实例定义了结束活动的触发动作则触发该动作(通过WFAppCaller调用)。
最后由事件工厂产生一个事件代码为1002的createScheduleNextActivityEvent事件。
由事件服务发布事件。
5,启动下个活动实例的事件动作是事件工厂调用scheduleNextActivity方法,该方法通过流程定义找到下个环节的转移条件,并根据转移条件和分支模式(全部分支:AND;多路分支:XOR;单一分支:OR)生成一个环节定义列表。
引擎首先把未启动的活动实例和挂起的活动实例找到,如果没有则生成一个活动实例。
然后生成一个转移对象(WFTransition),最后把待启动的活动实例对象放到一个列表中。
根据该列表中的活动定义的启动策略(直接启动,待激活,由规则逻辑指定)来启动活动实例;如果是直接启动活动实例则由事件工厂新建一个事件代码为2001的事件startActivity,如果待激活策略则由事件工厂产生事件代码为2000的事件preStartActivity。
同样如果在流程定义中定义了创建活动实例触发的事件则触发该事件,scheduleNextActivity方法做了很多业务处理的事情,所以比较复杂。
6,事件服务调用startActivity方法,修改当前活动状态位为2,并向时限管理服务注册时限,然后通过活动执行类的帮助类分派工作项,分派工作项的过程是判断是否是多工作项,如果不是则按参与人员分派,如果是则判断多工作项的启动策略,启动工作项业务处理比较复杂,并没有相应的事件代码对应,在这里不详细介绍。
以上的六个步骤完成了我们平时最常用的完成工作项的方法。
综上所述应该能够对EOS工作流的事件调度机制有个清楚的认识,比如结束工作项的事件调度有3004->2004->1002->2001这几种事件的触发。
同样还有我们平时比较常用的启动流程实例方法首先是创建一个流程实例,然后开始事件调度:10001->10002->2001,最后是分派工作项。
OSWorkflow里也有自己的调度机制,但在业务上要比EOS简单的多,准确的讲OSWorkflow只有两个概念:steps (步骤)和actions (动作)。
一个简单的调度过程它可能从一个步骤流转到另外一个步骤(或者有时候还是停留在一样的步骤)。
它的调度其实就是一个类:AbstractWorkflow,这个类里面有两个方法:doAction 和transitionWorkflow 基本实现了所有的调度(其实也不能算是调度,只能算是状态的迁移)。
OSWorkflow最大的优点是在执行调度过程中执行的一系列的Function(在SOA里叫服务模型,在EOS里叫展现逻辑),它在执行客户端的服务时的机制时还是比较复杂的,如果感兴趣在工作之余可以看一下。
还有个最近比较流行的开源的引擎,JBpm,我没看过这个,好象现在又整合到JBOSS下去了,好象很复杂。
1.2. 时限管理服务1.2.1. 时限的分类时限类型有两种:一种是一次触发完成时限,还有一种是循环触发(譬如隔多长时间进行一次提醒)并可设置触发的次数。
1.2.2. 时限计算器在工作流引擎启动时就启动一个JVM唯一实例的时限计算器,该类可以使用引擎默认的。
也可以自己去实现一个自定义的计算方法,在配置文件中注册要重写的类名即可。
引擎的时限计算器只有两个方法,一个是计算结束时间,还有一个是计算提醒时间。
其实是个静态类。
1.2.3. 时限服务的启动在引擎中的时限服务有两个,一个是引擎启动的时候启动的时限服务,该服务初始化了时限对象列表;一个是在引擎启动后启动的服务,该服务是对列表中的时限对象进行轮询,触发超时的时限对象对应的触发事件,并移除该对象时限。
时限的线程处理用了大量的过程化程序的结构,在这里还是比较绕人的。
1.2.4. 时限的注册和移除在流程引擎中的时限服务其实就是在维护一个时限对象的列表,该列表记载了处于运行状态的活动的时限对象。
在启动一个环节或启动一个流程时判断该活动或该流程的时限,如果该活动或该流程定义了时限则向时限服务注册该时限;在TimerManager类中的注册方法的实现是调用时限服务类的registeTimer方法,往时限对象列表(Vector)追加一条记录。
在结束活动事件时或结束流程时如果是超时的操作则时限对象列表中没有该活动的时限对象,因为该对象已被时限触发器触发并移除。
如果没有超时则要把这个向量列表中的那条时限对象给去掉。
在TimerManager类中的注册移除方法的实现是调用时限服务类的unregisteTimer方法,往时限对象列表(Vector)移除一条记录。
1.2.5. 时限事件的触发时限的触发完全是后台的线程做的事情。
该线程对时限服务所维护的时限对象列表进行轮询,如果发现有超时的对象则触发已定义好的动作,该动作就是我们平时在studio中设的如果超时则干什么事的触发动作。
对时限的处理是通过java.util.Timer这个类来实现的。
是通过新建一个时限任务(MyTimerTask)让Timer来执行。
并向该类传递一个OnceTimerHandler对象实例。
该对象有个方法timerTrigged就是到了预定时限时触发的方法。
该方法首先调用timerHandler类的handlerTimer方法,即如果有触发事件的话就调用上节讨论的事件代码以4开头的事件。