转蝲?http://taiwan.cnet.com
在谈?BPM 相关标准之后Q这ơ我惌读者谈 BPMS 的架构、组成模块及其各自功能，让读者有全盘性的了解Q希望能破除一般h?BPMS 的迷思?
关于 BPM Q业界有些迷思。例如，常听到有 BPM = EAI + Workflow Q?PBMS 只不q?Workflow 厂商的旧瓶新酒，换汤不换药，只要原来 WfMS 加上pȝ整合?Adaptors 变?BPMS Q或?EAI 厂商加上 Activity Modeling 的工h者是 Routing Engine 重新包装一下，也可以称?BPMS ?/P>
我认?BPMS 不只是如此，而是一个生命周期。顺着 BPM 生命周期了解用户的操作场?(Scenario) Q是理解 BPMS 的组成全貌最好且最直觉的方式。在本文中，我首先介l完?BPM 生命周期Qƈ从其中的每一步骤接着介绍工作内容、用到的工具及其功能、与用户的角艌Ӏ最后，我会(x)以一张完整的 BPMS 架构图，详细介绍其中l成的模块功能?A id=more-7>
BPM Q也要谈生命周期 (Life Cycle)
BPMS 让企业可以灵敏反应外部环境的变动q快速变动企业内部的程作业Q所以生命周期所的是持箋性改善与周而复始的循环?BPM 生命周期另一个含意就是，它是 BPMS 工具导入的方法论 (Methodology) ?BPMS 解决Ҏ(gu)最重要的核心就是方法论Q它臛_要包含思考哲?(Philosophy) 、方?/ 步骤 (Methods / Steps ) 、与伴随的工?(Tools/Utilities) 。因为没有Q何两家的程Q组l，{略目标是全然一L(fng)Q因此怎样才能从策略目标规划到最后系l导入执行连贯一体，成功而有效地完成建置所依赖的才是合适的Ҏ(gu)论?
目前各家 BPM 厂商所提出的生命周期不相同，乃是因ؓ(f)解决Ҏ(gu)所面对的业或应用领域不同Q所以有了各自强调与专注的重炏V例如， IBM HoloSofx 提出的是Q徏?(Create) 、管?(Manage) 、自?(Automate) 、协?(Collaborate) Q?Howard Smith & Peter Fingar ??BPM - The Third Wave 』一书所提出的是Q徏?(Model) 、布|?(Deploy) 、与理 (Manage) Q?Italio 提出的是发掘 (Discovery) 、徏?(Modeling) 、支?(Supporting) ?Monitoring ( 监控 ) 、及 Improvement ( 改善 ) 。在此我?x)提为完整的程步骤Q但不见得每?BPM 厂商的都W合Q读者可参考下图－ BPM 生命周期?
图一?BPM 生命周期
·阶段一?程发掘 (Discovery) :
要导?BPM W一步骤当然要先清楚知道现行程的作业方式与状况Q尤其是程内的信息?(Message flow) 、事件流 (Event flow) 、或控制?(Control flow) 。哪些流E可以自动化Q哪些是人工程Q有哪些人参与？程是在l织内部或外部被执行Q?BPMS 在此步骤的主要特征是如何 自动扑ևpȝ的商业逻辑 。通常企业?x)聘请外部顾问师或领域专家来协助辅导Q这个动作有人称?程评估 (BPA, Business Process Assessment) Q评估范围可能涵盖策略与理目标与流E的q结。同时企业也?x)配合导入一些管理的主题而作 程再?(BPR, Business Process Reengineering) Q例如评分计分卡 (BSC, Balance Score Card) 、六个标准差 (Six Sigma) 、或 ISO 9000 品质理pȝ?
· 阶段二?程设计 (Design) Q?/STRONG>
此阶D|一个包含四几个步骤的反复式的小循环 (Iterative mini-cycle) Q徏?(Modeling) ?( 分析 Analyzing) 、模?(Simulation) 、重?(Redesigning) 程。如前所qͼ面对外部的竞争压力与商机Qؓ(f)了让企业可以快速重构流E， 因此一些细致的程变革 (Fine-grained process change) 只需利用此阶D늚步骤p作出实时的反应?/P>
程 建模 所q用的工L(fng)?Process Designer 通常包含三个模块Q组l?(Organization Chart) 、流E图 (Activity Diagram) 、与H体 (e-Form) 设计工具。它们分别对应流E中三个最重要的元素：(x)人、活动与文g ( 有兴的读者可参阅 Process Modeling Conceptual Framework 有关的资料，后箋Ҏ(gu)在适当Z(x)再做介绍 ) 。徏模之后可以作执行动作前的 分析与仿?来验证设计的程是否正确合适或最?jng)_Q此外它能还提供现行程可能遇到的瓶颈信息，以避免执行后才发现问题进而导致很大的营运损失。如果分析模拟出来的l果q不满意Q可以反?重构 程直到产出满意的结果。分析指的是从流E定义的语意与理Z的推论分析，仿真则可讑֮机率变量与行为假设让pȝ自动跑出期望值或变异差数据，有些则仅提供自动执行 (Animation) 或手动逐步执行以观流E行为?
此阶D?BPMS 的主要特征是 囑Ş化的接口 Q让?IT 背景的用户可藉由拖曳方式也能Ll装或分解流E；此外q用程资 (Process assets) 的观念，让流E定义隐含业界的最?jng)_?(Best practices) 或流E样?(Process Pattern) Qƈ且储存于程仓储 (Process Repository) 以供随时再利?(reuse) ?
· 阶段三、流E执?(Execution) Q?
意指CU的程能被参与者顺利执行完成。负责控制执行的模块可称为工作流E引?(Workflow Engine) 或流E服务器 (Process Server) 。在此阶D?BPMS 主要的诉求是分布式交?(Distributed transaction) 的管理，因ؓ(f)q些交易可能是复杂度高的跨l(f)状流E?(Nested process) 而且交织着新旧pȝQ甚臛_既有的应用系l当成流E组件来执行。至于流E的执行者通常多是应用pȝQ可以不用h的参?(human intervention) 而自动执行，也就是一般所U?程自动?(BPA, Business Process Automation) ?
此外Q排E工?(Scheduler) 可以应用来设定自动启动流E的旉与周期频率。有?BPMS 的品会(x)提供规则引擎 (Rule Engine) 来负责商业规则判别与推理。此阶段另一个重要的特点是在不用技术h员的参与下，依然可以让流E用戯行编辑与修改商业逻辑。例如，代理人的指派规则通常相当复杂Q背后就需要有 Rule-based 的机制来支持?
程布v (Deployment) Q?/STRONG>意指设计好的流E推ZU让所有参与?(Participant Q可能是人，应用pȝQ或其它程 ) 来执行。这个步骤的主要特征是能以最的力气H?effort H达成运资?(Computing Resource) 与组lh员的l合 (binding) Q如事先整合应用pȝlg (Application components) ?
与h互动 (Interaction) Q?/STRONG>在流E的执行中很重要的就是与人的互动。ƈ非所有流E都可以自动化，所?BPMS 让h能管理自动流E与人工程之间的接口。负责与Z动的接口UCؓ(f)工作目的处理程?(Workitem Handler) 。有时候流E接口本w也是一个流E，例如动态加?x)签或在H体输入下一步流E的分派。过?Workitem Handler 相当单，然而现在有們丰富化与l致化的势。必要的时候还能让用户客制化或整合在不同系l的接口中。由于这个需求有快速提升的势Q所以各家厂商纷UhZ富且个h化的程入口|站 (Personalized process Portal) ?
W四阶段、管理维?(Administration) Q?/STRONG>
当流E上U后伴随产生了管理维护的问题Q如例外状况的介入处理、组lh员的变更、流E重新分z、或程版本升的媄响。在此，有个重要的模块称作流E活动监?(BAM, Business Activity Monitoring) Q它可以随时回报程的执行状态与q程Q而且用户也可以设定流E要q踪的关卡ƈd回报Q具有预警功能ƈ能随时掌握问题处理的时效。另外服务器的流量与执行监控及流E仓储的数据l护的效能也相当重要?
W五阶段、流E最?jng)_ (Optimization) Q?/STRONG>
程改善 (Improvement) 是个持箋性的zdQ不断反复朝向最?jng)_q进。流E测?(Measurement) 能提供流E的执行l效 (Performance) Q?BPMS 的报表工?(Reporting Tools) 能让企业对自ql织行ؓ(f)充分了解作ؓ(f)持箋改善的依据，如此方能{划出改善与最?jng)_的策略。流E分?/ 仿真着重在执行前的分析Q例如自动侦瓶?(bottleneck) 、死l?(deadlock) 与流E定义的不一?(Consistence) Q而流E测量则是执行后实际资料的分析，可以清楚知道程消耗时间与资源。这个阶D跟商业智慧 (BI, Business Intelligence) 的技术与主题怼性很高的Q差异在 BPMS 可以自动U录与收集流E相关的数据。尤?BPMS 所附含的流EW效A表版 (Dashboard) Q它提供一个全面式的概观让ȝ单掌握且一目了然哪些流E是在标准差内，哪些是在失控状态。当然这些报表，都是用户可以自行定义或查询的Q不?IT 人员的参与?
BPM Q?Workflow +EAI
怿从上q的介绍Q读者可以清楚认识到 BPM l对大于 Workflow ?EAI ?BPM 的主要精在于企业流E的理Q且主要的焦点在于业务性用?(business users) 而非技术性用?(technical users) Q在于流E弹性实时调整而非数据与应用系l的整合。所以仅是工作流E自动化加上 EAI 企业应用软g的{换机制是不以的늛企业理程中所有必要的环节。例如尚有让理ȝ能实时掌握流E成本效?(cost/effective) 评量与流EW?(Performance) 理Q业务性用户可以轻易调整组装流E以提供客户最佳业务服务，{等?
我将上述中的工具整合hQ架构如图二所qͼ(x)
BPMS pȝ架构 (System Architecture)
图二?BPMS pȝ架构?
一个完整的 BPMS pȝ需由流E设计环?(Process Design Environment) 、流E仓储或储存?(Process Repository) 、流E服务器 (Process Server) 、用h行环?(User Execution Environment) {主要元素所架构而成?
· 程设计环境 (Process Design Environment)
程设计环境扮演着程设计阶段中最重要的流E徏模工作，通常包含了「组l图?(Organization chart) 、「电(sh)子化H体?(e-form) 、活动图 (Activity Diagram) 、与商业规则 (Business Rule) {相兛_素，q可透过直觉囑Ş化的接口Q协助流E设计者进行企业流E的建构?
l织N份大多与l织目录服务pȝ (Directory system) 相结合，以协助企业进行组l的调整与管理，如支?LDAP ?AD {相关目录服务。而电(sh)子窗体指的是信息呈现的接口，一般而言可将应用pȝ的数据与程相关的数据，透过所谓的?sh)子H体来展玎ͼ便于处理与h互动的部分，而呈现的方式可透过特定的工具快速的订制。在了解程整体q作与规划中Q透过zd囑֏清楚地规划与了解程中的各个zd彼此的先后顺序与兌Qƈ订定程的运作条件与事g触发的相兛_作，再透过l合商业逻辑Q?Business Rule Q的方式Q让企业更清楚流E的q作方式且易于修改，在采购流E中Q若采购金额大于 100,000 台币者需{核臛_理，其余仅需{至l理Q就是个明显的例子?
程仿真Q?Simulator Q与程设计分析Q?Analyzer Q，则是透过程数据的仿真得以事先验证流E执行时的结果与程设计兌的分析（如在复杂的流E中Q重要的程元素或关联未建立Q，辑ֈ程执行前事先的预防Qƈ认设计的流E是否正合适或最?jng)_?
· 程数据储存?(Process Repository)
程仓储包含了流E定?(Process Definition) 、流E执行纪?(Execution Log) 、与应用数据 (Application Data) 。流E定义包括了程q作所有相关的数据Q最明显的就是流E三要素Qh、活动与文gQ都U录在流E定义中Q藉由流E的规则引擎 (Rule Engine) 的参数即数据的变异数或是各个节点所制定的活动时间限制等定出合适的程定义Q最后透过程服务器执行定义好的流E；程执行U录指的是流E执行过E中所有的U录Q有?BPMS 此部䆾内徏于系l中Q有的则是需另行所需U录抄写到数据库中；应用数据则是指在程执行的过E中Q所使用到其它系l的相关数据q着程U录下来或有所兌Q如请采购流E执行中Q需依照既有 ERP pȝ的相x据进行逻辑判断Q甚至需其抄写xE窗体中。而在此所指的应用性数据ƈ没有只局限在内部数据库，也包含了Ҏ(gu)程的定义向l织外可能以 web service 的方式呼叫外部数据来应用?
· 程引擎 / 服务?(Process Engine/Server)
程引擎是整?BPMS 中最重要的一环，它负责正无误地流E在正确的时间传送给正确的h或系l，而由于流E的q作Z业营q的核心Q因此能处理复杂且大量的程工作是流E引擎所必备的条件。分布式交易 (Distributed transaction) 的管理与负蝲qQ?Load Balancing Q将是考量的重炏V?
· 用户执行环境 (User Execution Environment )
q边所说的用户环境指的是用户与流E沟通的接口。一般简易的用户接口多藉由待办事（ Work lists Q让用户使用程工作。而由于企业入口网站的风行Q一个面面俱到的 BPM 产品通常透过 Web-based 接口Qƈ加入口网站（ Portal Q的概念Q提供所谓的程入口|站接口Q?Process Portal Q作为用户用流E的沟通接口。如此除了可清楚地看到透过程引擎指派而生的的各Q务或工作事项 (work items) 外，q可l合其它入口|站与应用系l整合的机制Q如使用协同工作功能促进员工彼此沟通与交流Q像是公布栏、行事历或讨论区{。另外也可透过待办事项的启?(trigger) 能够呼叫 (invoke) 与之相关的应用程?(applications) 甚至Ҏ(gu)各清楚定义的个别兛_ (activity) 自动?web service 的方式来跨组l地呼叫 (invoke) 外部数据作交?(transaction) 辑ֈ名副其实?SOA 技术架构概c?
此外藉由程|站接口用户 ( 通常指中阶以上主或部门ȝ ) 可利用行政管理工?(Administrator Tools) 与报表工?(Reporting Tool) 。就行政理工具来说Q进入流E数据储存库捞取程定义的信息所作出的制式化报表可以清楚的知道员工的工作负荷量的轻重E度Q而各U的l计量表包含热门排行、单位时间工作量l计、单位工作量l计、部门工作量l计、流E工作量l计、项目工作量l计提供理者用，使管理h员随时了解企业流E运作的各种情况。用户也能以 web service 的方式捞取应用数据作出动态分析。而流E的监控与管?(Activity Monitor) Q亦可让用户或管理者透过 Web 的方式，实时地追t目前流E的q度或进行例外的处理以能做到修正或变动的因应。也是说活动的监控Ҏ(gu)E范例的执行提供了一个W效量的准则。最后透过上述工具使流E作到实时的修正辑ֈ最?jng)_让工作更有效率?
?
]]>
|
工作?/STRONG>现状 Q?A target=_blank>原文Q? 作?A >Tom Baeyens 译dinghong 前言如果数据库系l（ database systemsQ像受h敬的智者讲q的条理清晰的故事，那么工作?/STRONG>Q?STRONG>workflowQ就像一^臭未q的子在大谈各自的“哲理”。之所以这栯Q我是想指出Q?STRONG>工作?/STRONG>pȝ Q?STRONG>workflow management systemsQ还处于技术发展曲U（ technology hype curveQ上的初U阶Dc在q个领域我们面临一个激动h心的阶段?Z描述q一点，可以?STRONG>工作?/STRONG>和关pL据库pȝQRDBMSQ做一个对比。当在Y件开发团队中谈论RDBMSӞ大部分h?x)有一个清晰的概念Q在你和他们交流的时候，Z?x)通过d的点头表C可或理解你所说的。可当用工作流术语讨论工作?/STRONG>Ӟ他们?x)摇头表CZ同意Q因为每个h?STRONG>工作?/STRONG>术语都有不同的理解?/SPAN>
 Figure 1: Workflow vs. RDBMS positioned in the hype-curve D形成q种状况的原因之一Q是?STRONG>工作?/STRONG>中用了q多的概c在q个领域中的大量规范和工h有一个是怼的。当Ӟ它们怺之间有重叠ƈ且会(x)怺参考引证?BR> 在介l?STRONG>工作?/STRONG>时有一个话题必d括，那就?STRONG>工作?/STRONG>?STRONG>业务程理QBPMQ的关系。术语?STRONG>工作?/STRONG>”通常描述Z计算机系l的一pd相关交互。在开发h员中Q?STRONG>工作?/STRONG>l常被提及。有Ӟ工作?/STRONG>的意思是指一些不同的UI界面。业务流E管理的范围比较q，相比之下工作?/STRONG>多半局限于技术领域。业务流E管理还从管理h员的角度涉及了非技术问题，比如分析、组l的效率?/P>
在本文中Q我首先解释什么是工作?/STRONG>理pȝQ然后介l业务流E管理的优点。接下来描述一下ؓ(f)什?STRONG>工作?/STRONG>市场乍看h如此混ؕ。本文给出的主要l论是：(x)选择工作?/STRONG>pȝ是想?STRONG>工作?/STRONG>pȝ的公司，要面对的最困难的事情。ؓ(f)此，本文的核心部分描qC一个流E定义（process definitionQ的四个层次Qؓ(f)你选择工作?/STRONG>提供一个基。本文还用中立的语言描述?STRONG>工作?/STRONG>和BPM的通用概念。最后，l出了一些规范和工具的指导性描q?/P>
工作?/STRONG>pȝ是以规格化的程描述作ؓ(f)输入的Y件组?它维护流E的q行状?q在人和应用之间分派zd?/P>
Z后面的描qͼ我们先定义一些基本的术语Q流E定义（process definitionQ和程实例Qprocess instanceQ? 一个流E定?/U>是一个业务流E或q程的规格化描述。一?U>程实例是流E定义的一个运行实体?都目前ؓ(f)止，概念q比较清晰是不是Q但当再深入一步时Q我们就要小心用文字了。如何阐q流E中的步骤，现在q没有一个统一的方式。这是各U?STRONG>工作?/STRONG>规范和工具之间主要的分歧?/P>
Z么应当禁止用术语“活动（activityQ?.. 工作系l?/STRONG>另一个重要的职责是维护每一个流E运行的上下文信息?程上下文变量（process context variableQ?/U> Q或U变量，是与程实例相关的变量。如Q休假申L(fng)开始日期、数据库中一条记录的键倹{文档管理系l中一文档的索引{。通常在流E定义中声明q些变量Q然后在程实例生成Ӟq些程变量被实例化。所有成熟的工作管理系l?/STRONG>都支持定制的变量cd?/P>
使用工作管理系l?/STRONG>的目的之一是作Z业应用系l集成（EAIQ的q_。在当前大部分企业IT架构中，各种各样的异构（heterogeneousQ应用和数据库运行在企业内网中。在q些pȝ被应用到l织Ӟ都有一个清晰的目标。例如，客户理、文档管理、供应链、订单、支付、资源计划等{。让我们U这些系lؓ(f)专门应用Q?dedicated applicationsQ。每一个专门应用都包含它们所支持业务程的领域知识。这些专门应用中的自动化程Q被DC业中更大的非自动化流E中。每当一个这L(fng)专门应用安装q投入用，都会(x)带来涉及其他多个应用的新功能需求。企业应用系l集成（EAIQ就是通过使用多个专门应用满软g新需求的Ҏ(gu)。有Ӟq只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务程编码在软g中。可以这么说Q在你购C门应用时Q你是购C一l固定的自动化业务流E。?STRONG>工作管理系l?/STRONG>是不必事先知道问题域的相关信息的?STRONG>工作系l?/STRONG>业务流E描qC入ƈ理程实例的执行，q得它比专门应用更灉|Q当然你也要q力编写业务流E的规格化描qͼ。这是Z么说工作系l?/STRONG>和专门系l是怺补充的?STRONG>工作系l?/STRONG>可以用来理全局的业务流E。如果专门应用支持你所需要的业务程Q那么用专门应用。在此讨论的工作系l?/STRONG>的第一U用方式就是：(x)l合所有的专门应用Q?STRONG>工作系l?/STRONG>构徏一个EAIq_?/P>
工作系l?/STRONG>能够发挥很大价值的W二个用方式是Q协助涉及多人相关Q?STRONG>工作?/STRONG>软g的开发。ؓ(f)了达到这个目的，大部?STRONG>工作系l?/STRONG>都有一个方便的机制Q来生成执行d的表单。对于专注于ISO 或?A >CMM认证的组l，采用q种方式使用工作系l?/STRONG>能够显著提高生率?不用过E用文字的Ş式写在纸上，工作系l?/STRONG>使你通过程定义建模实现q程的自动化Q如使用ZWeb的应用）?/P>
工作系l?/STRONG>的第三种使用方式是：(x)?STRONG>工作引?/STRONG>嵌入到其他应用中。在前面我们谈到Q专门应用将指定问题域相关的业务程固化在Y件中。开发专门应用的公司也可以将工作引?/STRONG>嵌入C们的软g中。在q里Q?STRONG>工作引?/STRONG>只是作ؓ(f)一个Y件组Ӟ对于应用的最l用h不可见的。将工作引?/STRONG>嵌入到应用中的主要原因是Z重用Q不重复发明轮子Q和应用软g的可l护性?/P>
对于引入工作?/STRONG>的组l，能够在Y件开发和业务两个层次受益?/P>
工作管理系l?/STRONG>能够化企业软g开发甚至维护? 在自动化业务程之前Q分析ƈ它们规格化是一件艰苦但?x)有很好回报的工作?A >e-workflow.org对于分析程能够带了的益处有不错的阐qͼ(x) 我认Z们还遗漏了一个?STRONG>工作?/STRONG>pȝ最重要的因敎ͼ(x)提高对P代开发的支持。如果Y件中业务程部分不容易更改，l织׃(x)花很大的_֊在开发前的业务流E分析中Q希望一ơ成功。但可?zhn)的是Q在M软g目开发中Q这都很能实现?STRONG>工作?/STRONG>pȝ使得C务流E很Ҏ(gu)部vQ业务流E相关的软g可以一UP代的方式开发，因此使用工作?/STRONG>pȝ使开发更有效、风险更低?/P>
一?STRONG>工作管理系l?/STRONG>以流E定义作入。在q里Q可以将程定义看作UMLzd图、UML状态图或者有限状态机。在提交一张费用单据、申请休假、要求一个报仗?..之后Q?STRONG>工作?/STRONG>pȝ负责l护q些程定义的执行状态和上下文。ؓ(f)此，需要通知工作?/STRONG>pȝ状态的变化。运行流E的状态变化可以记录下来，以备监控理?/P>
圈套QPitfallQ?/B> 所有状态和控制的表述Q都属于业务程的状态层。标准编E语a中的控制来源于Von Neuman体系。控制流定义了必被执行的指令的序Q控制流由我们书写的命o(h)、if语句、@环语句等定。在业务程中的控制基本与此一致。但在业务流E中不是使用命o(h)而是使用状态作为基本元素?/P>
在流E中Q?U>状?/U> (或者说{待状?代表了一U对外部参与者（actorQ的依赖。状态的意思就像“现在Xpȝ或某某h必须作某些事Q在此等待直到参与者通知q些d已完成”。状态定义了一U对外部提供l果的依赖。状态典型的例子是批准步骤（stepQ?/P>
程定义中的状态也指定了执行依赖于哪个参与者。在zd图中Q泳道（swimlanesQ的标注代表q些参与者的名字?STRONG>工作?/STRONG>pȝ使用q些信息构徏d列表Q这是一?STRONG>工作?/STRONG>pȝ都有的功能。如前所qͼ参与者可以是Z可以是系l。对于需要h参与的状态，工作?/STRONG>pȝ必须在运行时计算出具体的个h。这L(fng)计算?STRONG>工作?/STRONG>pȝ必须依赖于组l结构信息。关于这斚w的一非常有的文章是在further reading section提到的?STRONG>工作?/STRONG>应用中的l织理”（ 'Organizational Management in Workflow Applications'Q?/P>
程定义的控制流包含一l状态和它们之间的关pR状态之间的逻辑关系描述了哪些执行\径可以同时执行，那些不可以。同步执行\径用分叉QforksQ和联合QjoinsQ徏模，异步执行路径用判断（decisionsQ和合ƈQ?mergesQ徏模。注意在大多数模型中Q在每个状态之前都有一个隐式合q?/SPAN>?/P>
UMLzd囄常被用来做业务流E徏模。作ZU直观和通用的表达，zd囑֜囑Ş表述上有一个主要问题，是没有区分状态和动作Q它们都用活动来表示。缺这U区分（D状态概늚~失Q是学术z֯UMLzd囄主要批评。UMLzd囄W二个问题是在UML2.0版中引入的。当多个q移QtransitionsQ到达一个活动时Q以前的版本规定q是一个缺省合qӞmergeQ，?.0版中规定q是一个需要同步的~省联合QjoinQ。在我看来，UMLzd囄囑Ş部分仍旧可以用来对业务流E状态层ơ徏模，只要使用时对两条构徏语义作如下的变化Q?/SPAN>
在流E运行过E中Q?STRONG>工作?/STRONG>pȝ用一个o(h)牌（tokenQ作为指针跟t流E的状态。这相当于Von Neuman体系中的E序计数器。当令牌到达一个状态时Q它被分配给工作?/STRONG>pȝ{待的外部参与者。外部参与者可以是个h、组l或者计机pȝ。我们定义流E运行的执行人或pȝ为“参与者”（actorQ。只有在工作?/STRONG>pȝo(h)牌分配给一个参与者时Q才需要访问组l结构信息?STRONG>工作?/STRONG>pȝ通过分配令牌构徏d列表?/P>
程上下文变量（process context variableQ?/U> Q或U变量，是与程实例相关的变量。流E开发h员可以用流E变量存储跨流E实例整个生命周期的数据。一?STRONG>工作管理系l?/STRONG>有固定数目的数据cdQ另一些你可以定义自己的数据类型?/P>
注意变量也可以用来存攑ּ用（ referencesQ。一个变量可以引用如数据库中的记录、网l上的文件。什么时候用引用，取决于用引用数据的其他应用?/P>
和流E变量相关的另一个o(h)人感兴趣的方面是Q?STRONG>工作?/STRONG>pȝ如何数据{化ؓ(f)信息?STRONG>工作?/STRONG>是用于组l内部跨各U异构系l实CQ务和数据协同的。对于业务流E中人工执行的Q务，工作?/STRONG>pȝ负责从其他相关系l，如SAP、数据库、CRMpȝ、文档管理系l收集数据。在业务程的每一个h工步骤，只有相关联的数据被从异构系l中攉和计。通过q种方式Q从不同pȝ来的数据被{换ƈ展现Z息?/P>
如前所qͼ动作是在程q行q程中，工作?/STRONG>pȝ响应指定的事ӞeventQ执行的一D늨序逻辑Qprogramming logicQ。程序逻辑可以是二q制或源代码形式的、用M语言或脚本编写的软g。程序逻辑层是所有这些Y件片断和关于在什么事件发生时调用它们的信息的l合。程序逻辑的例子包括发Email、通过消息代理发消息、从ERPpȝ中拿数据和更新数据库?/P>
当前在BPM领域中，关于可执行业务流E的规范有趋向于l一集中的趋ѝ?XLANG, WSFL 和BPML合ƈ为基于交互（消息交换Q的BPEL。BPEL在面向服务体pȝ?SOA)的大背景下定义。它的前提条件之一是涉及的服务必须用WSDL声明。BPEL规定了一套XML语法Q这套语法可以看作一U编E语aQ用来描q包括对WSDL定义的服务调用的控制?/P>
在可执行业务程和基于状态的工作管理系l?/STRONG>所使用的方法中Q我注意C三点主要的区别：(x)
最后我们看看真实世界中?STRONG>工作管理系l?/STRONG>。选择一?STRONG>工作管理系l?/STRONG>是一件困隄事情Q但有选择L没有选择好?-) 本文阐述工作?/STRONG>基本概念的目的之一Q就是你能够作更好的选择。但我也意识刎ͼ对于现在的Y件架构师来说Q选择工作?/STRONG>pȝ是一件最h战性的工作?/P>
下面的列表来源于三个地方Q?A >my previous article, the list of Carlos E Perez, ?list by Topicus. Michael zur Muehlen作了一个所?STRONG>工作?/STRONG>相关规范的介l性的qȝ?/A>Q很不错?/P>
我同?A >John Pyke 在我看来Q导致规范如此之多而同时每个规范的应用又很有限的原因是Q在工作?/STRONG>最基础概念上大家达成的p很少?STRONG>工作?/STRONG>是最Ҏ(gu)让你感到心烦的话题，因ؓ(f)工作?/STRONG>本n的概念会(x)和其他相x念和技术淆在一赗可以D一个具体的例子Q比如说工作?/STRONG>完全是对Web Service的补充。你可以通过暴露接口以Web Service的方式访问一?STRONG>工作?/STRONG>理pȝQ但是不能假定L必须通过Web Service接口讉K工作?/STRONG>pȝ接口。一些规范造成了这L(fng)假设。除了Web ServiceQ其他容易淆的概念和技术包括：(x)Email、流E之间的通讯、Web应用和组l结构?/P>
?STRONG>工作?/STRONG>领域W一个致力于标准化工作的?A >Workflow Management Coalition (WfMC)Q开始于 1993?WfMC发布?A >参考模?/A>很不错，它定义了工作管理系l?/STRONG>和其他相关部分之间的接口。WfMC的另一Ҏ(gu)果是XPDL规范?XPDL定义了描q?STRONG>工作?/STRONG>声明部分Qdeclarative partQ的XMLl构。我个h认ؓ(f)Q参考模型和XPDL是目前最好的规范?/P>
我在本文中指?STRONG>工作?/STRONG>市场q属于年轻而又混ؕQyoung and wildQ的阶段Q但已经有可靠的工具存在?
从以上所有这些中能得到的l论是：(x)
我希望本文能够激发你?STRONG>工作?/STRONG>的兴ƈ且能够ؓ(f)你进行有效的Ҏ(gu)提供正确的背景知识?/P>
about the author 译?BR> 以下者加Q?/P>
1、网友flyislandҎ(gu)文的可视化展?/A>Q很直观Q?/P> |
]]>
This chapter describes how to work with timers in jBPM.
Upon events in the process, timers can be created. When a timer expires(l止), an action can be executed or a transition can be taken.
10.1. Timers
The easiest way to specify a timer is by adding a timer element to the node.
<state name='catch crooks'>
<timer name='reminder'
duedate='3 business hours'
repeat='10 business minutes'
transition='time-out-transition' >
<action class='the-remainder-action-class-name' />
</timer>
</state>
<state name='catch crooks(骗子)'>
<timer name="reminder(提示)" duedate(到期?="3 business hours" repeat="10 buesiness minutes" transition='time-out-transtion'>
<action class='the-remainder-action-class-name'/>
</timer>
</state>
A timer that is specified on a node, is not executed after the node is left. Both the transition and the action are optional. When a timer timer is executed, the following events occur in sequence :
an event is fired of type timer
if an action is specified, the action is executed.
if a transition is specified, a signal will be sent to resume execution over the given transition.
Every timer must have a unique name. If no name is specified in the timer element, the name of the node is taken as the name of the timer.
The timer action can be any supported action element like e.g. action or script.
Timers are created and cancelled by actions. The 2 action-elements are create-timer and cancel-timer. Actually, the timer element shown above is just a short notation(W号) for a create-timer action on node-enter and a cancel-timer action on node-leave.
2 action-elements :
create-time node-enter
cancel-time node-leave
Scheduler deployment
Process executions create and cancel timers. The timers are stored in a timer store. A separate timer runner must check the timer store and execute the timers when they are due.
10.2. Scheduler deployment
Process executions create and cancel timers. The timers are stored in a timer store. A separate timer runner must check the timer store and execute the timers when they are due.
三个Actor:
process executions(程执行):
a. scheduler timer (日期安排计时?
b. cancel timer (取消计时?
timer store(计时器储? --->cancel timer--->scheduler timer
timer runner(计时器运行? --->execute timers that are due
Scheduler Service
timer runner
The following class diagram shows the classes that are involved in the scheduler deployment. The interfaces SchedulerService and TimerExecutor are specified to make the timer execution mechanism pluggable.
process execution(actor) ---> SchedulerInstance ---> SchedulerService (接口)<----SchedulerServiceImpl(接口实现)
--->JBPM_TIMER database
/SchedulerMain |||
Runnable(接口)----TimerRunner(实现接口)--------->TimerExecutorQ接口）<---------TimerExecutorImpl(接口实现)
\SchedulerServlet
----------------------------------------------------------
11. Business calendar (商业日历)
This chapter describes the business calendar of jBPM. The business calendar knows about business hours and is used in calculation(计划) of dueQ预期的Q?dates for tasks and timers<d和计时器>.
The business calendar is able to calculate(计划) a date by adding a duration(持箋旉) and a date.
11.1. Duration(持箋旉)
A duration is specified in absolute or in business hours. Let's look at the syntax:
<quantity> [business] <unit>
Where <quantity> is a piece of text that is parsable with Double.parseDouble(quantity). <unit> is one of {second, seconds, minute, minutes, hour, hours, day, days, week, weeks, month, months, year, years}. And adding the optional indication business means that only business hours should be taken into account for this duration. Without the indication business, the duration will be interpreted as an absolute time period.
<quantity> [business] <unit>
<数量>[商业]<单元>
q里<quantity>是一D|字，用来解析使用Double.parseDouble(quantity). <单元>是{U、分{等}中的一U。ƈ且增加可选的指示商业意味着仅仅商业旉被考虑一D|间?没有q个指示商业Q持l时间将被解释ؓ(f)一个完全的旉区域?/P>
11.2. Configuration(配置)
The file org/jbpm/calendar/jbpm.business.calendar.properties specifies what business hours are. The configuration file can be customized and a modified copy can be placed in the root of the classpath.
This is the example business hour specification that is shipped by default in jbpm.business.calendar.properties:
hour.format=HH:mm
#weekday ::= [<daypart> [& <daypart>]*]
#daypart ::= <start-hour>-<to-hour>
#start-hour and to-hour must be in the hour.format
#dayparts have to be ordered
weekday.monday= 9:00-12:00 & 12:30-17:00
weekday.thuesday= 9:00-12:00 & 12:30-17:00
weekday.wednesday= 9:00-12:00 & 12:30-17:00
weekday.thursday= 9:00-12:00 & 12:30-17:00
weekday.friday= 9:00-12:00 & 12:30-17:00
weekday.saturday=
weekday.sunday=
day.format=dd/MM/yyyy
# holiday syntax: <holiday>
# holiday period syntax: <start-day>-<end-day>
# below are the belgian official holidays
holiday.1= 01/01/2005 # nieuwjaar
holiday.2= 27/3/2005 # pasen
holiday.3= 28/3/2005 # paasmaandag
holiday.4= 1/5/2005 # feest van de arbeid
holiday.5= 5/5/2005 # hemelvaart
holiday.6= 15/5/2005 # pinksteren
holiday.7= 16/5/2005 # pinkstermaandag
holiday.8= 21/7/2005 # my birthday
holiday.9= 15/8/2005 # moederkesdag
holiday.10= 1/11/2005 # allerheiligen
holiday.11= 11/11/2005 # wapenstilstand
holiday.12= 25/12/2005 # kerstmis
business.day.expressed.in.hours= 8
business.week.expressed.in.hours= 40
business.month.expressed.in.business.days= 21
business.year.expressed.in.business.days= 220
----------------------------------------------------
13. jBPM Process Definition Language (JPDL) (jBPM程定义语言)
JPDL specifies an xml schema and the mechanism to package all the process definition related files into a process archive(存档).
13.1. The process archive
A process archive is a zip file. The central file in the process archive is processdefinition.xml. The main information in that file is the process graph. The processdefinition.xml also contains information about actions and tasks. A process archive can also contain other process related files such as classes, ui-forms for tasks, ...
13.1.1. Deploying a process archive
Deploying process archives can be done in 3 ways: with the process designer tool, with an ant task or programatically.
三种部v方式Q?BR> a.程设计工具
b.antd处理
c.E序
Deploying a process archive with the designer tool is still under construction.
Deploying a process archive with an ant task can be done as follows:
<target name="deploy.par">
<taskdef name="deploypar" classname="org.jbpm.jpdl.par.ProcessArchiveDeployerTask">
<classpath --make sure the jbpm-[version].jar is in this classpath--/>
</taskdef>
<deploypar par="build/myprocess.par" />
</target>
To deploy more process archives at once, use the nested fileset elements. The file attribute itself is optional. Other attributes of the ant task are:
cfg:
cfg is optional, the default value is 'hibernate.cfg.xml'. The hibernate configuration file that contains the jdbc connection properties to the database and the mapping files.
properties:
properties is optional and overwrites *all* hibernate properties as found in the hibernate.cfg.xml
createschema:
if set to true, the jbpm database schema is created before the processes get deployed.
Process archives can also be deployed programmatically with the class org.jbpm.jpdl.par.ProcessArchiveDeployer
13.1.2. Process versioning
Process definitions should never change because it is extremely difficult (if not, impossible) to predict(预知) all possible side effects of process definition changes.
To get around this problem, jBPM has a sophicticated process versioning mechanism. The versioning mechanism allows multiple process definitions of the same name to coexist(共存) in the database. A process instance can be started in the latest version available at that time and it will keep on executing in that same process definition for its complete lifetime. When a newer version is deployed, newly created instances will be started in the newest version, while older process instances keep on executing in the older process defintions.
Process definitions are a combination of a declaratively specified process graph and optionally, a set of related java classes. The java classes can be made available to the jBPM runtime environment in 2 ways : by making sure these classes are visible to the jBPM classloader. This usually means that you can put your delegation classes in a .jar file next to the jbpm-[version].jar. The java classes can also be included in the process archive. When you include your delegation classes in the process archive (and they are not visible to the jbpm classloader), jBPM will also apply versioning on these classes. More information about process classloading can be found in Section 13.2, “Delegation?
When a process archive gets deployed, it creates a process definition in the jBPM database. Process definitions can be versioned on the basis of the process definition name. When a named process archive gets deployed, the deployer will assign a version number. To assign this number, the deployer will look up the highest version number for process definitions with the same name and adds 1. Unnamed process definitions will always have version number -1.
]]>
1. Overview
A process definition represents a formal specification of a business process and is based on a directed graph. The graph is composed of (be composed of ?..l成) nodes and transitions. Every node in the graph is of a specific(明确? type. The type of the node defines the runtime behaviour.(q个cd定义了运行时间行为? A process definition has exactly(正确? one start state.
A token is one path of execution.(token是一个执行\? A token is the runtime concept that maintains(l护) a pointer to a node in the graph.
A process instance is one execution of a process definition. When a process instance is created, a token is created for the main path of execution. This token is called the root token of the process instance and it is positioned in the start state of the process definition.
A signal(信号) instructs(通知) a token to continue graph execution. When receiving an unnamed signal, the token will leave its current node over the default leaving transition. When a transition-name is specified in the signal, the token will leave its node over the specified transition. A signal given to the process instance is delegated to the root token.
After the token has entered a node, the node is executed. Nodes themselves are responsible for the continuation of the graph execution. Continuation of graph execution is done by making the token leave the node. Each node type can implement a different behaviour for the continuation of the graph execution. A node that does not propagate execution will behave as a state.
Actions are pieces of java code that are executed upon events in the process execution. The graph is an important instrument(工具) in the communication about software requirements. But the graph is just one view (projection) of the software being produced. It hides many technical details. Actions are a mechanism to add technical details outside of the graphical representation. Once the graph is put in place(在适当的位|?, it can be decorated(装饰) with actions. The main event types are entering a node, leaving a node and taking a transition.
程定义(process definition)
转变(transition)
节点(node) 节点-->>cd-->>q行旉行ؓ(f)
记号(token) 执行路径 --->节点
程实例(process instance) 一个流E定义的一个执?BR>信号(signal) 通知程l箋q行
行ؓ(f)(action) 在流E执行事件之上的javaq行代码
2.Process graph
The basis of a process definition is a graph that is made up of nodes and transitions. That information is expressed in an xml file called processdefinition.xml. Each node has a type like e.g. state, decision, fork, join,... Each node has a set of leaving transitions. A name can be given to the transitions that leave a node in order to make them distinct. For example: The following diagram shows a process graph of the jBAY auction process.
Below is the process graph of the jBAY auction process represented as xml:
<process-definition>
<start-state>
<transition to="auction" /> auction(拍卖)
</start-state>
<state name="auction"> 状态有两种转变 一U是转向salefork 一U是转向end
<transition name="auction ends" to="salefork" />
<transition name="cancel" to="end" />
</state>
<fork name="salefork"> 分支
<transition name="shipping" to="send item" /> q?BR> <transition name="billing" to="receive money" /> 开出帐?BR> </fork>
<state name="send item">
<transition to="receive item" />
</state>
<state name="receive item">
<transition to="salejoin" />
</state>
<state name="receive money">
<transition to="send money" />
</state>
<state name="send money">
<transition to="salejoin" />
</state>
<join name="salejoin">
<transition to="end" />
</join>
<end-state name="end" />
</process-definition>
3. Actions
Actions are pieces of java code that are executed upon events in the process execution. The graph is an important instrument in the communication about software requirements. But the graph is just one view (projection) of the software being produced. It hides many technical details. Actions are a mechanism to add technical details outside of the graphical representation.[行ؓ(f)是一U在囑Ş表现之外加入技术细节的机制 ] Once the graph is put in place, it can be decorated with actions. This means that java code can be associated with the graph without changing the structure of the graph. The main event types are entering a node, leaving a node and taking a transition.
Let's look at an example. Suppose we want to do a database update on a given transition. The database update is technically vital(重大? but it is not important to the business analyst.
A database update action
public class RemoveEmployeeUpdate implements ActionHandler {
public void execute(ExecutionContext ctx) throws Exception {
// get the fired employee from the process variables.
String firedEmployee = (String) ctx.getContextInstance().getVariable("fired employee");
// by taking the same database connection as used for the jbpm updates, we
// reuse the jbpm transaction for our database update.
Connection connection = ctx.getProcessInstance().getJbpmSession().getSession().getConnection();
Statement statement = connection.createStatement("DELETE FROM EMPLOYEE WHERE ...");
statement.execute();
statement.close();
}
}
<process-definition name="yearly evaluation">
...
<state name="fire employee">
<transition to="collect badge">
<action class="com.nomercy.hr.RemoveEmployeeUpdate" />
</transition>
</state>
<state name="collect badge">
...
</process-definition>
Actions can be given a name. Named actions can be referenced from other locations where actions can be specified. Named actions can also be put as child elements in the process definition.
This feature is interesting if you want to limit duplication(复制) of action configurations (e.g. when the action has complicated{复杂?难解的} configurations). Another use case is execution or scheduling of runtime actions.
Events
Events specify moments() in the execution of the process[事g指定了在程执行中的片刻]. The jBPM engine will fire events during graph execution[jBPM引擎在图表执行时候将ȀzM件]. This occurs when jbpm calculats the next state (read: processing a signal)[q个集中在当jbpm打算下一个状?读：(x)传递一个信?]. An event is always relative to an element in the process definition like e.g. the process definition, a node or a transition[一个事件L与流E定义中一个元素相关的,例如程定义、节Ҏ(gu)者{变]. Most process elements can fire different types of events[大部分流E元素蚕ȀzM同类型的事g]. A node for example can fire a node-enter event and a node-leave event. Events are the hooks for actions[事g是行为的挂钩]. Each event has a list of actions[每一个事件有一个行为的列表]. When the jBPM engine fires an event, the list of actions is executed[当jBpm 引擎ȀzM个事Ӟ行ؓ(f)列表被执行].
Event propagation 旉传播
Superstates create a parent-child relation in the elements of a process definition. Nodes and transitions contained in a superstate have that superstate as a parent. Top level elements have the process definition as a parent. The process definition does not have a parent. When an event is fired, the event will be propagated up the parent hierarchy. This allows e.g. to capture all transition events in a process and associate(交往) actions with these events in a centralized(集中? location.
Script Q脚本）
A script is an action that executes a beanshell script[脚本是执行beanshell脚本的一个行为]. For more information about beanshell, see the beanshell website. By default, all process variables are available in the script[默认的，所有过E变量在脚本中都是可用的]. After the script is executed, variable values of the script interpreter(解释? can be stored (or created) in the process variables[在脚本执行之后，脚本解释器的变量值可以被存储Q创建）在过E变量中]. For example:
<process-definition>
<event type="process-end"> //q程l束 事gcd
<script>
<expression>
a = b + c;
</expression>
<out variable='a' />
</script>
</event>
...
</process-definition>
The previous script will load all process variables in the interpreter. Then the expression is evaluated(?..的?, which requires that process variables b and c were present in the process variables when the script was executed. The out element specifies that the value of the scripting variable a has to be collected from the interpreter after the evaluation has completed and stored in the process variables (as variable a). When loading all the process variables into the interpreter or when there are variables that are not valid scripting variable names, you can specify the in variables analogue(cM情况) to the out variables.
Custom events[定制事g]
Note that it's possible to fire your own custom events at will during the execution of a process[注意在进E的执行中激zM的定制的事g是有可能的]. Events are uniquely(独特? defined by the combination(联合) of a graph element (nodes, transitions, process definitions and superstates are graph elements). In actions, in your own custom node implementations, or even outside the execution of a process instance, you can call the GraphElement.fireEvent(String eventType, ExecutionContext executionContext);. The names of the event types can be chosen freely.
GraphElement.fireEvent(String eventType,ExecutionContext executionContext)
Superstates(状?
A Superstate is a group of nodes[状态是一l节点]. Superstates can be nested recursively[状态可以被递归嵌套]. Superstates can be used to bring some hierarchy in the process definition[状态可以在q行定义中被用来产生层次]. For example, one application could be to group all the nodes of a process in phases(阶段). Actions can be associated with superstate events. A consequence(l果) is that a token can be in multiple nested nodes at a given time. This can be convenient to check wether a process execution is e.g. in the start-up phase. In the jBPM model, you are free to group any set of nodes in a superstate.
7.4.1. Superstate transitions
All transitions leaving a superstate can be taken by tokens in nodes contained within the super state. Transitions can also arrive in superstates. In that case, the token will be redirected to the first node in the superstate. Nodes from outside the superstate can have transitions directly to nodes inside the superstate. Also, the other way round, nodes within superstates can have transitions to nodes outside the superstate or to the superstate itself. Superstates also can have self references.
7.4.2. Superstate events
There are 2 events unique to superstates: superstate-enter and superstate-leave. These events will be fired no matter over which transitions the node is entered or left respectively. As long as a token takes transitions within the superstate, these events are not fired.
Note that we have created separate event types for states and superstates. This is to make it easy to distinct between superstate events and node events that are propagated from within the superstate.
Exception handling
The exception handling mechanism of jBPM only applies to java exceptions. Graph execution on itself cannot result in problems. It is only the execution of delegation(代理) classes that can lead to exceptions.
On process-definitions, nodes and transitions, a list of exception-handlers can be specified. Each exception-handler has a list of actions(每一个异常处?nbsp; 一批行?. When an exception occurs in a delegation class, the process element parent hierarchy is serached for an appropriate exception-handler. When it is found, the actions of the exception-handler are executed.
Note that the exception handling mechanism of jBPM is not completely similar to the java exception handling. In java, a caught exception can have an influence(改变) on the control flow. In the case of jBPM, control flow cannot be changed by the jBPM exception handling mechanism. The exception is either caught or uncaught. Uncaught exceptions are thrown to the client (e.g. the client that called the token.signal()) or the exception is caught by a jBPM exception-handler. For caught exceptions, the graph execution continues as if no exception has occurred.
Note that in an action that handles an exception, it is possible to put the token in an arbitrary node in the graph with Token.setNode(Node node).
7.6. Process composition
Process composition is supported in jBPM by means of the process-state. The process state is a state that is associated with another process definition. When graph execution arrives in the process state, a new process instance of the sub-process is created and it is associated with the path of execution that arrived in the process state. The path of execution of the super process will wait till the sub process instance has ended. When the sub process instance ends, the path of execution of the super process will leave the process state and continue graph execution in the super process.
When a subprocess is started, start-variables allow feeding of data from the super process into the sub process. Two variable names can be specified for each start-variable : the super process variable name and the sub process variable name. When the sub process is created, the value of the super process variable is copied in the sub process variable. The reverse is done with end-variable's. End variables allow collection of the results of the sub process into the super process.
]]>
1.Hello World 例子Q?BR>主要展示?BR>Q?Q从XML String 形式中获?ProcessDefinition
Q?Q构造实例化ProcessInstance
Q?Q获得o(h)牌token
Q?Q用signal()用法
其中QJpdlXmlReader.parse(String str)
parses a process definition from a string. replaces single quotes with double quotes before parsing the xml.
从XML中解析一个流E定义。在解析先，用双引号代码单引受?BR>2.数据库例子：(x)
jbpm的一个基本特征就是：(x)当它们在{待状态中Q有能力在数据库中持久化程的执行?BR>主要展示Q?BR>Q?Q获得JBpmSessionFactory static 对象
Q?Q创建数据库schema
jBpmSessionFactory.getJbmpSchema().createSchema();
Q?Q获得创建JbpmSession
Q?Q引入GraphSession?nbsp; are the graph related database operations.
Q?Q根据流E名获得最q的ProcessDefinition
ProcessDefinition processDefition = jbpmSession.getGraphSession.findLatestedProcessDefinition("hello world");
3.传递变?上下文例?
主要展示Q?BR>Q?QContextInstance 为流E实例维护所有的key-variable寏V?BR>ContexrInstance contextInstance = processInstance.getContextInstance();
Q?Q赋g获得|Map机制
contextInstance.setVariable("amout",new Integer(500));
contextInstance.getVariable("amout");
4.d委派例子Q?BR>主要展示Q?BR>Q１QProcessInstance .getTaskMgmtInstance() 为管理Q务和行ؓ(f)Q传递实例扩展?BR>Q２QQ务实例 TaskInstance
TaskInstance taskInstance = (TaskInstance)processInstance.getTaskMgmtInstance().getTaskInstances().iterator.next();
Q３QtaskInstance对用有actId
5.定制行ؓ(f)例子Q?BR>主要展示Q?BR>Q１Qactions是绑定特定java代码到jBpm程的一U机制。actions可以被用来连接它自己的节炏Vactions可以替代事gQ{变、进入、离开一个节点）?BR>Q２QactionHanlder 要实现ActionHandler接口?ActionHandler接口定义了一个方法execute(ExecutionContext executionContext) ?BR>
]]>