第六章-工作流之数据模式（可见性模式）

可见性模式讨论数据的作用范围。

 

1、任务数据（WDP_01: Task Data）

唐僧与QA MM

在一个典型的项目团队里，包括了以下几种角色（帽子）：PM（项目经理）、BA（业务分析师）、DEV（程序开发者）和QA（质量保证人员），整个团队的目标是向客户交付价值。

 

那么，有一天，QA MM来找我，我是开发人员。MM说，一张图片没有正常显示，我想知道原因，同时想知道你能否修复。我的第一想法是，这不可能，一定是环境的原因。我说，好的，稍等。接下来，我张大嘴巴看到了MM给我重现的BUG：本该显示图片的位置一片空白，就像此时我合不上的嘴。这怎么可能呢？我想，这个功能完成的如此之得意，以至于测试用例里的数据都是以我的名字命名的。

 

几分钟后，或者更长，我叫来MM，说，找到原因了。

 

我打开编辑器，光标在源程序的某一行闪烁，我说，最根本的原因在这里。我看到MM的眼中闪过一丝迷茫。接下来，我却换到另外一个源文件，光标继续闪烁，我说，这里的程序因此受到影响。看得出，MM有点发晕。终于，当我打开第N个源文件并试图继续讲解时，MM昏过去了。

 

当MM苏醒过来时，我在她清澈的双眼中看到了一只清晰的唐僧。

 

MM肯定感到了不好意思，因为我的讲解中包含了比喻、类推、排比等我力所能及的各种语文知识，看得出，我很努力，我的语文老师也很努力，所以她委婉地说，能不能简单一点？

 

我想了想，说，测试驱动时测试数据不全导致程序少考虑一种情况。

 

MM说，能修复吗？

 

我说，可以。于是故事结束。

 

就 是这样，当我们执行一项任务时，围绕这项任务必然会产生许许多多的信息，这些信息对于该任务的执行者是必须的，但是对于其他人则不是，有效的沟通往往来自 于简练的表达即只表达对方需要和可以理解的内容，浩瀚的细节只会将真正想表达的内容淹没。其实这里还有这样一层意思：我之所以用这么多的细节信息来淹没QA，实际上是不太情愿承认程序里有BUG。QA想要的结果很简单，是否是程序BUG，能否修复。而开发人员则往往把自己的程序与自己关联在了一起，认为程序是自己的扩展，程序有BUG则意味着自己有缺陷。这一关系明显是矛盾的，可是一些团队里开发人员和QA能够和平相处，而有些团队却势如水火。

 

那么，对于单个任务而言，需要定义自己的变量，这些变量数据只与该任务相关，只在该任务里可见。典型的工作流应用于任务执行期间的中间数据存储。在文档处理中，一个重要的功能就是需要提供版本管理，在单个任务实例里，办理者能够管理自己处理过的文档版本。

 

描述

任务能够定义变量，在一个流程实例里，该变量只能被其任务实例所使用。

图 6-2任务级别的数据可见性

如图6-2所示，我们在任务B上定义了一个变量M，此时，在一个流程实例里，只有任务B的实例才能使用该变量。

 

实现

存在两种实现方式，一种是如图6-1所示的，在任务节点定义中声明变量，运行期初始化任务实例的同时初始化该变量并使用；另一种是在流程定义级别统一声明变量，但是各个任务实例都独立初始化并存储该变量。第二种实现方式在各个任务都需要使用同一语义的变量时很常见，例如各个任务实例都会有参与者，我们在流程定义时声明一个名为userid的变量，在流程实际执行时，各个任务实例都会独自保存有自己的userid数据。

 

2、块数据（WDP_02: Block Data）

用户故事与开发任务

在开发人员的日常工作中，编码工作主要包括了三种类型：用户故事（用户故事）、开发任务（Task）和缺陷（Defect）。尽管不喜欢缺陷，但是它是你生活的一部分，并且大部分的缺陷都与沟通相关，在这些缺陷中，团队成员对功能的假设产生了偏差。

 

一 个用户故事可以拆分为多个开发任务。一个常见的问题是：如何区别用户故事和开发任务？我们用海平面来进行区分，海平面即用户价值。项目目标是那高高的风 筝，它高高的飘扬，越过云彩，它是项目帮客户实现的商业目标，飘那么高，让客户瞅一眼就觉得激动万分；项目特性是那半空中的云彩，客户从风筝上下来，看到 的是项目所提供的大的特性，这些特性帮助客户实现其商业目标；接下来就是用户故事，是的，现在终于落地（海）了，用户故事是海上的点点小岛，它一半露在海 平面以上，另一半没在海平面下，客户看到的是海平面以上的东西，所以用户故事一定要包含用户价值，开发人员看到海平面以下的东西，所以用户故事一定要是可 评估的、可开发的，因为存在两种不同的角度看用户故事，所以用户故事一定要是可沟通的，围绕着海岛总是有很多的话题，例如，项目经理经常就会与客户就海岛 展开磋商，项目经理通常会说，时间来不及了，我们需要找出最有价值的海岛进行开发。而客户通常会说，不行啊，看人家海南岛，仅仅一个规划就把房价炒得那么 高，所有的海岛都要开发；开发任务则是海底的贝壳、扇类，它们是那样的美丽，以至于只有开发人员才能了解，当一个用户故事过大难以评估时，我们往往将它拆 分为多个开发任务，这些开发任务单独并不能为客户提供价值，只有当多个开发任务联合起来时才能显示价值，典型的，探索性技术开发都属于开发任务。是的，那 么结论是？

 

开发人员都是潜水员！所以，怪不得那么多技术社区冷冷清清，如果你不提供内容，就别指望其他人为你提供内容。

 

这样，当进行开发任务时，这些开发任务就与与之对应的用户故事构成了一个完整的对客户可见的价值域，作为开发人员，必须理解相应用户故事要解决的问题和验收条件，这些信息贯穿于所有开发任务的开发中，为用户故事和开发任务们所共享。

 

那么，对于工作流里的块任务，它需要能够定义变量，这些变量数据能够在其子任务中共享。

 

描述

块任务（典型的如子流程任务）能够定义变量，在一个流程实例里，其所包含的子任务实例能够使用该变量。

图 6-3块任务级别的数据可见性

如图6-3所示，我们在块任务C上定义了一个变量M，此时，在一个流程实例里，与其对应子流程中的任务X、任务Y和任务Z的实例在运行期都可以使用该变量。相似的，我们可以在子流程中定义了一个变量N，那么子流程中的所有任务实例都可以使用该变量，根据不同的工作流系统实现，N也可以被块任务C的实例所使用。

 

为什么需要块任务？

 

良 好的代码需要封装，需要职责分离，业务流程建模同样如此。在一个定义良好的流程里，相互连接且语义相关的任务往往被建模为子流程。例如，一个跨越多个部门 的复杂业务流程，一种比较好的方式是针对每个部门都建立起自己的子流程。从维护的角度看，这种建模清晰自然，各个部门也能自己维护自己的流程建模。由于任 务执行的上下文存在差异，那么针对各个子流程建立自己的执行环境就非常必要，在工作流系统里，这种执行环境的表现即为数据。

 

实现

为 保证子流程定义的复用和独立性，一般不直接在与之对应的块任务里定义其要使用的变量，采用的方式是在块任务定义里进行数据映射，即将块任务中的变量与子流 程中的变量进行一一映射，运行期父流程实例中的变量传值到子流程中的对应变量中，子流程实例执行完毕再将值传回。具体的实现将在下一节的交互模式里进行详 细说明。

 

3、任务范围数据（WDP_03: Scope Data）

PDF噩梦

在之前的一段时间里，只要一提起PDF，我就会头晕，然后是头疼，最后是头大，总之是和头相关。需求很简单：为所有报表提供在线生成PDF版本的功能，这样网站用户在浏览报表时就可以下载离线浏览。对不住了，开源软件，我不得不说，慎用开源软件，慎用！痛苦的查找论坛、痛苦的翻看源码，最后，在支付了200欧后，痛苦消失了，我们购买了商业软件，200欧兼容了更多的网页结构，200欧具有更快的速度，200欧带有一年的技术支持，最最重要的是，200欧，客户出的。

 

这不是这里的关键，问题是，200欧后，我遇上了新麻烦：报表的PDF版本样式不正确，不正确的原因是图片下方的文字将图片的排列样式弄乱了（图片大小不规则，字数不规则）。在网页中，DOM渲染完毕后，我们使用JavaScript来进行图片与文字高度的重计算，但在PDF中，我们束手无策。

 

我问BA，可以容忍部分图片排列不整齐否？不出所料。

 

怀有侥幸，我继续问BA，可以容忍部分文字丢失否？BA说，不可以。意料之中。于是找到徐昊。

 

徐昊问BA，这些说明文字对客户如此重要吗？

 

BA说，是的。

 

徐昊说，为什么？它主要有哪些内容？

 

BA说，有标题，简单说明以及图片的版权信息，最重要的就是版权信息，一定不能丢失。

 

徐昊说，能不能这么说，其实对客户最关心的是版权信息。

 

BA说，是的。

 

于是问题解决。解决方案是：我们给文字定高，同时将文字缩小以容纳最可能多的字数，这样网站用户在PDF里看到的图片重新恢复了整齐，尽管看不太清图片说明文字，但是用户真正关心的是图片，谁关心哪些无处不在的版权信息呢？你可能会说了，看不清版权信息怎么行？幸好，你问的不是，版权信息有那么重要吗。回答是，这里是PDF，移动你的鼠标到Zoom，点击下拉框，点击150%以上的选项，然后，你会惊讶的发现，那些该死的版权信息到处都是。

 

BA的职责是帮客户发现的问题，开发人员的职责是解决问题，QA的职责是校验最终的实现是否能够解决客户的问题。具体到一个用户故事上，就是BA编写用户故事，DEV编码开发，QA验收用户故事，这是三个任务，很明显，这三个任务有一个非常重要的共享信息，这个信息就是用户故事所要实现的客户价值（即帮客户解决的问题）。围绕着客户价值，每次迭代开始前，团队都会进行迭代计划会议，所有成员会跟随BA逐一审核各个用户故事；围绕着客户价值，开发人员开发中随时可以和BA进行沟通，就设计问题进行讨论；围绕着客户价值，开发人员每开发完成一个故事，BA、开发人员和QA就会在一起进行一个微型 ShowCase，在期间讨论用户故事的实现是否实现了客户价值，大家对用户故事的理解是否一致。

 

那么，在相关的任务之间需要能够定义变量，这些变量数据能够在这些任务间共享。

 

描述

一定的任务范围能够定义变量，在一个流程实例里，该范围所包含的任务实例能够使用该变量。

图 6-4任务范围级别的数据可见性

如图6-4所示，我们划定了一个任务范围，该范围包含了任务A、任务B和任务C，同时，我们在该任务范围内定义了一个变量M，那么，在一个流程实例里，只有任务A、B和C的实例在运行期能够使用该变量，任务D和E的实例都不能访问，不可见。

 

可以看到任务范围和块任务在概念上比较相似，都是包含一系列的子任务，它们之间的差别在于：块任务一般具有比较独立的执行上下文和业务语义，而任务范围则是对具有相同执行上下文的任务的一种分组。

 

在工作流系统里，对流程任务进行分组的好处在于：可以为特定的一组任务绑定数变量、异常处理器和补偿动作。例如在图6-4中，如果任务A、B和C中的任一实例执行失败，那么我们就认为整个任务区域执行失败，将统一执行一个业务补偿行为，同时，这些任务共享一个异常处理器。

 

实现

在jBPM4里，流程定义模型相比jBPM3最大的变化即是引入了任务嵌套的概念，一个任务能够包含多个其他任务，这里的父任务即可充当任务范围的定义。jBPM4针对这种嵌套的任务建立了一套处理机制，总的来说就是建立任务运行期的嵌套关系，查找变量时首先会在任务级别进行查找，如果找不到，则会依次向上查找父任务实例，直至流程实例级别变量，同时，父任务可以统一绑定异常处理器和事件动作。在后续jBPM4的章节，我们将会详细分析该机制的实现细节。

 

4、多实例数据（WDP_04: Multiple Instance Data）

估点与人月

我不喜欢估算人月，因为这是一个需要想象力的活，并且从来不准。最开始是被经理拉着估算，经理说，完成这个子系统需要多长时间？我开始想象，我发誓，我一定是努力想象了，因为我说的是20个工作日，而不是一个人月。经理说，知道了。然后他在MS Project上将我的名字拉出一条长长的蓝线来。40个工作日，经理说。真是个悲观的人，我想，他一定是童年受什么打击了。

 

事实上却是：我太乐观了。开发人员都是乐天派，至少在估算开发进度这件事情上。

 

不会有人请假、不会有人生病、每个人都像今天这样有效率、不会有人来打扰，好吧，如果你认为上天是如此的眷顾你们团队，那么，大厦一层，3号房间，你可以去买双色球了。

 

很快就受到了教训，这次是我负责一个新产品的开发，这次是老板问我第一个发布需要多长时间。我说，4个月，我有包括自己在内的4个开发人员，加起来就是16个人月。糟糕的是，这个时间只是我对每个开发人员对自己任务估计时间的简单叠加；更糟糕的是，在开发人员向我汇报估计时间时，我甚至帮他们进行了时间的压缩，需要这么长的时间吗？不用吧，其实实现起来很简单的；最最糟糕的是，老板相信了我的估计，天啊，他竟然相信了！

 

痛苦的过程很快就来了，这次200欧也不能止疼。开发一天天的滞后，这些滞后总是一些小事引起的，并且编码完成远远不是交付，交付包括了需求、测试、文档和客户。终于，到达第3个月的时候，我发现仅仅完成了1个半月的编码工作，你没看错，仅仅是编码工作，中途还伴随着开发人员的流失。因为我将页面与后台实现进行了分离，QA甚至不能开始任何有效的测试工作。我恨分层开发。

 

再 接下来人月就不见了，取而代之的是估点，任务很简单，确定当前用户故事的点数，啊，是用户故事啊，不再是模块和子系统了，悲剧了，不能锻炼想象力了。估点 任务由整个开发团队一起进行，每个开发人员都需要出具一个点数，这个点数是个相对值，相对一个大家都认知的用户故事（一般该用户故事的点数为1），最后的结果取决于大家共同的点数。

 

咳咳，明白了吧，用户故事估点这个任务实际执行时产生了多个任务实例，每个实例都由一个开发人员执行，当所有的任务实例都执行完毕时，它们都返回了同一个信息即点数，最后该用户故事的点数由所有这些点数共同决定。

 

那么，多实例任务需要能够给每一个该任务的实例都定义一个变量，同时，当这些任务实例都执行完毕时，能够汇总这些变量数据。

 

描述

多实例任务能够定义变量，在一个流程实例里，该任务的每一个任务实例都能够在任务级别初始化该变量，并独立使用。

图 6-5多实例任务级别的数据可见性

如图6-5所示，在一个流程实例里，多实例任务E运行期产生了E1、E2和E3三个任务实例，我们在任务E上定义了一个变量M，实际执行时，每个任务实例都在任务级别初始化了一个变量M，并独立使用，最后当所有任务实例都执行完毕时，各个实例的M值将被汇总并传递给下一个任务。上图展现了数据的简单叠加汇总。

 

实现

通常在任务定义里声明变量，各个任务实例都独立初始化并存储/操作该变量。变化来自于数据的汇总策略，根据不同的业务场景，这个策略会发生很大的变化，例如投票里的一票否决和多数通过。一般工作流引擎都会提供接口作为与业务的契合点。

 

5、流程实例数据（WDP_05: Case Data）

两次点击

在实现一个给图片打标签的用户故事时，我碰到了一点小麻烦。这个用户故事的客户端代码很重，需要使用JavaScript在客户端维护很多的状态，最后同步给服务器端。在这种情况下，如果分两次同步数据则会给极大地减少客户端的代码复杂度，同时代码行数也会大大减少，唯一的问题在于：客户需要点击两次，比原先设计的多出一次。

 

这不是什么问题，我想，仅仅多出一次点击而已，地球也不会因此毁灭，即使毁灭也还有2年呢。

 

这个问题被Micheal注意到了，他找到我，说，为什么多出一次点击？

 

我说，这样比较好实现，只是多出了一次点击。

 

Micheal说，不是一次！你明白这个程序对客户的重要性吗？

 

项 目开始的第一天，所有项目成员聚在一起，内容是讨论客户的商业模式。客户是一家全球领先的时尚内容提供商，通过遍布全球的员工，客户每天获取大量关于时装 发布、产品设计、街边流行、城市热点等信息，这些信息的绝大部分是以图片的形式提供，然后再由本地编辑对这些图片进行整理和归类，最后由设计人员根据这些 信息书写报表。客户通过分类细致的海量图片和具有前瞻的分析报表吸引行业内用户订阅并付费。

 

我说，我知道了。

 

Micheal说，我们经常在抱怨这个软件不好用，那个工具不好用，可是，我们有选择的权利，而客户没有，一旦项目交付，意味着他们每天至少有8小时要使用这个软件，8个小时要处理多少张图片？那又是多少次点击？一个月呢？一年呢？一个团队呢？

 

接下来，我们花一天时间重构了代码，很开心的一天，因为我们认识到这一天帮客户减少了数以万计的点击。

 

整个项目团队的目标需要一致，只要有一名成员与团队的目标不一致，那么该团队的整体水平就会受到影响。这种影响不仅来自于这名成员本身，而且也会影响其他团队成员，他们总能感受到分歧或某个同伴漠不关心的态度。最为开发人员，我们需要了解为什么做，而不仅仅是做什么。

 

那么，当所有具体任务开始前，我们需要统一认识，这些认识包括了客户的盈利模式、项目在客户价值链中的位置、项目的目标等等，这些认识贯穿于整个开发流程，为所有任务共享并作为所有行为的指导原则。

 

描述

流程模型能够定义变量，在一个流程实例里，该实例中的所有任务实例都能够使用这些变量。

图 6-6流程实例级别的数据可见性

 

如图6-6所示，在流程模型里我们定义了变量M，在一个流程实例里，该实例里的所有任务实例都能够使用该变量M，任务A、块任务C、多实例任务E和子流程任务X的实例都能够使用M。

 

实现

最基本的数据模式，几乎所有的工作流系统都提供支持，相当于控制模式里的1到5模式。在很多的系统里，由于不支持1到4的数据模式，往往通过冗余变量定义来变通支持相关的业务应用（例如，任务A需要一个独自使用的变量N，那么实现往往是在流程模型里定义该变量，并约定其他任务不能使用该变量）。

 

6、文件夹数据（WDP_06: Folder Data）

上哪儿借人

项目底层平台使用的是Day CQ，Day CQ采用了Apache的OSGI框架Felix。Felix给程序包的管理带来了方便，但是给开发带来了一些困扰。每次开发完代码，我们需要将代码打包成Bundle部署到Felix上才能看到实际的效果，这带来了调试的不便，特别是在编写JavaScript代码时，每次改动代码，都需要使用Maven打包部署一次，时间在这一刻时滞了，十几秒比一个世纪都长。

 

于是我们决定去其他项目组抓人。韩锴是我们的第一个目标，他做过Day CQ的 项目，但此时他正在另一个项目组，处于另一个开发流程中。我们找到韩锴的项目经理，说明来意，这只是一个形式，很快，我们就得到了他。他来到我们项目组， 坐下来，和我们一起结对，十分钟，他帮我们装好了他们用过的一个插件，这个插件在本地文件和服务器文件间建立起映射，这样，我们又可以向以前那样编写代码 了，不用打包、不用安装，修改完毕，按下F5即可（我甚至想如果F5都不用按该多好啊）。

 

公司从事各种项目的开发，虽说各个项目各自前进（都在进行自己的开发流程），但总有相似的任务，这些任务或解决的问题一致或使用的技术相似，那么，在这些相似任务间共享知识就变得非常重要。共享这些知识有很多种途径，建立Wiki、同事间进行Session、培训都是很好的做法。但是文档的问题在于没有人去看，并且如果分类不明细，超过2页的文档就会让人昏昏欲睡；Session和培训的问题在于听过即忘，你还记得茴字的四种写法吗？抓人结对始终是最优的方法，既能即时沟通，又能避免光说不练，对程序员而言，大多数时候，几行代码比一堆文档更有说服力。于是，我们经常可以看到，有人跑到你面前，说，你被我借用了，跟我走。

 

什么，你们公司没有Wiki，没有Session，老板还不愿意花钱进行培训？好吧，请问贵公司是软件公司吗？

 

什么，你们领导说你很忙不能借？我敢打赌，这一定是他显示他那点可怜权利的唯一时机，原谅他吧。

 

那么，不同流程实例之间可能存在着相似的任务，这些任务之间需要共享信息。

 

描述

流程模型能够定义变量集合，这里称这种集合为文件夹，当启动一个流程实例时，流程实例能够与这些变量集合绑定，一旦绑定，该流程实例里的所有任务实例就能够使用变量集合里的变量。

图6-7文件夹级别的数据可见性

如图6-7所示，我们在流程模型里定义了两个变量集合，分别是文件夹甲和文件夹乙，在文件夹甲里我们定义了变量M，在乙里我们定义了变量N。流程执行时，实例1与文件夹甲进行了绑定，那么实例1里的所有任务实例都能使用变量M；流程实例2与文件夹乙进行了绑定，那么实例2里的所有任务实例都能使用变量N；流程实例3与文件夹甲和乙同时进行了绑定，那么实例3里的所有任务实例都能使用变量M和N。需要注意的是，这些变量在所有绑定其的流程实例里都是共享的。

 

该模式的目的即是在不同流程实例间选择性的共享数据，选择性预示着这其实是为具有相似性的任务实例共享数据。最典型的应用就是建立起与流程相关的知识库应用。如下图6-8所示：

图 6-8流程相关的知识库应用

与单纯的建立Wiki和文档相比，图6-8的模式建立起任务实例与知识库的强关联性，随着知识库的细致分类和与流程绑定，更精确的结果能够直接推送给任务实例执行者。

 

7、流程定义数据（WDP_07: Workflow Data）

CI红了

橘子红了很好看，CI（持续集成）红了就不是那么回事了。

 

一段时间，我们项目组受到了同事的激烈批评，其中的一个原因在于：CI红了，没人修复，周末红了两天。是啊，周末没人加班，绿了才是见鬼了呢。

 

我们并不服气，因为每次提交前我们都会在本地运行所有的测试，测试通过后我们才会提交，然而，一旦提交，CI却并不总是领情，一段时间里主要原因在于CI环境。我们在CI服务器上启动了Day CQ，每次代码提交后都会被打成Bundle，安装到Day CQ上，然后开始执行自动化测试。理论上OSGI框架应该支持无数次的热部署，可随着Bundle和代码基的扩大，情况开始变得糟糕，不知道什么时候，Day CQ就失去响应，测试自然就失败了。一段时间以来，一旦谁的提交破坏了CI，我们的CI猴就会站起来，很希曼的大吼一声：CQ挂了！然后刚才提交代码的那个倒霉蛋就屁颠屁颠去CI服务器重启Day CQ，剩下人则一起大笑，此时，提交拼的是人品。

 

这次也不能例外，重启Day CQ，手动告诉Cruise重新执行，于是CI就绿了。

 

于是，我们显得理直气壮，这不是我的错！

 

那么，这是谁的错呢？

 

在公司，不管是任何项目的开发，都会在项目开发地点的最高处架上CI环境的显示器，那里躺着Cruise那张让人欢喜让人忧的老脸。所有人都有基本的共识：一旦CI失败，必须要有人尽快修复，在修复之前，所有人都不能提交。CI是项目最重要的可视化手段之一。认知，就是测量。

 

回到问题上来，CI红了是问题吗？不是，这只是现象，CI所能做的只是暴露问题，事实上的问题是：由于CI的随机失败，整个团队的提交频率下降很快，经常有开发人员一天都提交不了的情况出现；由于提交频率下降，本地代码慢慢积累，开始出现在CI飘红基础上继续提交的现象，原因无外乎抱有侥幸心理：这是Day CQ的原因重启一下就好了，这样当大家忽略CI结果继续提交时，CI的根本好处就丢失了：自动阻止开发流程，迫使问题及时解决。

 

如何修复这个问题？实际并不复杂，我们改进了CI流程，在代码编译前增加了重启Day CQ环境的任务。一段时间后，通过持续集成状态分析工具 iAnalyse（http://code.google.com/p/ianalyse/，同事胡凯作品），我们发现CI的通过率从原先的50%迅速提高到90%，排队提交的现象得到缓解，同时，我们强制了一次破坏CI而迟迟不能修复的代码的回滚。

 

为什么最开始没有将重启Day CQ加入到CI流程，原因是最开始的代码规模并不大，频繁的安装Bundle并没有产生破坏Day CQ的影响，而每次重启需要大概1分钟，在最初整个自动化测试只需要5分钟左右的情况下，这一时间显得过长。随着时间的推移，自动化测试增长到20分钟左右，CI通过率逐渐下降，终于使得没重启Day CQ成为瓶颈。换句话说，就是CI流程也需要不断重构。通常，当人们熟悉一件事情后，就会忘掉为什么最开始事情就是这样，他们会认为这是很正常的事情，那怕有人指出来，最初的时候人们也会想：他并不了解实际情况。于是，人们会说，是的，他说的非常对，但是，我们有我们特殊的情况。

 

尽管最开始被指出问题时并不舒服，但是所有问题的解决都会经过这一阶段。最根本的，是在所有项目开发团队间都存在对CI的共识，总有些原则是需要遵守的。

 

那么，不同流程实例之间也需要共享信息。

 

描述

流程模型能够定义变量，所有属于该模型的流程实例都能使用这些变量，即，这些变量在其流程实例的任务实例间是共享的。

图 6-9流程定义级别的数据可见性

如图6-9所示，我们在流程模型里定义了变量M，那么，属于该模型的所有流程实例里的任务实例就都能使用M。

 

实现

和 文件夹数据模式类似，该模式目的在于在各个流程实例间建立起信息的共享。实现并不困难，困难的地方在于辨别哪些应用场景需要应用该模式。实际的应用中，工 作流数据与业务数据通常是分离的，这是合理的，工作流数据关注于流程的流转和任务推送，由工作流系统维护，业务数据涉及到具体的业务，由业务系统维护。而 数据的共享往往是业务数据的共享，在这种情况下，工作流系统只要提供钩子即可。在之前东方易维的工作流系统里，我们没有支持该模式，实际上是没有支持的必 要。

 

8、环境数据（WDP_08: Environment Data）

和网络管理员结对

Day CQ版本升级，需要搭建新的QA环境。这里强烈鄙视一下Day公司，版本存在BUG，想得不是如何支持，而是强迫用户升级，并且果然是个轻量级的公司，新版本与老版本存在大量不兼容的地方。相比而言，微软就厚道得多。

 

对Linux并不熟悉。突然间就看到网络管理员，大喜。

 

和管理员结对总有好处，比如，聊聊市场行情、硬件价格什么的，他的强大在于一边飞快的输入命令，一边能够飞快的回答你的问题，顺便，聊的高兴，换个新键盘鼠标什么的岂不容易。一得意，我就成功的从他那儿“借”来块移动硬盘。于是，一高兴，我就将Day CQ安装到了移动硬盘里，天啊，移动硬盘，过不了几分钟，我就会发现自己给自己埋了颗很大的地雷，但是现在，一切看起来都很好。

 

那么，流程中的任务需要从外部环境中获取信息和帮助。

 

描述

流程实例里的任务实例能够在运行期使用外部环境定义的变量，这里的外部环境包括了外部数据仓库（数据库）、外部应用和外部服务等。

图 6-10环境级别的数据可见性

如图6-10所示，外部环境定义了变量M、N、O，流程实例里的任务实例均能够使用这些变量。

 

该模式强调的是工作流系统的集成能力，工作流在执行时需要具备从外部获取和交换数据的能力。

 

再谈工作流系统与BPM（业务流程管理系统）

很多技术人员以 XPDL 和 BPEL 来区分流程产品是工作流还是 BPM ，认为 BPM 更为强调软件的系统集成能力。实际上，工作流软件与 BPM 软件最大的区别不在于技术实现，而是它们解决的问题域发生了变化。

工作流软件解决的问题域是起源于70年代的流程自动化，而 BPM 软件解决的问题则是源于90年代的业务流程优化 。

实际上很多 BPM 软件的前身即是工作流产品，从技术角度上理解，工作流软件和 BPM 软件是没有区别的， BPM 软件是工作流软件发展的结果，只是开发商出于市场的考虑换上一个不同的标签而已。很多 BPM 软件解决问题的思路并不正确，依旧是试图通过自动化流程来实现业务流程的优化，这再次回到工作流软件所面临的问题：企业很多业务流程很难自动化、自动化流程的柔性很低。对于这些问题， BPM 软件试图通过简化编程（快速开发、 SOA 思想）和系统集成来尽可能自动化多的流程，通过增强流程定量分析能力来尽可能的增加流程柔性。这实际上是在用正确的方式做错误的事，因为解决问题的思路从一开始就决定了这并不是一条正确的路。