[[358500]]

前言

本片博客的重點會放在「流程的講解」以及「Activiti7的一些重點功能」上.詳細的Activiti7教程會在之后的一篇博客里面詳細講解.主要還是我自己還沒有學完.

流程

沒有規矩,不成方圓.

其實流程就相當于我們在編寫功能時提前定好的規矩,我們一般編寫的功能都是按照甲方爸爸的要求編寫的,所以功能執行的過程就應該是按照甲方爸爸定義的流程來編寫的.那么我們就能理解流程的概念了.

理解完流程的概念之后,我們就需要了解一下我們一般是怎么執行流程的呢?

一般的流程我們自己設計流程表,然后將我們的流程表與我們的業務數據進行綁定,這樣我們的流程就能一步一步的進行下去.我們通過一個請假的流程 來描述一下一般我們是怎么實現這個功能的:

可能一開始看上面的流程會覺得,這樣挺好的,一目了然,清清爽爽.說實話,我第一次也是這樣覺得呢,這不挺好的嘛.但是告訴你都是假象.

在上面的設計過程中我們不僅要管理我們的業務數據,同時還要管理我們的任務數據,并且各個任務數據可能還存在著一定的關聯關系,這種關聯關系我們肯定也要保留,否則我們怎么能確定,主管到底審核的是誰的請假申請!!!!!所以說就會明顯增加我們對于數據的管理壓力.

這樣的設計方式也不能說他是錯的,但是隨之時代的發展,勢必就會產生下面的局面:「部門越來越精細(就是他娘很多部門的意思),流程越來越復雜,處理的時間越來越長.....」

在這這樣的情況下,如果還是我們自己設計表,然后與我們的業務數據進行綁定的話,那么顯然「不僅開發的難度會上升很多,同時在后期的維護難度上也會增加很多」.所以還是得通過流程框架來幫助我們更加高效的開發流程.

改動需求-->逼死程序員

說完流程的大體概念之后,我們來稍微了解一下為什么需要流程框架來幫助我們簡化流程的開發.原因就那么幾點,「一個就是開發的難度越來越大,流程越來越復雜,另外一個就是需求整天變個不停」.你想想你不用流程框架之前好不容易把一個流程寫完了,還沒兩天客戶說流程改了,你什么心態??

順便和大家講一下需求改了之后我們具體哪些地方使我們最頭疼的.

相信大家在開發的過程中最煩的就是需求一直在發生變化.因為需求一旦發生改變,那么就會引起下面一連串的反應.正如下圖所示:

就是因為會有上面一系列的連鎖反應,所以后端開發人員一般都是在需求盡可能詳細的說明書出來之后才開始開發的.

因為一旦需求發生改變.那么下面的幾項基本上也是肯定需要發生改變的.

數據庫重構 這個大家應該都能明白.就算不明白,舉下面一個栗子.大家就懂了. 假設我們之前設計的一張關于用戶User的表是下面這樣的:

但是呢客戶現在提新的需求了,我們需要把用戶的詳細信息包括:電話號碼,家庭住址,學歷等等信息全部存儲下來,那么顯然我們數據庫中關于User這張表就需要重構.而且重構會出現下面兩種情況: 1.「直接在原來的表上面添加字段.」2.「新建一張表,在該表上添加字段,之后再將兩張表關聯起來.」可能這時候會有人說了,第一種方案不是挺好的嘛,第二種方案不是鯊雕嗎!!還專門再建一張表關聯起來,真實有夠好笑的呢!!

其實并不是我鯊雕,這個其實是要看情況的,很明顯我們上面的樣例User表,可以直接在表上面添加字段就行了,但是如果是下面這張User表呢?

假設我們的表里面已經有了30個甚至更多的字段之后,那么我們還能繼續添加字段嗎?顯然這樣做就很蠢,相當蠢,非常蠢,確定一定以及肯定的蠢了. 因為 「一張表中的字段過多」 了之后就會嚴重影響我們關于數據庫「各項操作的性能」.所以我們只能選擇分表然后關聯的操作.這樣才能相對來說繼續維持我們數據庫相關操作的性能.

流程需要重新編寫 這個其實大家也能理解.我們還是舉一個栗子來幫助大家理解: 假設我們之前開發了一個功能是關于請假的. 假設我們之前的請假流程是這樣的:

但是需求改成這樣了:

那么顯然相應的我們關于該請假流程的整個編寫過程就要發生改變.所以我們后端開發最最最最最討厭需求有重新發生了改變,這樣就使得我們整個的開發過程會異常的漫,并且有時候甚至會出現 「重構的過程比推倒重新做花的時間還要長」.所以我們常常能夠看到什么「程序員與產品經理打架的新聞」,這個也是正常的.

• 模塊之間產生新的耦合關系 如果只是上面的還好,就怕客戶提了一個之前沒有提到過的模塊,如果這個模塊只是關聯到我們最開始的模塊或者是最后的模塊,其實都是還好的,就怕他提的功能模塊是卡在兩個模塊中間執行的,這就要命了.不僅要和前一個模塊進行綁定,同時又要與后一個模塊進行綁定.兩頭為難. 這就好比某奇藝的騷操作,看網劇的時候好不容易等你熬過了開頭的廣告,之后好不容易看了半集電視劇了,他又給你整了個插播廣告,看完插播廣告你才能看下面半集電視劇,你說你氣不氣.圖片

Activiti7相當方便快捷

講了那么多關于流程以及流程開發復雜的 東西,下面我們來簡單將一下Activiti7是如何幫我們實現的吧!

這里先簡單的講解一下,詳細的教程會在下一篇博客里面完整的分享出來.

首先第一點,「關于流程的表都不需要我們在單獨設計創建,Activiti7會幫我們自動創建并且管理」 ,想想看,這是一件多么美好的事,基本上流程的所有問題全部都交給Activiti7就能完成.

第二點Activiti7大大的簡化了我們之前重復性的管理任務信息以及關聯的操作. 我們首先需要理解Activiti7的流程運轉過程.我們可以通過下面的圖來進行理解:

在Activiti7中是采用一開始就把操作的整個流程部署好,這樣每個用戶的操作就會按照這個流程走就行了. 那這樣我們按照這個順序來走一遍 我們先來繪制一張BPMN文件.

可以看到我們在BPMN文件中就已經定義好了整個流程的運轉過程,并且將流程中的操作細分成了相應的「任務節點---(發起請假,審批請假)」,用戶每操作完一個動作,相應的任務節點就完成,交付給下一個任務節點,當所有的任務節點都完成了以后這個流程就結束了.

這樣就使得我們不用在考慮如何存儲任務節點以及他們的關聯信息了,這些操作全部都交給 Activiti7來操作就行了.

之后我們就只需要將該流程定義部署起來:

@Autowired 
 private RepositoryService repositoryService; 
 
 //根據bpmn部署流程 
 @Test 
 public void initDeploymentBPMN(){ 
     String filename="BPMN/Part4_Task.bpmn";//BPMN文件所在的位置 
     Deployment deployment=repositoryService.createDeployment() 
             .addClasspathResource(filename) 
             .name("流程定義部署測試") 
             .deploy(); 
     System.out.println(deployment.getName()+",部署成功"); 
 } 

這樣我們的流程定義就部署成功了.

之后我們就需要去初始化該流程定義的一個流程實例:

@Autowired 
    private RuntimeService runtimeService; 
 
    //初始化流程實例 
    @Test 
    public void initProcessInstance(){ 
 
        ProcessInstance processInstance=runtimeService.startProcessInstanceByKey("myProcess_Task");//BPMN文件的Id名 
        System.out.println("ID:"+processInstance.getId()); 
        System.out.println("ProcessInstanceId:"+processInstance.getProcessInstanceId()); 
        System.out.println("ProcessDefinitionId:"+processInstance.getProcessDefinitionId()); 
    } 

這樣我們的流程實例就已經創建完畢.之后我們就可以一步一步的執行我們的流程實例中的任務節點了.

@Autowired 
    private TaskService taskService; 
    //執行任務 
    @Test 
    public void completeTask(){ 
        taskService.complete("2d22f941-3f67-11eb-b3b6-3c58c24c1a1b");//任務節點的ID號 
        System.out.println("該任務節點已經處理完畢"); 
    } 

這樣我們就可以完成我們的任務節點,等到所有的任務節點都完成之后我們的流程就完成了.

是不是非常的方便快捷.

并且就算甲方爸爸修改了需求,我們只需要重新繪制我們的BPMN文件,之后在重新部署,再將我們相應的完成任務節點的操作與我們的業務數據對應即可.相當快速.不用再像之前一樣了.

到這里一個簡單的請假流程就編寫號了,是不是相當的方便快捷!!!!

本文轉載自微信公眾號「萌萌噠的瓤瓤」，可以通過以下二維碼關注。轉載本文請聯系萌萌噠的瓤瓤公眾號。