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的章節，我們將會詳細分析該機制的實現細節。