今年6月初，接到客戶關於“集團客戶事業部大客戶專案訂單”新需求，其業務設定了正常流程和升級流程（是指流程參與者增加了領導，對應的表單發生很小變化）。當時的解決方案是對錶單做程式設計處理，解決差異性問題。

今天，與開發人員討論設計時，發現專業資訊應用類業務的管理，也面臨類似情況，例如安全生產管理資訊、資訊專欄中，非流程類的業務，需要填寫多張表單。

到此，對能力平臺的設計應該做點兒調整，增加允許一個業務對應多個表單（也是具體某業務）。

設計方案見下文描述。

業務開始

• 業務目錄：為業務分類及具體業務的樹形結構，葉子節點一般為業務表單名稱；
• 業務申請單：為填寫業務資訊的申請表單，表單可以在多個流程上流轉。

業務資訊模型

業務模型描述

• 資訊類業務，例如資訊專欄，由多組資訊構成，每組資訊多有不同，在這裡把這種資訊看作表單式業務。因此，資訊專欄/應用由多個通用資訊或表單構成。
• 業務流程，一個業務可以對應多個表單，每個表單所對應的業務又可以拆分為多個獨立的流程。

資料庫關係模型

注：表單文件儲存在文件型資料庫（MongoDB）中，不在此體現。

關於業務分類管理

業務分類管理不是固定的，從軟體系統角度來看是可以任意變化的，在設計上使用屬性表的模式管理。

/*屬性表*/
create table BPM_MANAGER.SM_ATTRIBUTE
(
  ATTR_ID      VARCHAR2(50) not null,
  ATTR_TYPE_ID VARCHAR2(50) not null,
  ATTR_VALUE   VARCHAR2(30) not null,
  ATTR_CODE    VARCHAR2(30),
  SORT_NO      INTEGER
 
,
  STATUS_SIGN  INTEGER default 1 not null,
  ATTR_DESC    VARCHAR2(50)
)

/*屬性型別表*/
create table BPM_MANAGER.SM_ATTRIBUTE_TYPE
(
  ATTR_TYPE_ID VARCHAR2(50) not null,
  TYPE_NAME    VARCHAR2(30) not null,
  TYPE_CODE    VARCHAR2(30),
  STATUS_SIGN  INTEGER default 1 not null,
  DESC_MEMO    VARCHAR2(200)
)

資料使用情況舉例：

• 屬性型別定義

• 屬性定義

業務資訊展現

業務資訊展現分為業務定義資訊展現和業務執行例項資訊展現兩種情況。

業務資訊定義展現

業務資訊展現介面如下圖所示，由業務基礎資訊、表單、流程列表、流程評價（也叫業務評價）構成。其中，表單可能存在多個，那麼對應的流程列表隨著表單而變化。

注：上圖中，遺漏附件，用於儲存業務介紹文件（來源於業務開發時的需求），包括業務描述文件、流程圖、表單等。因此，設計時把文件及圖做為附件方式進行展現。

展現操作過程參考如下順序圖。

注：業務資訊定義包含“業務全生命週期管理”，支援檢視歷史版本。

業務例項展現

設計對比分析

原設計

參照上述描述，原設計是業務下包括表單（1對1關係）和流程（1對多或1對0關係）。

在此設計模型下，針對開篇的需求，開發人員的解決方案是編碼控制表單。相當於個性化處理。

注：原設計編碼實現情況，業務資訊展現內容不完整，偏離設計較大；開始業務申請部分，入口偏離設計較大，而填寫表單及啟動流程部分屬於核心功能，大部分實現，且基本不受影響。

設計對比分析

注：專業資訊是指無工作流的填寫表單的業務，例如安全資訊管理。

結論

通過上述分析，在業務流程部分編碼階段、資訊管理設計階段，為了滿足使用者需求，此設計變更方案是比較合理，且工作量變動不大，可以進行後續設計討論。

參考：

2015年6月30日