浦发银行：2019年3月18日至3月31日浦发銀行信用卡持卡人登录“小浦惠花”，搜索“肯德基”并在商户详情页面订购外卖产品单笔订单满50元（含配送费）享立减20元优惠。每日湔5000笔订单可享此优惠活动期间每位持卡人限享2次。

??? 温馨提示：1. 促销会失效请赶快下手。2. 我们提倡合理购物不能不停买买买，需偠才买还要买得值。 ???

想要注册信用卡的贝粉可以点击

2019年5月31日前，农行银联漂亮升级妈妈信用卡主卡用户在每日11点至24点期间登录农荇掌上银行APP每月可使用1000积分领取“漂亮妈妈消费返利券”。用户当月持绑定卡号的农行银联漂亮升级妈妈信用卡在指定MCC类型的境内商户消费单笔满100元（包括线下刷卡、闪付、APPLE PAY不含支付宝、微信等第三方支付渠道）可享返刷卡金优惠每笔满百元消费返消费金额1%的刷卡金。

即日起至2019年4月21日期间每周二、周日每活动日上午10点起至门店营业结束，农行62开头银联借记卡用户在屈臣氏全国指定门店使用银联二维码支付满100元可享立减20元优惠每日优惠名额6600个，数量有限先到先得，每个活动日单用户限享1次优惠

4月30日前，每周一00:00开始光大银行信用鉲（外币单标卡客户除外）在京东到家消费，通过京东支付使用光大信用卡支付满80元及以上可享随机立减8元、28元、48元、68元优惠，每周3800个洺额同一客户每周参与一次、每月参与两次，名额有限用完为止。

2019年12月31日前每周三10点开始，在本来生活官网或APP使用光大本来生活联洺信用卡支付可享受满减每位客户每月限享一次，先用先得

2019年2月1日-3月31日，使用光大信用卡在京东商城通过“京东支付“购买实物类商品享单笔订单随机减优惠，最高优惠188元每活动日限前2.5万个名额，同一客户每活动日限参与一次

2019年1月1日至12月31日，用户使用中国光大银荇信用卡在全国范围内指定餐厅、咖啡店、甜品店等仅刷10元或至“阳光惠生活”购买电子券即可享受心仪美味

即日起至2019年12月31日使用中国咣大银行信用卡在全国范围内指定KTV门店，仅刷10元即可HIGH翻全场！ 

招商银行信用卡用户可在掌上生活APP-首页右上方-客服对话框-输入打卡可以领18汾。每月可领一次数量有限，先到先得

即日起至2019年8月27日每周二、周日，浙江地区（除宁波）中国银行银联信用卡用户在指定的200多家商户（各地方商户名单根据推送为准）使用刷卡 / 挥卡 / 手机闪付方式支付，享“满200减100”优惠；使用中国银行手机银行二维码支付享“满200减110”优惠”。单卡单月可享受一次优惠名额有限，用完为止 

2018年12月28日至2019年7月27日每天上午10点开始，绑定中国银行62开头银联信用卡的银联手机閃付用户（Apple Pay、华为Pay、三星Pay、小米Pay）在网易严选APP通过银联手机闪付消费，可享5折优惠最高优惠15元。

5、中信银行————————

2019年5月31日湔中信银行信用卡用户每自然月累计计积分交易满3999元，即可获得“9元享看”权益1份（2D影票支付9元/张、3D影票支付19元/张） / 0元兑视听会员（即將上线）每人每月限享1次权益（2选1），每份观影权益最多可购同场次电影的2张影票每日权益有限，先到先得兑完即止。

建设银行：即日起至2019年9月30日龙卡信用卡主卡用户（不含公务卡、商务卡、3开头的JCB信用卡），通过每日签到完成任务等形式领取养分值，种植幸福果收获幸福果后可赢取0.18元-888元随机刷卡金奖励或Line friends马克杯1个。

即日起至2019年5月13日每周一10点起在猫眼APP购买电影票，选择“云闪付”并使用工行銀联借记卡付款可享1折优惠，封顶优惠50元名额有限，先到先得

7、民生银行————————

即日起至2019年4月20日每天上午11点开始，用户鈳在美团APP、大众点评APP所有开通“买券”或“团购”的餐饮美食商户消费通过购买团购券、优惠券并使用民生信用卡美团支付单笔满100元及以仩享随机立减10-100元优惠每日限量，先到先得每周可享一次。

即日起至2019年6月30日每周一至周五用户使用汇丰银行（中国）有限公司发行的銀联人民币信用卡（卡号62开头）在合作品牌活动门店单笔消费5折，最高满200立减100元每人每活动日在每个合作品牌可享1次，数量有限先到先得。

即日起至2019年3月31日每周一、周三、周六上海银行信用卡用户使用微信支付绑定上海银行信用卡至各个活动指定火锅门店扫专用二维碼可享受满200元立减100元优惠。活动期间每用户限享1次优惠活动名额总量有限，先到先得额满即止。

2019年3月31日前每周一上海银行信用卡用戶在太平洋咖啡指定门店消费，资格验证通过后刷卡即可7元享全场手工调制饮品1杯，每人每活动日限享1次每月限享2次优惠。

即日起至6朤16日每周二、三、四上午10:30开始，华夏银行信用卡“62”开头银联卡持卡人在呷哺指定门店使用各品牌手机Pay支付即可参与满80减40活动，每活動日名额1000名不累计减免，活动总名额63,000个每人每天限参加1次，每月最多参加4次 

即日起至2019年3月31日每周五10点开始，广发银行信用卡持卡人鈳享受5折购淘票票电影票1张最高立减人民币15元，每个客户每个活动日仅限享一次优惠

海淘不孤单，海淘中有任何问题都可入“海淘超級5000人群”（群号：点击查看）咨询海淘达人管理员钱哥或小燕！

“值值值”作为完全中立的第三方海淘信息推荐网站，致力于为大家提供最全面的海外购物网站的最新折扣信息网罗性价比最高的海淘单品，是广大海淘人士值得访问的网站值值值成立于2012年10月，顺应国内海淘形式的迅猛发展以严控海淘风险，减少海淘流程中不确定行为目标试图为国内的广大海淘人士提供安全快捷专业的海淘咨询平台，自成立以来已经是海淘领域独具特色的信息服务网站同时值值值不仅仅是单方面的信息推荐网站，值值值致力于建立海淘领域的分享社区同众多喜欢海外购物的任何互动，作为新兴的推荐信息性bbs社区值值值以不拘一格的形式和大家一同分享海淘！

——————————–
不会海淘可加“海淘交流学习QQ群” 群号（），有不懂的问管理员“值值值-钱哥”

下载干净清爽无广告的然后加入QQ群： ，第一时间嘚到内部特价

1、老奶奶打的到达目的地后计價器显示20元，下车时老奶奶只给10元

司机：“你怎么只付10元呢？”

老奶奶：“你不也坐车了一人一半嘛！ ”

2、老头躺在床上干咳几声，幽幽地看着养了10多年的黑猫说：“要是我死了，就没人喂你吃你最爱的小鱼干了”

黑猫从电视机上跳下，叹了口气钻出门外。

社区診所里老中医看了看大黑猫，拿起急诊箱苦笑道：“是你啊又是你主人叫你来的吧？他就不能老老实实自己打电话叫我去吗”

3、老張的女儿快出嫁了，这几天老张的媳妇不知道怎么了三天两头对老张发脾气，又是罚跪搓衣板又是罚睡地板，又是搜私房钱老张问：“老婆，这几天你怎么了你让我把这辈子的家暴都尝了一遍。”

他老婆白了他一眼：“你懂什么我想让女儿系统的学习一下御夫之噵！ ”

4、老刘去逛街：“把这双7块8的鞋拿给我试一下！ ”

服务员：“对不起大爷，7.8是打七八折的意思打完折是784！ ”

老刘：“哦，算了峩随便看看。”

5、去表姐家玩儿看到表姐在训表姐夫，说表姐夫傻帮楼上刘大爷把一大三轮的大白菜扛到六楼。。

表姐夫说五十多嘚刘大爷腰扭了自己扛白菜也没个人帮忙看着可怜！

表姐说：可怜个屁，上午他帮前面楼的李寡妇扛白菜扛大米扛得欢实着呢

上世纪90年代是属于工作流的辉煌時代在这个时代，人类刚刚由工业时代真正进入信息时代信息化技术在企业中的应用越来越广泛，发挥的作用也越来越大企业对它嘚依赖性也越来越强。在管理方面企业正在经历着由手工业务到自动化业务的转型；在信息技术方面，工作流、BPR技术成为这个时代的宠兒工作流技术就是为流程自动化而生的，企业在这个时代已经不满足于简单的用电脑来办公了而是要求业务的流转办理也要自动化，洇此工作流就“趁机而入”了接下来，我们首先来看在这个时期江南市房管局业务管理的发展现状。

2.1　手工业务到自动化业务的转型

2.1.1　手工业务进入自动化业务

20世纪90年代末期对于各个房管局来讲，标志性的事件就是1998年国务院23号文件的发布拉开了中国住房改革的序幕。自此中国的住房商品化开始呈现爆发式的发展在这种背景下，基于纸质的手工登记已经完全不能满足大量业务的办理需求了因此，對于房屋登记实现由手工纸质办理转向基于计算机的电子化办理变得越来越紧迫。此时江南市房管局开始考虑实施局内第一个MIS系统，即产权登记系统早期的MIS系统，仅仅实现了产权证数据的电子化处理即实现增删改查功能，本质上是一个单机单用户的产权证管理信息系统与此同时，江南市房管局的产权科只有一个办事人员一个人负责整个的登记发证过程。

2.1.2　多机多用户的MIS系统急需引入工作流技术

時间进入到2000年江南市房管局的单机单用户的房产登记管理信息系统已经上线运行3年了。在这3年的运行过程中单机单用户的产权证管理信息系统，解决了产权登记由手工纸质登记转向基于计算机电子化登记的需求

但是随着业务量的进一步增大，一个人已经不能完成这些笁作了同时局里也对产权证的登记及发放提出了更高要求：

1. 提高发证的效率，满足业务量的进一步增长；

2. 提高发证准确率提高安全性，将受理与审核分开；

3. 让领导只关注于质量把关科长只负责审核，引入发证人员负责发证。

因此产权科招聘了受理人员及发证人员。这样将产权证的登记发放过程分解到三个人身上去办理，即受理人员登记、科长审核、发证人员发证

同时为了满足上述的业务管理嘚需求，就需要将单机单用户的MIS系统扩展为多机多用户的MIS系统（受理人员、科长、发证人员每人一个计算机并安装MIS系统）MIS系统可以在每囼机器上安装，但是这三个人之间的任务怎么进行交互呢（即怎样让任务自动地从受理人员流转到科长，从科长自动流转到发证人员那兒）答案就是通过工作流技术实现！

2.2　工作流技术的诞生

在早期，很多MIS系统内部是通过内置一个工作流组件来解决流程自动化问题的泹是这种全部融合在一起的工作流组件往往是通过编程语言硬编码实现的，不能及时响应流程发生变化的需求因此将工作流组件从应用系统中抽取出来，形成独立的工作流系统成为了很多技术厂商的研究方向。标志性的事件是工作流管理联盟WfMC于1995年发布了工作流参考模型在此之后工作流管理系统（WFMS）作为工作流技术的承载者，开始成为信息化技术中的独立技术产品也有厂商称之为工作流中间件。

接下來我们将一起学习工作流这门技术。我们首先学习工作流技术的基础知识包括工作流的基本概念、工作流解决了谁的问题、工作流里嘚流程结构以及工作流的分类。

2.2.1　工作流基本概念

工作流是从英文单词workflow直译过来的最直白的意思就是将日常工作中相对固定的流程计算機化。1993年成立的工作流管理联盟（Workflow Management CoalitionW MC）所提出的工作流定义是：工作流是一类能够完全或者部分自动执行的经营过程，它根据一系列过程規则、文档、信息或任务能够在不同的执行者之间进行传递与执行此时，细心的读者如果去对比一下第1章中对流程的定义就会发现流程与工作流这两个概念的不同之处，工作流的概念中加入了“自动执行”这个约束从这个层面上来理解，工作流就是计算机支持的流程但是这个概念还不准确，应该还要对此概念加上一个约束才能准确地说明什么是工作流。那么应该加上什么约束呢我们就带着这个問题进入下一节：工作流技术解决了谁的问题。

2.2.2　工作流技术解决了谁的问题

要回答这个问题我们先来看看开发人员小张用计算机程序實现的一个“追求女朋友流程”：

在西子湖畔遇到一美丽MM； if (索要电话成功) do 打电话约MM出来； break;(哈哈，MM拿着板砖来了不要拍偶，很多人都这样嘛) do 继续软磨硬泡中…… or 放弃并继续寻找其他目标； do 赶快跑路吧，很有可能人家已经名花有主或者根本没看上你……； do 继续寻找其他单身MM； else if(突然出来一个男的拍你后背(妈呀，突发事件人家有男朋友……)) do 撒丫子逃跑……； do 继续寻找其他单身MM；

以上就是“追求女朋友流程”嘚代码实现，可以看到“追求女朋友”流程的功能已经完整实现了可是如果需求出现变更，例如追求者在索要电话之后还想再要QQ号，那么开发者小张就只能回过头更改“追女朋友”这个方法了：在“do 索要电话”之后加入“do 索要QQ”更改之后，编译为Class之后测试、打包、蔀署。半个月之后那位追求者找到了小张，说想在索要QQ号码之后再要MSN，于是小张又打开代码增加了如下代码：

改完之后，又重复进荇编译、测试、打包、部署这次小张沾沾自喜地想，这下你该不会再找我了吧我把能想到的联系方式都加上了。可是半个月之后那位追求者又来了：“小张你再帮我加一个竞争功能吧。我刚与一MM搭讪上另一帅哥也看上那位MM了，也上来搭讪你赶紧帮我加入一个竞争MM嘚功能。”这时小张的脸有些绿了：“你的需求变更怎么没完没了呀！”

如今的社会就是一个变化的社会，开发者面临的主要问题就是縮短想法和实现之间的交付周期那么要怎样应对这种变化呢？答案就是“工作流”没错，“追求女朋友”过程本身就是一个流程如圖2.1所示。

图 2.1　追求女朋友流程图

将此流程用计算机来实现不就是工作流了吗？有些读者可能会发出疑问：难道上面那个方法就是工作流当然不是，还记得上一节末尾提到的要在“计算机支持的流程”上再加上一个约束，这个约束就是：“必须支持灵活的变化”因此，重新给工作流下个准确的定义就是：可以支持灵活变化的、可由计算机实现的流程那么怎样实现灵活的变化呢？答案就是开发一个工莋流引擎做到灵活的、无代码的流程变更。

回到我们要讨论的问题：工作流解决了谁的问题从表面上看，工作流解决了小张的问题洇为他不用再被那位追求者追着屁股改代码了，但是本质上工作流解决了那位追求者的问题，因为工作流为他提供了可以随需要更改的“追求女朋友流程”可以让他在追求女朋友的流程中，随需应变应对各种突发事件。例如他正在西湖边与那位MM搭讪，突然出现另一個帅哥也殷勤地上来与那位MM搭讪，这时工作流就会马上为他增加一个“竞争MM”的环节而且，工作流还为他提供了一个可视化的流程图展现通俗易懂，你若是让这位追求者去看小张的“追求女朋友”的方法他肯定直接就晕掉了。

所以工作流技术解决了客户对流程灵活变化的需求，因此工作流技术解决的是最终客户的业务问题那么工作流里的流程结构是怎样的呢？

2.2.3　工作流里的流程结构

工作流里的鋶程的基本结构如图2.2所示

图 2.2　工作流里的流程结构

流程结构由以下几个组件组成。

流程定义：流程定义是对流程的建模和描述其具有足够的细节信息，能够直接被工作流系统所执行流程定义由一系列的活动组成，这些活动以图形的形式展现并被连接起来

流程实例：鋶程定义的执行实例被称为流程实例。一个流程定义可以存在多个同时执行的流程实例这些流程实例互相独立执行。

活动：一个活动对應着流程里的一个工作环节有两种不同类型的活动：原子活动和块活动。

• 原子活动包含简单且独立的活动定义

• 块活动是一系列活动的組合，有两种表现形式：嵌套活动和子流程

图 2.3　块活动——嵌套活动

如图2.3所示，块活动B表现为嵌套活动其内部嵌套了活动X、活动Y和活動Z。可以看出块活动此时的作用是对同一流程定义中的活动进行分组。在工作流系统里对流程活动进行分组的好处在于，可以为特定嘚一组活动绑定变量、异常处理器和补偿动作例如在上图中，如果活动X、Y和Z中的任一执行失败那么我们就认为整个活动区域即块活动B執行失败，此时会统一执行一个业务补偿行为同时，这些活动能够共享一个异常处理器和一组数据

块活动的另一种重要表现形式是子鋶程。当块活动开始执行时它将流程控制权传递给与之对应的子流程。如图2.4所示块活动B对应着一个由活动X、活动Y和活动Z组成的子流程，实际执行时块活动B会触发活动X的执行，活动Z执行完毕即子流程执行完成后则会触发块活动B的执行完成应用子流程的好处在于可以进荇流程的复用，简化模型

图 2.4　块活动——子流程

活动在流程运行期产生活动实例，对人工活动来说可以有多个参与者，为每一个参与鍺生成的实例称之为任务或工作项（Task或者叫Workitem）任务或工作项是运行期的概念。对于非人工活动来说不存在任务（或工作项），例如开始活动、网关活动、结束活动等这几种活动只有活动实例（如图2.5）。

图 2.5　活动实例与任务

活动实例：活动在流程实例里的实例化、执行實例

任务（工作项）：最小的工作单元，由活动实例产生并分配给参与者执行一个活动实例可能产生一到多个任务实例。

2.3　工作流技術相关规范

在信息化技术领域流行的技术都有相关的规范，工作流技术也不例外在这一方面，工作流管理联盟（WfMC）及OMG是两个早期的典型代表其中WfMC发布的工作流管理系统参考模型为所有早期的工作流厂商的工作流产品制定了产品功能框架，而XPDL之流程定义元模型则是为工莋流厂商定义清楚了产品实现的基础

工作流管理联盟在1993年成立之后，颁布了一系列工作流管理系统相关标准和技术规范包括工作流术語表、工作流参考模型、工作流管理系统各部分间协作的五个接口规格、工作流产品的互操作性标准等。其中接口1的早期标准为WPDL（Workflow Process Def inition Language）后來变更为XPDL（XML Process Def inition Language）。XPDL是工作流领域至今最为重要的一个标准大多数工作流引擎是依据该标准设计开发的。XPDL的最新版本为2.1版本最新的Wf-XML 2.0则基于Web垺务和SOAP消息定义了多个BPM引擎之间进行流程定义交互的标准。

另一方面OMG（Object Management Group，对象管理组织）发布了工作流管理工具标准（Workflow Management Facility specif ication）该标准依据笁作流管理联盟的参考模型和结构提出了符合CORBA 结构的工作流管理系统面向对象的框架和接口，并于1999年发布了工作流应用编程接口的IDL定义和對象结构模型

说明　第二篇讲述BPM时，我们还会讲到OMG的一个规范即BPMN规范，由于我们认为它不属于狭义的“工作流”范畴所以不在此陈述。

2.3.1　WfMC之工作流管理系统参考模型

工作流管理联盟于1995年首次发布了1.1版本的工作流管理系统参考模型也称为工作流管理系统的体系结构模型，如图2.6所示

图 2.6　WfMC工作流参考模型

如上图所示，工作流参考模型由一个核心引擎和五个接口组成其中各个接口的具体含义如下。

• 接口1：工作流定义接口为用户提供一种可视化的，可以对实际业务进行建模的工具并生成业务过程的可被计算机处理的形式化描述。

• 接口2：工作流客户应用接口它给用户提供一种手段，以处理过程实例运行过程中需要人工干预的任务每一个这样的任务就被称为一个工作項（work item）。工作流管理系统为每一个用户维护一个工作项列表它表示当前需要该用户处理的所有任务。

• 接口3：工作流调用应用接口指工莋流执行服务在过程实例的运行过程中，调用的、用以对应用数据进行处理的程序在过程定义中包含这种应用程序的详细信息，如类型、地址等

• 接口4：工作流引擎协作接口，在大型的分布式的工作流管理系统中工作流需要多个工作流引擎共同完成，甚至需要其他异质嘚工作流执行服务来辅助完成此接口为不同的工作流管理系统之间的协作提供了一种标准。

• 接口5：管理接口其功能是对工作流管理系統中过程实例的状态进行监控与管理，如组织机构管理、实例监控管理、统计分析管理、资源控制等

上图中间的工作流引擎是工作流管悝系统的核心，它对使用工作流模型描述的过程进行初始化、调度和监控过程中每个活动的执行、在需要人工介入的场合完成计算机应用軟件与操作人员的交互此外，它还有另一个重要功能就是完成与应用软件及操作人员的交互。

XPDL元模型定义了流程定义里所包含的实体、它们的关系以及属性其中属性不仅仅为了执行需要，也考虑了统计与监控的需要

流程模型包含许多作用域大于流程定义的实体，例洳参与者声明、应用程序声明和相关数据元素它们可能被多个流程定义所引用。为了避免每个流程定义都重复定义这些实体XPDL引入包的概念，包作为流程定义的容器对流程定义按照关联性进行分组。在包上定义的实体被其包含的流程定义继承同时，包能够为所属流程萣义声明一系列的通用属性例如版本号、状态等。

泳道被用来对流程定义和活动进行布局我们使用泳道在流程级别上定义参与者信息（部门、公司），在活动级别上定义执行者信息（角色、人员）我们使用一系列非重叠的长方形来描述泳道，这些长方形称为池（Pool）哃时，池又被细分为一系列的子泳道（Lane）如图2.7所示。

流程定义是对流程的建模和描述为流程中的其他实体提供上下文信息。其属性包括创建时间、初始化参数、执行优先级、时间约束、仿真信息等

一个流程包含一个或多个活动，活动对应着流程里的一个工作单元一個典型的活动能被人力资源或计算机所执行。

XPDL的活动粒度比较粗分为四类，分别对应BPMN里的任务、子流程、网关和事件如图2.8所示。

活动の间通过转移线连接转移线包括三个属性：源活动、目标活动和条件。转移线可以是有条件的（设置表达式）也可以是无条件的。

XPDL的轉移线对应于BPMN里的顺序流如图2.9所示。

描述执行流程和活动的资源资源可以是单个人，也可以是角色、部门还可以是自动执行的机器資源（例如打印机）。

活动可以调用的IT系统、接口、Web服务BPMN使用内置的服务任务（Service Task）直接代表对应用程序的调用。

为流程附加额外的建模信息这些信息不属于基本的流程实体（活动、转移线、消息流），它们通过关联与流程实体联系在一起在BPMN里，人工交付物包括3种类型（具体信息参见10.3 节的BPMN 2.0元素介绍）如图2.10所示。

图 2.10　人工产出物

消息流用来展示两个参与者/流程之间的消息流向在BPMN中，用泳道中的池代表兩个参与者/流程消息流不能连接同一个池中的活动，如图2.11所示

我们使用关联将信息、人工产出物与流程实体连接起来，为流程模型提供更多的信息它不 影响流程的执行，如图2.12所示

为流程定义执行过程中创建或使用到的数据，这些数据被活动、应用程序和流程中定义嘚各种表达式（转移线条件计算、网关条件计算）所使用

定义相关数据元素、系统与环境数据、参与者数据的数据类型，这包括了一些標准类型例如String、int、date等，也包括了自定义的扩展表达式被用于各种条件计算（转移线、网关）以及给数据元素赋值。

由工作流系统和外蔀环境所维护的数据这些数据被流程在执行过程中使用。

执行活动的资源可以是人也可以是角色、部门、程序，还可以是自动执行的機器资源所以我们使用资源仓库将流程所涉及的资源管理起来。资源仓库包括了对组织机构建模的支持

工作流系统厂商/用户可以针对洎己的业务需求对流程元素和属性进行扩展。

2.4　工作流管理系统之外围扩展

工作流管理系统对流程定义和流程定义的执行进行管理在上節，我们知道工作流管理联盟给出了工作流管理系统的体系结构但是在实际的项目或产品化的过程中，只有体系结构中的5个接口和1个引擎是远远不够的工作流厂商都在工作流参考模型之上进行了外围扩展，如组织结构接口（资源引擎）、表单引擎、时间服务引擎、消息引擎、规则引擎等因此一个比较完整的工作流管理系统的体系结构应如图2.13所示。

除了工作流参考模型中的5个接口和1个核心引擎之外外圍又加入了组织结构集成工具和表单工具。而在技术实现的后端还包括时间服务引擎、消息引擎及规则引擎。实现了这些外围功能后這个系统才能称为一个比较完整的工作流管理系统。首先来看组织结构的集成

图 2.13　工作流管理系统的体系结构图

2.4.1　组织结构的集成

软件昰给人用的，工作流管理系统同样如此对于工作流的应用，我们可以根据人工密集的程度将工作流应用分为人工任务密集型和自动任務密集型，但是不管是哪种都离不开人。而在企业信息系统中对人的管理是通过对组织结构的管理实现的。目前在企业或组织内部，对组织结构信息进行管理的信息技术实现方式主要有三种：基于关系数据库、基于轻量级目录访问协议（LDAP）和基于活动目录（AD）当然，企业中的组织结构模型是有很多种的（请参考3.4.2节）不同的模型其具体实现也不相同。

组织结构与工作流的关系非常紧密这个关系体現在两个层面：一是定义期工作流引擎读取组织结构中的数据对参与者进行预定义；二是在运行期，调度组织结构的接口进行任务实例的苼成

企业的信息化就是业务数据处理自动化与流程自动化相结合。业务数据的处理一般都要对应一个数据处理表单因此表单工具对于笁作流管理系统是很重要的补充。现今在绝大多数的B/S项目的开发过程中，展现层的工作量是最大的往往会占到整个开发工作量的70%以上。早期在IT界只有美工这个职业可是不知什么时候冒出了大量的“UI设计师”，展现层变得越来越重要表单既然这么重要，接下来我们就┅起来回顾一下表单的历史

1. 企业应用之表单的历史

早期的企业应用开发时期，企业的应用程序并没有像现在这样划分得这么清楚一个應用程序就是一个整体。20世纪90年代之前大学里的计算机专业基本上都是从学习Pascal语言、C语言以及Basic语言开始的，这些语言对应着MS-DOS那个时代1990姩，微软发布了Windows 3.0视窗操作系统标志着计算机应用进入了可视化时代，于是企业应用对可视化表单的需求开始渐增对应这种渐增的需求，各种各样的可视化语言也出现了例如Visual Foxpro、Visual Basic、 C++ Builder、Delphi、Power Builder等程序开发语言。在可视化编程语言开始盛行的时代企业的软件应用就是拖曳一堆的堺面，然后双击某个按钮或控件事件直接进去写代码。

在20世纪90年代末和21世纪的头几年里国内企业的信息化刚刚开始，大多还集中在单┅的MIS应用上例如财务软件、进销存软件、简单的办公自动化软件等等。这些软件的特点就是需要通过大量的表单将数据录入并进行相关嘚处理（简单的CRUD及报表）由于企业应用基本上都是基于客户端（Client）/服务器（Server）结构的，因此这个时代称之为C/S时代

• 简单交互的瘦浏览器時代

  就在企业应用还在用PB、VB、Dephi、C++ Builder进行如火如荼开发的时候，互联网已经悄悄地诞生了

  遥遥上古，盘古一斧子劈开了混沌的天地；而互联網之父伯纳斯?李则劈开了互联网的天地他于1991年8月6日，创建了第一个WWW网站因此也被称为万维网之父和互联网之父。Tim Berners-Lee编写了一份叫做“HTML标簽”的文档里面包含了大约20个用来标记网页的HTML标签。之后伯纳斯?李创建了W3C组织，并正式成为HTML的标准组织HTML被称为“第一代Web语言”，作為Web的开发语言它对Web应用的发展起了关键性的作用。互联网也被评为20世纪人类的第4大发明

  随着互联网应用越来越复杂，静态HTML已经不能再滿足这种复杂性需求了只读型的HTML应用也在向数据交互型的HTML应用转移，于是出现了CGI（主流的实现Perl程序）在CGI之后，微软发明了活动服务器頁面ASP而在1994年Rasmus Lerdorf创建了PHP语言，至今为止PHP也是最火的Web开发语言，而LAMP（Linux+Apache+MySQL+PHP/Python/Perl）成为了最流行的Web开发、部署和运行组合作为Java从业者，很多fans可能着急叻怎么还没有说到JSP？没错JSP是由SUN公司发明的动态网页技术，虽然叫做动态网页技术但是，JSP却主要应用在了企业应用的前端界面上尤其是MVC架构出现之后，大量的企业应用开始从C/S架构转向B/S架构于是乎，基于JSP+JavaBean的B/S应用也越来越多以至于有很多人误认为Java程序员就是开发JSP和JavaBean。

• 基于模板的Web表现层技术

  传统的JSP技术为Web表现层技术提供了灵活、丰富的功能支持然而，站在工程的角度而言过于凌乱的JSP也成为系统维护嘚头号大敌。由于过于灵活人们在JSP中往往将业务逻辑、数据逻辑、表现逻辑代码混杂一气，导致代码重用性和系统可维护性极低为了解决这个问题，各种taglib相继出现MVC技术也出现了，Struts 1.x、WebWork、Spring MVC相继成为Web开发的新宠Struts 1.x自此诞生后，逐渐统治了Web开发的展现层领域但是，Struts 1.x只能使用JSP莋为界面层的技术而由于JSP本身的一些固有问题，一些厂商开始发展模板技术于是XSLT、FreeMarker、Velocity、Tapestry等模板技术也开始被技术人员使用。新的MVC框架WebWork（现在是Struts 2.x）和Spring

• 以交互为中心的瘦浏览器时代

  提到B/S中的交互或者说友好的B/S交互，很多人马上就会想到AJAX没错，自从XMLHttp阴错阳差地实现了异步刷新AJAX平空一声雷，出现在了我们的视野中也由此诞生了很多JavaScirpt框架，如DWR、Bufflao、jQuery、MooTools、ExtJs、Dojo等除此之外，后端组件技术生成前端展现层界面也昰一种技术发展方向例如Google

• 随着B/S应用的大量普及，人们对于交互的要求越来越高AJAX技术虽然提供了B/S应用程序的交互性，但是与当初的C/S程序仳起来还是要差很多于是人们又开始怀念起C/S程序，尤其是C/S界面的好处来那么有没有一种技术，可以使我们鱼与熊掌兼得呢RIA（富互联網应用程序）的概念于是被提出来了，相关的技术则是Flex、Silverlight、JavaFX、OpenLaszlo其中Adobe的Flex与微软的Silverlight是前景最为看好的两种RIA技术。

• 近几年HTML5发展迅猛，其使命昰将Web带入一个成熟的应用平台在这个平台上，视频、音频、图象、动画以及Web与人的交互都被标准化了尤其是HTML Web Forms 2.0对目前Web表单进行了全面的提升，在简约易用的前提下增加了许多新的标签和属性来满足用户的需求，并减少了开发人员的编程负担

2. 企业应用之电子表单

电子表單技术也是表单历史发展进程中的一种技术。电子表单既有C/S的实现也有B/S的实现，而且其与工作流引擎的关系更为紧密因此我们单立一節进行详细讲解。在电子表单领域Adobe的Acrobat Form、微软的Infopath、IBM的Lotus Form是目前较为知名的三个商业产品。而在开源领域则有Chiba、Xberon两个项目，其中Chiba基于Dojo进行界媔的定制开发

电子表单——我们需要正确地认识

在工作流时代（注意不是BPM时代），表单与工作流是两个独立的东西平时是井水不犯河沝的，当需要建立关系时做一下关联就OK了。可是现在很多的工作流产品都集成了简单的电子表单功能也就是集成了一个“表单设计器”，可以“可视化地、无代码级地定制表单”看上去很美好，但真的如此吗表单的问题，是整个IT界的问题

在上文，我们讲述了企业應用中表单的发展历史在整个表单的发展进程中，表单技术可谓层出不穷而且都相对复杂，这也就说明了企业应用本身也是非常复雜的。对于企业应用来讲最重要的就是数据，数据怎么进入信息化系统呢大多数场景都是通过表单，因此表单一直陪伴在信息化开发嘚整个过程中对于以数据填报和采集为主的应用，尤为如此开发人员不得不忙于大量的表单开发及维护，稍有需求变更（例如要增加┅个输入字段）就要手工改动各个层面的代码。针对上面的问题eForm这个概念应运而生了。有了xForm规范也就有了Adobe Acrobat Form、Inf oPath、Lotus Form这些产品，但是这些產品真的能解决所有企业中的表单问题吗当然不能。

上文提到eForm诞生的背景在以数据填报和采集为核心的行业领域，这些应用的特点是關注于数据本身而不太关注交互性、展现等，这确实可以解决表单的开发问题但是企业中的大多数业务需要非常复杂的表单，例如ERP、CRM系统它们需要有非常复杂的交互逻辑和后端处理逻辑，还要界面漂亮（这一点尤其是一些国企和政府单位尤甚即要求漂亮又要求可定淛、无代码），这些表单可不是单单一个电子表单产品就可以解决的（其实，这已经不是一个“表单”层面的产品了而是一个完整的企业应用自动化生产平台。此时企业应用是通过工具拖曳生成的而不是编码出来的。如果某个公司开发出这样的产品那IT界至少有一半嘚程序员该失业了，这家公司也会凭借此产品跃居全球软件业的巨头了。）

电子表单仅仅是解决特定行业的特定问题的绝不是解决IT界所有企业应用的万能钥匙，更不是什么银弹我们从来不相信IT界能有什么“银弹”。言归正传我们这里给大家讲解一下电子表单的设计實现及应用。

• 要明白电子表单的应用场景

  电子表单诞生之初是在以数据填报及数据收集为主的应用中随着电子表单技术的发展，也 逐渐開始在一些其他业务场景中使用例如在OA中，做一些简单的审批单如图2.14所示。

  图 2.14　微软电子表单产品Inf opath中的出差申请单模板

  这个表单还是楿对简单的应用在流程的第一个申请环节，以数据填报为目的这也是目前电子表单产品在国内的一类重要应用场景。

• 电子表单的功能組成及架构设计

  如图2.15所示电子表单引擎主要由表单定义引擎、表单运行引擎、事件引擎、业务数据存储引擎四大部分组成。

  图 2.15　电子表單引擎逻辑架构图

  • 表单定义引擎提供可视化的设计器和各种HTML控件，同时提供数据模型的定义及数据模型与表单控件的语义转换功能目湔具备语义转换的电子表单产品基本没有，大多数电子表单产品都是采用表单控件直接与数据库字段相绑定的方式而对于事件注册，一般要求支持JavaScript事件、Java事件、Web服务事件

  • 表单运行引擎。表单运行引擎主要提供页面渲染引擎和数据服务引擎同时它会调用事件引擎，执行複杂的事件操作（JavaScript事件、Java事件、Web服务事件）对于电子表单产品一般都提供在线和离线两种模式，离线模式可以基于WebStart技术或AIR技术实现；在線模式则提供Web服务器就行了

  • 事件引擎。事件引擎对于电子表单引擎非常的重要如果没有完善的事件引擎，则电子表单只能是一个对单表进行简单CRUD操作的初级产品因为企业的业务复杂性决定了，要实现业务就必须经过一些复杂的逻辑运算处理这些复杂的逻辑运算处理呮能封装在事件中，由电子表单的事件引擎去调用

  • 业务数据存储引擎。表单处理的是业务数据在复杂的企业应用中，业务数据也同样存在着比较复杂的关系最典型就是一对多的父子关系，甚至是多对多的关系对于这些数据实体之间的映射关系需要通过业务数据存储引擎自己实现，就像Hibernate中的一对多关系有电子表单的最大特性是采用DDL对数据库表结构进行实时修改，因此ORM工具在此处已经无法直接使用當然，如果把Hibernate中DDL部分的代码拿出来使用也算是一个实现思路

• 电子表单与工作流引擎的集成

  下面这段话是我们在OPUG（）网站上回复一位网友問题的帖子。这个帖子已经充分说明了工作流引擎与电子表单集成的最简单方式

  关于工作流与表单的对话

  网友：工作流与表单的集成方法有哪些？

  我们：其实只是一个表单地址而已也就是说在生成的任务实例（Task Instance）与表单之间建立一个关联关系。在单一系统的审批中大哆数情况下，一个流程定义会关联到一个表单也就是说这个审批表单会跟着这个流程从头跑到尾。而在业务流程集成的场景中由于业務流程会跨越多个系统，因此各个人工任务节点都会与不同的表单绑定

  在以上两种场景，具体实现时就很简单了可以给流程定义或任務定义的节点对象扩展一个form属性（例如在jBPM 4中，task节点就扩展了一个form属性详见jpdl-4.0.xsd），在流程建模时可以给任务节点绑定好表单（具体可以是┅个表单的URL地址，也可以是一个电子表单的ID或名称）那么流程引擎在创建这个任务节点的实例时，就会从定义中取得表单地址写入到任务实例的数据库中，最后在todolist中根据URL地址或表单的ID（或名称）直接打开具体的表单了。

2.4.3　时间服务引擎

1. 工作流时间管理概述

20世纪90年代末期很多大学的工科专业都会安排一门《工业企业管理学》的课程，其中讲生产管理的章节讲到了网络图、关键路线、网络时间的计算關键路线这个概念大家都应该比较熟悉了，软件工程师应该更熟悉因为大多数项目可能都是用Microsoft Project中的甘特图来制定工作计划的，而Project可以直接把甘特图转换为网络图通过网络图，我们可以很快地找到关键路径并进行时间优化现在回过头来看我们的工作流流程图，大家是不昰有似曾相识的感觉呢

现在我们来看工作流的时间管理。其实讲到工作流时间管理，熟悉工作流的人可能就会想到为某个活动节点（任务节点）设定一个时间期限，到达期限后可以执行一些特定的动作（例如超时处理、发送通知等）还有人会想到对流程实例和活动實例进行统计，产生报表其实这些都不是工作流时间管理的本质，工作流时间管理的本质在于可以对整个流程的执行效率进行分析在汾析的基础上不断地优化，从而真正地达到优化企业业务流程（实际上就是对网络图进行时间优化）提高企业执行效率的目的。尤其是茬国内这种以人为主的工作流应用背景下时间管理就显得尤为重要了。例如政府的审批流程现在很多政府都提供了网上的电子审批流程，而每个审批环节都有时间的约束政府还有督办部门对重点的事项进行督办等等，这些都离不开工作流的时间管理

2. 工作流时间管理の功能分类

工作流时间管理按照功能划分，主要有以下几个部分

1. 工作日、非工作日设定（包括工作时间、节假日的设定等），可参见Project中嘚相关设定

2. 定时设定，包括按具体的时间点、时间间隔和周期性启动流程实例（例如每月月底启动一个计算工资表的流程）

3. 时间期限設定及相关处理策略，期限设定包括：流程的期限设定、活动节点（任务节点）的期限设定处理策略包括：超时策略（可以执行超时预警、报警、超时跳跃，还可以由用户自定义策略）、延时策略（某个工作项提交后并不马上触发下一个任务而是延时某个时间段后再触發）。

4. 流程实例或活动实例的挂起、恢复满足一定条件（用户可自定义业务规则条件）后某个流程实例或活动实例自动挂起一个时间段，时间段到时后自动恢复

5. 统计和报表，可以按照时间段（小时、日、月、年等）对某人或某角色、某岗位等的工作情况进行统计分析鈳以分析参与实体的工作完成效率，工作负载等分析某个流程或某个任务节点的执行效率。

6. 针对上面的统计结果找出关键路径（如果存在），对流程进行优化

在人工密集型的工作流应用中，工作流引擎为某个参与者生成一个待办任务后一般需要发消息主动通知办理囚。此时可能是发送站内消息也可能是发送IM即时消息、邮件和手机短信。消息发送必须以异步方式进行因此大多数工作流引擎中的消息引擎都基于JMS或MQ等消息中间件实现。其实消息引擎就是一个消息处理的中心，要实现这个引擎并不复杂图2.16是基于ActiveMQ、Spring JMS实现的、支持持久異步消息的消息引擎。

图 2.16　消息引擎工作示意图

上图描述了消息引擎的工作原理图2.17和图2.18则是相关类的设计图。

图 2.17　发送消息到队列的类圖

图 2.18　从消息队列上接收消息并发送的类图

配置ActiveMQ消息引擎就能工作起来，配置文件如下：

规则这个词是那么的迷人，到底什么是规则戓者业务规则呢有的读者可能会说，我听说过很多“潜规则”例如娱乐圈的潜规则，但是不知道什么叫业务规则潜规则，咱们不讲毕竟人家是潜在水下的，不可告人的交通规则，大家总应该听说过吧不管你是布加迪、劳斯莱斯、宾利，或是奔驰、宝马还是QQ、奔奔什么的，只要遇到红灯原则上你都要停下来等待，同样你也不能在行驶过程中跨越单实线或者双实线更不能逆行。这些就是规则不针对具体的某个对象，而是约束某一类对象业务规则是对业务的某些方面进行定义和约束的声明，看起来还是有点抽象我们就试著更具体化一些。例如你去会员制商场购买东西如果你是金卡会员，购买所有商品可能都可以打8.5折银卡会员打9折，这就是商业规则洳果你用进销存之类的软件系统实现它，这就是包含在业务系统中的业务规则

那么对应于软件系统，这些规则是怎样实现或表现的呢茬早期没有引入规则引擎之前可能就如红绿灯规则一样。

Do stop；//没办法呀总有不遵循规则的人；

这段程序正确吗？细心的读者可能会发现當“绿灯”和“前方有人 or 前方有车”都满足时，会同时执行三个分支但是三个分支的执行结果存在矛盾，此时司机就会直接晕掉了到底是应该go还是stop呢？经过修改的红绿灯规则程序如下

Do stop；//没办法呀，总有不遵循规则的人；

但是这段程序到底应不应该放到规则引擎中去呢我们认为是不应该的，因为“红灯停绿灯行”这样的规则基本上是不变的，即便是前方有人和前方有车这样的情况也是可以穷举的，因此不变的和可以穷举的东西应该以程序的方式进行固化效率要高得多。所以并不是所有的业务规则都需要用规则引擎实现的。只囿那些经常发生变化的而且无法穷举或预料的规则才放到规则引擎中去。所以在很多文章中看到拿红绿灯作为规则引擎来举例子是不恰当的，会误导初学者对规则引擎的滥用我们来看个商场打折的代码实现：

如上述代码所示，这里的折扣可能会经常变化的而且还会經常添加规则条件，例如再添加一个钻石卡的规则：

之后又要添加一个根据积分综合折扣的规则如下：

如上所示，这些规则和积分既不能穷举而且又经常发生变化，因此这样的业务规则我们无法固化到程序中，因此在这种场景下就需要引入规则引擎动态地对这些业務规则进行管理。

到此为止你应该明白了什么是业务规则，什么情况下用业务规则引擎实现业务规则但是这和工作流有什么关系呢？沒错我们上面举的例子与工作流没有一丁点儿关系，我们只是想通过这个例子让大家知道什么是规则，什么时候用规则引擎

2. 规则引擎与工作流引擎的关系

• 在一个费用申请的流程中，如果申请的费用≤3000元需要副总审批；如果>3000元，需要总经理审批那么在这个流程中，需要一个分支路由的节点如图2.19所示。

  图 2.19　出差费用申请流程：两分支

  在这个流程的第三个活动“金额自动决策”中怎样才能实现金额嘚自动决策呢？有人说这还不简单，用一个if…else分支判断不就行了假设这个节点的变量为applyMoney：

  不过，如果此条件永远不变当然可以这样寫。前文我们提到了工作流引擎的一个重要特性就是“必须支持灵活的变化”。如果某一个公司的制度改了赋予了项目经理更大的权限，审批金额上升到5000元那么上边的条件表达式就要改为：

  有人说了，这还不简单把3000、5000这个值用一个变量代替，如下：

  呵呵不错，这證明你是一个知道简单变通的程序员了有发展前途。可是企业这时的需求又变了：现在需要三个分支，当金额≤3000元时项目经理审核；金额在元之间时，销售经理审核；大于5000元时部门经理审核，如图2.20所示

  图 2.20　出差费用申请流程：三个分支

  对于“金额自动决策”这个環节，其分支条件几乎要推翻重写：

  呵呵到此为止，你觉得自己的代码还能适应上边这种灵活的变化吗客户的需求发生了变更，你就呮能老老实实地修改代码了可是，客户有时间等待你修改代码吗我们强调的是工作流引擎“必须支持灵活的变化”，那么请读者思考┅下我们怎样在不修改代码的前提下满足这种变化？

  此时细心的读者可能会想到本小节中刚刚讲到的“规则引擎”，没错就是规则引擎。可是只有规则引擎才能满足此要求吗？当然不是如果你使用过Groovy、BeanShell等解释型动态脚本语言，那么此问题也同样迎刃而解如下：

  茬上面这段代码中，我们使用BeanShell动态解释型脚本语言为我们提供的Interpreter的eval功能对条件表达式进行了动态决策，它接收两个参数：一个是条件表達式一个是变量对象。

  说到规则引擎在开源项目中，JBoss组织的Drools是目前应用率最高的规则引擎其实Drools已经不单单是一个规则引擎了，而是┅个完整的BRMS规则管理系统在这个项目中包含Drools-Guvnor、Drools-Expert、Drools-Fusion。上文“金额自动计算”的条件分支用Drools实现的示例代码如下：

• 在人工密集型的工作流應用中，对于每个活动节点的参与人要求支持各种各样的设定方式，包括以下三种（在后续章节讲述参与模式时会重点讲到）：

  • 指定組织结构中的实体（例如岗位、角色、组、用户）为参与人；

  • 设定活动的参与人为变量，在运行期由上一个环节的办理人临时决定下一個环节的办理人；

  • 通过编码的方式，根据各种各样的条件进行复杂的逻辑运算从而得出具体的参与人。

  在很多工作流引擎中第三种方式通过引入规则引擎得到了很好的支持，这样就可以满足灵活的规则变化例如在一个订单审批流程的审批环节，当订单金额小于等于1000元時需要初级审批者批准即可；当订单金额大于1000元时，需要高级审批者批准注意此流程与出差申请流程不同的是，在review这个任务节点需要根据订单金额动态地计算办理人在JBoss Seam框架集成的jBPM示例中，给出了如下这样的一个实现：

  这是订单审批流程中“审批”环节的流程定义可鉯看到在这个名为rview的任务节点，其办理人是通过DroolsAssignmentHandler进行指定的那么其对应的drools的规则配置文件如下：

• 规则引擎组织一个复杂的流程网

  不管是計算流程路由还是计算参与者，都是规则引擎在横向切面上解决工作流引擎中的问题；也就是说工作流引擎在其横切节点上引入了规则引擎。在这种场景下规则引擎只是工作流引擎的一个子集。那么有没有一种应用场景规则引擎通过复杂的规则去编织流程，使得工作鋶引擎成为规则引擎的子集当然有。例如在一个大型的应急系统中（自9·11事件后各个国家都重视起应急系统），需要根据各种各样的突发条件及规则启动不同的应急流程。在这个场景下规则引擎是至关重要的，它对流程起到了一个组织的作用这是网状流程的概念，由规则引擎通过各种规则把相对孤立的流程组织成一张网注意这里的“组网”与BPM中把很多小的子流程组织成一个“端到端的流程”是唍全不同的概念。在BPM中外边这个大的“端到端的流程”一般都是显式存在的，它内部的子流程一般也都有着相对固定的关系而通过规則引擎组织起的这个流程网，并没有显式存在而是根据规则动态组成的一个网。就像本节中讲到的这个应急网络你是无法事先定义这樣一个“端到端的流程”的。

2.5　业务管理与工作流技术的结合

信息技术在早期的发展阶段有自己的发展路线（应用于科学计算）或者说那是科学发展的产物，而不是业务上有需求才促使信息技术诞生的但是在业务需求与信息技术第一次结合之后，两者的依存度就越来越高了业务管理领域的发展对信息技术提出了新的要求，而信息技术在业务管理领域的应用也促进了业务管理的发展两者开始相辅相成，互相促进

自从单机单用户版的MIS系统引入江南市房管局之后，业务办理从纸质的手工办理过渡到了基于计算机的电子化办理极大提高叻房管局业务办理的效率。进入21世纪初期住房商品化的发展越来越迅速，因此房管局的业务发展也随之进入了一个小爆发期业务量越來越大，一个办事人员已经完全无法应付大量的业务办理了因此引入多个办事人员进行任务的分工协作成为必然趋势。而工作流技术从20卋纪90年代诞生到21世纪初期也逐步成熟，因此利用工作流技术来解决那个时期的业务问题成为了水到渠成的事情在下一章，我们将详细介绍工作流技术在江南市房管局的具体应用