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的章节，我们将会详细分析该机制的实现细节。