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