基于工作流的平臺管理系統設計，解析異構應用系統業務協同工作流平臺設計與實現

「本文重點介紹關于工作流平臺系統。」

對于互聯網金融平臺來說,重要的業務尤其是涉及資金業務相關操作時都有必要有相關的審批流程.同時在流程的流轉過程中需要和各個業務系統進行交互,完成真正的業務處理, 并記錄這個過程中所有人的操作以及每一步操作時所涉及數據快照,以便于內外部審計和問題的追溯。

◆?下面為兩個典型的業務流程?◆

(注: 為了說明方便, 已經簡化和修改相關步驟, 和點融實際操作不一致)

一. 借款人銀行卡信息修改

該流程發起原因主要是由于借款人銀行卡變更原因需要修改. 流程關鍵步驟為:

? 用戶聯系客戶服務人員,提交申請, 包括借款信息, 手持身份證照片, 銀行卡信息等

? 申請提交系統后, 由風控進行審核

? 運營部門進行修改操

二. 提前還款流程

發起流程的主要原因是用戶希望按照合同進行提前還款. 流程關鍵步驟為:

? 借款人聯系客服人員, 提交申請

? 運營生成提前還款說明書, 其包括詳細金額數據

? 借款人確認, 通過客服服務人員上傳簽字照片

? 運營代扣還款金額, 結清借款

? 生成還款結清證明

在平臺的實際運營中, 有各種各樣的業務需要處理, 包括借款人, 出借人, 資金等等, 同時還涉及到各個不同的業務部門, 而且流程的流轉操作人員和部門也隨著公司業務的發展而不同的調整. 設計一個基礎的流程框架和實現基礎代碼, 形成簡潔的開發模式是該系統的關鍵. 因此整個系統的設計涉及到以下主要幾個方面:

? 選擇合適的工作流引擎

對于一個類似涉及到審批以及執行具體業務的系統, 基于簡單的狀態控制的設計, 或者自行開發類工作流引擎輪子的做法都是不合適. 所以一個開源并且被廣泛使用的工作流引擎是一個正確而且必須的選擇. Activiti 工作流引擎由于其輕量級, 易用性等優點目前在業界被廣泛使用. 其工作流的狀態機和外部系統的連接只需要通過一個ID進行關聯即可, 即activiti的business key。 (如下圖)

?設計通用的底層數據來支持不同的業務

由于這樣一個運營管理系統涉及到各種不同的業務數據. 如借款人信息相關涉及借款ID, 銀行卡信息等; 如出借人信息則涉及用戶ID, 電話號碼等; 而對于資金相關如提前還款則涉及到提前還款日期, 還款金額等. 所以一套支撐不同具體業務的流程數據表結構也是非常重要.

? 基礎框架代碼的設計

一個好的設計不是一步到位的設計, 而是一個循序漸進的過程以及不斷重構的過程. 但是非常重要的一點就是在一開始能夠根據當前的需求以及所能預見的需求進行設計, 并且在這個基礎框架代碼上開發要更加便利和簡潔.

◆?以下對第二、三點進行展開?◆

數據庫設計

如上所說, 這樣的一個數據設計必須能夠滿足:

1. 能夠滿足不同的業務域的需求, 如出借, 借款, 資金相關的具體業務數據

2. 能夠記錄每一步的操作審批或業務執行結果, 同時記錄相關的數據快照

所以, 基于具體的業務進行數據表的設計是不合適的, 且無法擴展. 常見的設計為基于Key-Value的設計, 而key則是各個不同業務系統涉及到的metadata. 如USER_ID(用戶ID), LOAN_ID(借款ID)等等. 設計概述如下:

一個Request代表某一個人發起的請求, Snapshot代表這個流程的每一步操作. Property則分別為Request的Snapshot的具體的數據, 當其REQUEST_ID非空SNAPSHOT_ID為空時表示其為REQUEST的屬性(SNAPSHOT同理), 即用戶發起請求所帶入的數據. 如: 用戶信息修改: PROPERTY則包括NAME(KEY)為USER_ID(用戶唯一ID), ATTACHMENT(用戶手持身份證照片), EMAIL(修改項)等相應的值. 而對于SNAPSHOT, 則記錄對應審核以及操作的信息, 其對應的PROPERTY則保存了對某個數據修改前后的值.

基礎框架代碼設計

初始的場景和需求包括:

1. 一些通用的activiti流程, 如一步操作即創建后只需要一步完成操作, 兩步流程 – 創建后一步審核一步操作等, 不同的業務會使用相同的流程.

2. 在activiti流程相同的情況下, 不同的業務的步驟其處理人/組則不同

3. 不同業務流程的實際代碼開發應該簡潔, 和工作流引擎解耦, 即實際的開 發人員 在不了解工作流引擎具體工作原理的情況下可以進行迅速的開發, 并 只需要關注具體 的業務需求

為了解決#1的問題, 則需要定義出流程--步驟—業務(請求類型)—處理人/組 的配置 關系, 并在流程流轉時自動設置, 而不是在流程描述文件 (bpmn)里 指定

為了解決 #2 的問題, 則需要用服務進行封裝, 抽象出一些接口以及基類的實 現, 并 應用一些常見的設計模式(工廠模式)和java的特性(反射).

下圖為基本的架構設計

基于這樣的框架完成基礎代碼后, 最終對于一個實現具體業務的開發人員來說, 其實 現一個業務流程代碼主要包括:

1. 實現一個創建Request的頁面, 用于錄入業務數據

2. 實現一個Request詳細頁面, 用于展示詳情, 包括操作歷史, 和業務操作按鈕

3. 實現該業務涉及的具體步驟的操作processor類(如審批或和其他系統對接, 完成實際的業務),

4. 將流程涉及的processor和對應的業務類型, 流程名, 流程步驟進行注冊綁定

演進過程

正如上面曾說到, 對于一個系統設計, 不可能一步到位, 在最初時要抓住最需要解決的問題, 比如在這個系統開始階段, 最核心的設計包括:

? 數據庫設計 和RequestService對底層數據操作的封裝

? WorkflowService對工作流引擎的封裝

?可配置化的根據業務類型(Request Type) 和配置(process_cfg)在運行時動態設置流程相應的處理人/組

持續的重構包括:

?將各種處理類(業務處理類, 流程處理人/組分配處理類, 通知處理類) 通過RegisterService的統一注冊管理, 并且支持應用對于特定的流程實現特定的處理類來替代默認的處理類

?RequestQuery支持統一的查詢入口對業務流程數據進行查詢

? 根據業務需要提供ASync的processor處理基類, 因為實際應用中發現, 一些業務的處理(如批量)需要一段時間的執行才能完成, 而異步處理基類則完成基礎實現, 并由相應子類去實現虛函數即可.

公共化工作流模塊:

? 最近, 另外一個項目其應用到的場景和這個系統有類似之處, 其獨立于該業務管理平臺. 在這種情況下, 將該工作流相關的模塊進行公共化, 以JAR包的形式提供, 使得另外一個系統的開發能夠短期內達到同樣的效果

借鑒Activiti的源代碼

在設計和實現該系統時會有

這樣或者那樣的疑惑或者斗爭,

哪一種實現更好?

別人的系統是如何實現的?

這里舉幾個例子

Property表里是否需要需要用不同的字段(LONG_VALUE, TEXT_VALUE, DOUBLE_VALUE等)存不同類型的值;還是直接都存成字符串, 在代碼中再根據需要轉成Long, Double等?當然兩種實現都是可行的, 并且各有優缺點, 并且個人覺得存在不同的字段上優點更大一些(主要體現在查詢效率), 但是如何更加的讓自己信服? 在看activiti的文檔時發現外部的業務數據以Map的方式存在activiti的數據庫中, 那么activiti的設計者一樣會碰到同樣的問題. 通過查看源代碼以及其數據庫設計, 發現其將數據存入不同的字段. 但是在我的設計中, 我并沒有完全照搬Activiti的處理方式, 比如: 我沒有為布爾類型加單獨的字段, 而是以0或者1的方式存入LONG_VALUE里。

Activiti中提供便捷的查詢類, 如: ProcessInstanceQuery, TaskQuery. 其同時支持按照Process和Task相應的屬性數據進行查詢, 和Request/Snapshot以及property有很大的相似之處, 借鑒并根據實際情況實現自己的RequestQuery類, 支持各類復雜查詢, 如: 按照指定的property的name和value查詢, 支持or的查詢等。

Activiti的數據庫版本的自動升級. 當我們升級activiti的版本時, 其實我們只需要更新JAR的版本號, 而不用關心起底層數據庫是否需要升級, activiti在其表中會記錄數據庫scheme的版本號, 啟動時會自動判斷并根據需要自動更新數據庫. 這也是非常值得借鑒的地方, 尤其是當這個模塊被多個系統所使用時。

解析異構應用系統業務協同工作流平臺設計與實現

政務信息化進程中，各地區、各部門根據自身管理需求而引入的各種應用系統，在單個業務領域的管理上無疑有自己的特點，但由于它們無法面向整個的業務過程，各個系統之間也難以緊密集成，使得政府部門"環環相扣"的業務被這些分散的系統"分隔"開來，形成"應用孤島".政府部門不得不花費大量的人力、物力在不同的應用系統之間切換，從而造成運營效率低下和反應遲緩。隨著社會經濟的快速發展，"應用孤島"與業務協同的矛盾日益突出。IT行業的技術進步帶來政務效率提高的同時，也會帶來業務流程的變革。這種業務流程的變革也造成了原有應用系統無法使用或使用效率低下。

　　1 解決方案

　　針對"應用孤島"與業務協同的矛盾，本文以松散耦合、獨立于具體應用為指導思想，設計了電子政務可變業務協同工作流平臺，實現多業務應用系統之間的松散耦合，松散耦合，顧名思義就是比較松散點的耦合。是種分層次的耦合。一般項目都會要求，高內聚、低耦合。而松散耦合算是種低耦合。打個比方說MVC模式，分為三層，Module、View、Controller,一定意義上算是種松散耦合。在可視環境下進行業務流程配置，即可應對可變業務流程。在本工作流平臺基礎上，各機構的業務系統不需要修改代碼，只要在原有的系統上建立一個適配器模塊，便可以完成接入工作。不會影響原有的系統，實施成本降低，運營效率得到大幅提高。

　　本工作流模型設計基于應用集成技術和WCF服務技術，獨立于具體應用之外，提供流程分析、建模、重組、部署、管理、監控、評估、優化的環境。政務業務協同實施開發人員在不改變各部門現有管理模式的前提下，根據不同部門業務協同的需求，可以方便快速地利用這些工具和服務接口，在可視化的建模環境中，將異構應用系統按照流程驅動的方式整合在一起，實現業務流程管理與應用系統間的松散耦合。 

    2 可變業務協同工作流服務平臺原型系統

　　2.1 平臺架構

　　本工作流服務平臺搭建在。NET Framework 3.5之上，主要應用了Windows Communication Foundation、Window Workflow Foundation兩大前沿技術。作為電子政務、企業應用整合、信息共享、業務協同的服務平臺，工作流服務平臺系統具有良好的架構。　　

（1）業務流程處理框架

　　業務流程處理框架提供了設計、執行和管理業務流程的功能，并且有很強的可擴展性和可用性，它不僅可以用于實現自動化的流程管理，也可以作為基礎平臺搭建可人工干預的工作流服務。

　　（2）業務流程數據服務框架

　　業務流程數據服務框架采用集中式業務流程數據存儲，支持多種數據存儲介質。存儲業務流程及業務流程在執行過程中所有傳遞、產生的相關數據，如流程實例、收發數據、日志等。

　　（3）消息處理框架

　　消息處理管道框架負責將接收到的消息或要進行發送的消息，根據消息的處理規則（拆包、封包），實現消息的預處理操作序列。將對象與若干XML數據包進行轉換，以及對消息體進行加密、解密，提定編碼、解碼格式等。

　　（4）應用適配器框架

　　用于將專有的企業應用系統與標準技術連接在一起，包括各種主流應用適配器和標準通訊協議適配器，如File、HTTP、SMTP、Web Services、SAP、DBMS等。也可以把企業應用暴露的接口封裝成適配器，使傳統應用結構轉變成服務體系結構，保護已有應用投資。

　　（5）開發和管理工具

　　可視化的建模工具將確保開發人員迅速設計出適用于多種不同應用程序和技術手段的業務處理過程。

　　（6）安全、監控工具

　　提供相應的安全、監控工具以確保傳入和出站消息的安全、運行時信息和配置信息的安全以及能夠安全地與不同應用系統相集成；能夠實時監控流程的運行狀態、跟蹤流程處理結果、流程的訪問控制；應用集成單點登錄等。

　　2.2 工作流平臺組成

　　（1）工作流設計器

　　工作流設計器為可視化的流程設計工具，用戶通過拖放等方式繪制流程，并通過對環節的配置來實現環節操作、環節表單、環節參與者的配置。目前支持順序工作流和狀態機工作流兩種工作流類型。

　　（2）工作流引擎服務

　　工作流引擎服務是整個工作流服務平臺的，以Windows服務形式常駐內存，在系統開機時自動啟動，作為工作流的運行環境。主要由工作流實例運行、工作流日志服務、工作流持久化服務、工作流跟蹤服務等多個功能組成。工作流引擎服務同時承載工作流實例、活動和工作流運行時環境。

　　（3）工作流引擎管理服務

　　管理工作流引擎服務包括更新、備份、啟動、停止等功能操作，該服務是Windows服務，常駐內存。系統管理員可以通過"控制面板"中的"服務"子項，找到并控制該服務。工作流監控系統調用工作流引擎管理服務的接口方法，以友好的UI界面對工作流引擎服務進行管理，如更新、備份引擎等操作。

　　（4）工作流管理系統

　　管理與維護用于創建一個工作流所必要的信息組織，如工作流組織、工作流節點組織、項目組織、工作流前置組織、工作流模板等信息。實現對業務流程系統、應用集成系統、應用適配器系統的動態配置。

　　（5）工作流監控系統

　　流程監控系統通過提供圖形化的方式對工作流服務平臺的流程實例運行過程進行監控，包括流程實例狀態、日志、異常監測并提供性能。主要功能包括以下幾個方面：

　　工作流以及工作流實例的維護、跟蹤、控制、工作流版本更新等功能；提供日志管理與維護。工作流（Workflow），就是"業務過程的部分或整體在計算機應用環境下的自動化",它主要解決的是"使在多個參與者之間按照某種預定義的規則傳遞文檔、信息或任務的過程自動進行，從而實現某個預期的業務目標，或者促使此目標的實現".工作流概念起源于生產組織和辦公自動化領域，是針對日常工作中具有固定程序活動而提出的一個概念，目的是通過將工作分解成定義良好的任務或角色，按照一定的規則和過程來執行這些任務并對其進行監控，達到提高工作效率、更好的控制過程、增強對客戶的服務、有效管理業務流程等目的。盡管工作流從產生到現在已經取得了相當的成就，但對工作流的定義還沒有能夠統一和明確，不同學者從不同角度對工作流做出了不同的定義。

　　模擬流程運行生成性能，獲知流程運行的時間、效率及某個環節需要的時間周期等。

　　異常信息，可通過對異常信息來更正和處理流程操作。

　　（6）工作流通信接口

　　工作流通信接口用于工作流平臺的對外管理接口，以WCF服務方式暴露給外界調用，輸入相關的參數即可與工作流平臺進行通信，如創建工作流實例、發送、接收和工作流引擎服務交互數據等。

　　（7）前置系統

　　部署在機構應用前端，實現在不同的應用集成系統之間進行路由，使不同的應用集成系統之間實現互聯互通。打破孤立狀態，實現集中式管理。系統利用應用接口適配器組件提供的開發框架，以適應不同應用系統的連接。通過配置的方式實現與應用系統的連接，提高部署效率，降低實施成本。

　　3 應用

　　在區域電子政務可變業務協同中，以"企業養老金發放"為例，進行了應用試驗，效果良好。

　　3.1 養老保險金發放存在的問題

　　當前的養老保險金發放存在著重復享受養老保險待遇及起死回生冒領養老保險金的普遍問題。為解決此問題，必須借助電子政務技術手段，建立一個全省性的社會保障基金管理網絡，與民政部門、公安部門進行聯網溝通，實現企業和事業單位養老保險人員養老保險金發放的業務協同服務。通過跨部門、跨區域的聯合監管、協同辦理，及時了解信息，才能有效地堵塞企業和機關人員虛報、冒領養老保險金的現象。

　　3.2 解決方案

　　（1）業務協同部門

　　參與"企業養老保險人員養老金發放"業務協同任務的主要部門及其目前運行的業務軟件和數據庫。

　　"企業養老保險人員養老金發放"協同業務事項需要以上各個部門的業務系統及業務數據庫按照一定的流程進行協同配合，以完成人員信息數據的抽取、傳輸、比對和核查等操作。

　　（2）業務協同應用模型

　　根據"企業養老保險人員養老金發放"的業務協同需求，在工作流服務平臺定制"企業養老保險人員養老金發放"業務協同流程。通過在各部門系統前端部署的前置系統實現工作流服務平臺流程控制，實現各部門業務數據交換和業務功能協同，以達到聯合監管的目的。

　　（3）業務協同流程描述

　　監管堵塞企業和機關人員虛報、冒領養老保險金流程如圖4所示。社保局每月發放企業基本養老保險時，通過工作流服務平臺向公安廳全省人口信息系統提交核對人口死亡情況申請，公安廳全省人口信息系統自動響應勞動和社會保障部門請求，返回人口死亡核對情況。

　　社保局向財政工資發放系統核對請求提供政府直接退休金人員名單，財政工資統發系統自動響應該請求。社保局根據工作流服務平臺返回的信息，審核本月應發放的企業養老保險，并發放養老保險。

　　省財政部門編制預算時通過工作流服務平臺要求省社保局提供各單位繳交企事業基本養老保險的人員名單及相關金額、企事業基本養老保險發放金額以便合理安排下一年度預算。

　　（4）業務協同流程設計

　　根據"企業養老保險人員養老金發放"的業務協同需求，在本工作流服務平臺可視化環境中定制"企業養老保險人員養老金發放"業務協同流程。通過在各部門系統前端部署的前置系統實現工作流服務平臺流程控制，實現各部門業務數據交換和業務功能協同，以達到聯合監管的目的。利用工作流服務平臺提供的工作流流程設計器工具，在可視化的編輯環境中，設計跨部門業務協同整合工作流。

　　（5）業務協同流程服務的實施

　　通過工作流服務平臺提供的業務協同流程服務在異構的應用系統之間形成松耦合，實現信息交換、路由、分發、轉換等功能。業務協同主要以消息和異步通訊技術為手段、面向服務體系為框架、XML為信息描述語言，XML（Extensible Markup Language）即可擴展標記語言，它與HTML一樣，都是SGML（Standard Generalized Markup Language,標準通用標記語言）。Xml是Internet環境中跨平臺的，依賴于內容的技術，是當前處理結構化文檔信息的有力工具。擴展標記語言XML是一種簡單的數據存儲語言，使用一系列簡單的標記描述數據，而這些標記可以用方便的方式建立，雖然XML占用的空間比二進制數據要占用更多的空間，但XML極其簡單易于掌握和使用。實現各應用系統間的集成。

　　社保局的工作人員在每月養老金發放時間，登錄社保局內部的"企業基本養老保險系統",開啟"養老金發放"功能，就會通過部署在省社保局前端的前置系統，將請求發往工作流服務平臺，啟動"企業養老保險人員養老金發放業務工作流",實現社保局、公安廳、財政廳聯合審查的"企業養老保險人員養老金發放"業務協同工作。

　　本文依據WFMC提出的工作流模型，基于WCF與WWF兩大前沿技術，Windows Communication Foundation （WCF） 是由微軟發展的一組數據通信的應用程序開發接口，它是。NET框架的一部分，由 .NET Framework 3.0 開始引入，與 Windows Presentation Foundation 及 Windows Workflow Foundation 并行為新一代 Windows 操作系統以及 WinFX 的三個重大應用程序開發類庫。在 .NET Framework 2.0 以及前版本中，微軟發展了 Web Service （SOAP with HTTP communication），.NET Remoting （TCP/HTTP/Pipeline communication） 以及基礎的 Winsock 等通信支持，由于各個通信方法的設計方法不同，而且彼此之間也有相互的重疊性（例如 .NET Remoting 可以開發 SOAP, HTTP 通信），對于開發人員來說，不同的選擇會有不同的程序設計模型，而且必須要重新學習，讓開發人員在使用中有許多不便。設計與實現了可變業務協同工作流服務平臺，并在區域電子政務資源共享應用示范中應用，有效突破了"應用孤島".實踐證明，本工作流服務平臺具有安全、高效、低成本、易部署等特點，為可變業務協同工作流服務平臺提供了可行的解決方案。

「上述就是小編為大家整理的工作流平臺系統相關內容」

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。