韓欣怡，高銘，靳海濤

（北京信息科技大學，北京，100020）

0 引言

目前高校及科研院所大都已經(jīng)在一級部門間啟用或開始啟用信息化的溝通協(xié)作系統(tǒng)，但由于存在較多歷史遺留問題，并沒有實現(xiàn)完全的信息化。同時，一級部門下設(shè)的二級機構(gòu)之間，信息化協(xié)作水平較低，尚處于使用郵件在同一份文檔內(nèi)進行溝通協(xié)作的傳統(tǒng)模式。隨著去年新冠疫情爆發(fā)，線上辦公的普及，上述傳統(tǒng)模式轉(zhuǎn)為云文檔在線協(xié)作，部分提高了溝通效率，但依然存在操作復雜、流程繁復等弊端。

以高校GPU資源申請場景為例：申請資源的用戶需要填寫在線收集表，申請記錄會自動收集到申請記錄表格中，每一條記錄都包括用戶的基本信息（姓名，工號等），申請的資源的詳情，以及申請的處理進度。資源管理員需要定期查看申請記錄表格，并根據(jù)用戶的申請需求和資源的實際情況，對用戶的申請做出相應的處理。用戶想要了解申請進度，需要自行查看申請記錄表格中的處理狀態(tài)，且表格并未進行有效的權(quán)限管理。部門間的高溝通成本和低協(xié)作效率會放大上述問題的影響，降低基礎(chǔ)設(shè)施的使用效率，導致資產(chǎn)的無形損失。

1 工單系統(tǒng)分析

■ 1.1 工單系統(tǒng)發(fā)展現(xiàn)狀

客服工單管理系統(tǒng)目前在國內(nèi)外技術(shù)都比較成熟，基本涵蓋工單管理、客戶管理、知識庫管理、在線客服、呼叫中心等功能模塊。為了更好的獲取客戶反饋信息，實時追蹤和處理解決客戶反映的問題，21世紀初，美國多家公司致力于開發(fā)客戶管理、工單管理、統(tǒng)計報表等服務，幫助公司及時獲取客戶所需，解決客戶急需解決的問題或意見與建議[1]。國內(nèi)后續(xù)也有很多企業(yè)致力于幫助開發(fā)者和企業(yè)可以更快速低成本的搭建自己的客戶服務系統(tǒng)，使用戶的問題可以更方便的提交和反饋。其中的工單系統(tǒng)將工單作為部門協(xié)同、任務流轉(zhuǎn)記錄、提升效率、改善和提升服務體驗的工具，在公司內(nèi)部各個部門進行流轉(zhuǎn)處理[2]。經(jīng)過我們查閱資料等方式，總結(jié)為主要以下三個問題：（1）用戶分級操作不明確：學生無法通過自主填寫信息完成資源申請；（2）用戶申請狀態(tài)難追蹤：在申請記錄非常多的情況下，用戶就難以在眾多的記錄中查找自己的申請記錄，且不方便管理員更新申請的處理狀態(tài)；（3）流程中溝通成本巨大：用戶申請占用大資源需要相關(guān)領(lǐng)導審批，但用戶無法通過填寫一張簡單的申請表格來描述自己對大資源的需求，還需要自行聯(lián)系資源管理員，級級上報，等待審批，最后才能為用戶分配資源。可見，巨大的溝通成本導致的特殊申請的效率極其低下。

■ 1.2 工單系統(tǒng)需求分析

由于本系統(tǒng)最主要研究的是各高校以及科研院所中不同層級資源申請的問題，設(shè)計并開發(fā)一款適用于高校及科研院所內(nèi)部使用的工單管理系統(tǒng)，旨在高校及科研院所之間的協(xié)同配合工作，使得資源管理員可快速響應各層級用戶的申請，解決用戶問題。我們設(shè)計的工單系統(tǒng)是面向不同級別用戶申請資源的一種區(qū)別于線下傳統(tǒng)的線上系統(tǒng)，針對于不同級別的用戶，如普通用戶與管理員，而普通用戶又有級別的區(qū)別，這些不同的級別也都對應著不同的工單流轉(zhuǎn)方式以及所需要的審批工程。圖1是工單系統(tǒng)所要完成的基本功能。

圖1 工單系統(tǒng)功能圖

2 工單系統(tǒng)基本設(shè)計

該工單系統(tǒng)的前后端是分離獨立的，采用了client/server模式，以及MVC的三層設(shè)計模式[3]，前后端交換數(shù)據(jù)使用的是JSON格式[4]；系統(tǒng)后端采取Java語言寫，使用java web技術(shù)開發(fā)，MyBatis-Plus技術(shù)進行封裝，基于的是SpringBoot2框架[5]、微服務架構(gòu)；系統(tǒng)前端分為兩個大的模塊，其中之一是管理員后端，另外一個模塊即普通用戶進行申請的小程序前端，管理員后端使用了Vue.js框架技術(shù)，Vue.js框架能快速的搭建與用戶交互的環(huán)境，使用戶有良好的交互式體驗；數(shù)據(jù)庫的實現(xiàn)采用了MySQL數(shù)據(jù)庫，是安全、跨平臺、高效的數(shù)據(jù)庫系統(tǒng)，與我們系統(tǒng)的后端Java語言緊密結(jié)合。

■ 2.1 后端基本設(shè)計

后端表現(xiàn)層（Web層）是與Service層接口交互的層次，主要負責接受客戶端的請求，向客戶端發(fā)送請求結(jié)果。通過前端的表現(xiàn)層調(diào)用方，即后臺管理系統(tǒng)前端（Browser）、微信小程序前端、微信服務器這三部分前端調(diào)用，通過HTTP協(xié)議調(diào)用JSON向表現(xiàn)層傳參，,之后表現(xiàn)層再把自己接受到的數(shù)據(jù)通過Service層接口傳到Service層[6]。

后端服務層（Service層）設(shè)計是與數(shù)據(jù)庫進行直接交互的層級，表現(xiàn)層接受到的數(shù)據(jù)通過接口調(diào)用，傳給Service層對外暴露的接口，通過接口數(shù)據(jù)即被傳到了服務層，服務層的需要通過MDS加密類等工具實現(xiàn)加密數(shù)據(jù)、格式化日期數(shù)據(jù)等功能，將表現(xiàn)層傳過來的數(shù)據(jù)進行統(tǒng)一的格式化處理，格式化處理后的數(shù)據(jù)會通過數(shù)據(jù)持久層接口傳送到數(shù)據(jù)庫。

后端數(shù)據(jù)持久層，即直接與數(shù)據(jù)庫進行交互的層級，這部分操作是通過標準的Java應用編程接口向數(shù)據(jù)庫傳入需要存儲的數(shù)據(jù)[7]。

■ 2.2 前端視圖層設(shè)計

系統(tǒng)前端視圖層總共有四個模塊，即消息模塊、工單模塊、審批模塊、用戶信息模塊，這四個模塊分別調(diào)用控制層中的消息控制層接口（MessageController）、工單管理控制層接口（WorkController）、審批工單控制層接口（ApprovalController）、用戶控制層接口（AuthController）這四個控制層。

2.2.1 用戶信息模塊

用戶信息模塊中，分為用戶信息注冊和用戶登錄兩個主要功能。其中用戶信息注冊是指在首次使用此工單系統(tǒng)時，用戶需要填寫自己的個人信息，主要是明確信息的身份等級。以圖2(a)進行小程序前端注冊頁面的展示。用戶登錄功能，傳入微信login()接口獲取的臨時代碼，服務器返回一個有時限的登錄token（令牌），需要客戶端保存好，每次訪問接口時都要將token通過HTTP請求頭發(fā)送到后端，作為登錄的憑證。token中包含用戶id，學號和工號（如果是學生就攜帶學號，教師就攜帶工號），也就是說對于首次登錄的用戶，會讓其填寫基本的個人信息，主要是為了獲取用戶的身份等級，以確認用戶提交工單后自動流入的節(jié)點，但登錄時可能會有一些錯誤登錄的情況，有專門的錯誤代碼返回一些錯誤的信息，并且在頁面上給予用戶提示。同一個用戶在后續(xù)登錄系統(tǒng)的過程中，會一直攜帶著被保存的token，也就意味著，后續(xù)用戶打開工單系統(tǒng)小程序?qū)⒛茏詣拥侨胂到y(tǒng)。

2.2.2 消息模塊

消息模塊中，使用前端小程序的用戶可以發(fā)送消息給負責審批的管理員，后臺的管理者也可以將審批的意見反饋給用戶，調(diào)用的都為發(fā)送信息接口，并且普通用戶以及管理員都可以通過消息詳情接口的調(diào)用去“查看消息詳情”，“收件箱列表顯示”和“發(fā)件箱列表顯示”是通過“消息收件箱接口”和“消息發(fā)件箱借口”來獲取到具體消息列表的，以上消息模塊所完成的功能由控制層中的消息控制層來統(tǒng)一調(diào)度，并且每一條未讀的工單信息都會標有“未讀”，圖2(b)是前端小程序的消息模塊頁面。

2.2.3 工單模塊

在工單模塊中，分別有工單列表顯示、發(fā)起工單和查看工單詳情這三個具體的功能。工單列表顯示即通過調(diào)用工單列表借口，來查看用戶申請的歷史工單和在審工單等；用戶發(fā)起工單即在申請資源時，要填入自己想要申請的具體內(nèi)容（即標題），還要填寫自己的留言（即申請資源的原因和用途），在選擇流程中，可以選擇上傳截圖證明，文件證明或是聊天記錄，填寫完以上所有必填項之外，提交按鈕會變?yōu)樗{色，最后發(fā)送請求給接口/workOrder/save，后端在工單表中新增工單記錄，并根據(jù)工單流程自動在審批關(guān)系表中新增記錄，表示工單已經(jīng)流入第一個審批節(jié)點，查看工單詳情即可以通過調(diào)用工單詳情接口來查看工單詳情來查詢工單的具體審批情況。

2.2.4 審批模塊

審批模塊中，分別有審批工單列表、查看工單詳情，以及審批工單這三個部分的功能，在審批工單列表中，調(diào)用審批工單列表接口可以看到所有工單的審批狀態(tài)；在審批工單時在進行工單的審批，管理員審批需要經(jīng)過幾個節(jié)點，即不同的層級，節(jié)點轉(zhuǎn)換的觸發(fā)條件是：審批人員點擊“通過”按鈕。后端刪除目前審批表中的相關(guān)記錄，并查詢流程表獲取下一個節(jié)點信息，在審批表中新增記錄，表示工單已經(jīng)流入下一個節(jié)點。同時將上一個節(jié)點的審批信息全部記錄到審批記錄關(guān)系表中，圖2(c)是查看工單申請批詳情界面。

圖2

■ 2.3 后臺網(wǎng)頁端頁面設(shè)計

在工單小程序的后端管理平臺中，網(wǎng)頁的頁面主要包括五個具體頁面。首先是管理員的注冊登錄頁面，管理員可以選擇以用戶名密碼的方式進行登錄，也可以通過微信直接掃碼登錄頁面，并且只有管理員的登錄才是有效的，其它普通用戶無法成功登錄[8]。主要的功能性設(shè)計包括管理模塊、用戶模塊等，管理員可以對任一工單或是用戶做右側(cè)Actions中的任意操作，如圖3以工單管理具體頁面作為主要展示：其中ID號是依照工單申請的順序依次排列的，工單標題為自己填寫，工單的創(chuàng)建時間是根據(jù)系統(tǒng)自帶的時間而定，工作狀態(tài)分為三種：即在審、不通過和順利通過，其中在審是指此工單已經(jīng)進入審批階段，并且目前已經(jīng)通過的節(jié)點沒有其他的問題；不通過是指某一個節(jié)點，管理員在審批的時候拒絕了用戶的CPU申請，工單申請中途夭折，所以該工單的狀態(tài)為不通過；狀態(tài)為順利通過時是指，此工單固有的審批節(jié)點流程已經(jīng)進行完畢，即完成了此類型工單系統(tǒng)所需要的工單流程。

圖3 后端工單管理頁面基本展示

3 數(shù)據(jù)庫實現(xiàn)

數(shù)據(jù)庫的設(shè)計在我們工單系統(tǒng)的開發(fā)中占了非常重要的地位，之所以夠有效的存儲數(shù)據(jù)，滿足各類用戶的應用需求，那么良好的數(shù)據(jù)庫設(shè)計可以節(jié)省的存儲空間，保證所需存儲數(shù)據(jù)的完整性，減少數(shù)據(jù)冗余的情況[9]。我們設(shè)計的數(shù)據(jù)庫主要包含了以下四個模塊的數(shù)據(jù)，分別是工單信息、用戶信息、權(quán)限管理和流程信息。工單信息包括了我們設(shè)計的工單表、已經(jīng)審批完成的工單歷史表，正在進行管理員審批的工單狀態(tài)表、還有工單審批記錄表，也就是說工單信息覆蓋了工單從開始填寫到審核完畢的全過程；用戶信息包括用戶表、學院表、專業(yè)表和部門表，涵蓋了用戶信息的各類屬性；權(quán)限管理模塊包括權(quán)限表、角色表，是根據(jù)用戶的不同等級來劃分權(quán)限，也對應著不同的角色；流程信息包括了流程表、流程節(jié)點表，根據(jù)不同的角色使其進入指定的節(jié)點流程。

對于一些工單申請的用戶，在后端的數(shù)據(jù)庫中其基本的信息都有記錄，管理員可以隨時在后端數(shù)據(jù)庫中管理用戶的基本信息或是對表中的數(shù)據(jù)進行查詢、刪除或是更改。

4 結(jié)束語

我們通過采取client/server模式完成了前后端的環(huán)境架構(gòu)、建立GitHub倉庫并使用Java語言編寫前后端代碼，并采用MySQL數(shù)據(jù)庫完成數(shù)據(jù)庫的構(gòu)建和實現(xiàn)，順利地開發(fā)了基于小程序的DevOps工單系統(tǒng)，可以用于各個高校與科研院所的線上工單申請流程。目前已經(jīng)基本解決了目前線下各個層級間溝通成本高，時間耗費大，用戶申請時體驗感欠佳等各方面的問題，之后我們也會持續(xù)對此次開發(fā)的工單系統(tǒng)進行實時測評，并對用戶提出的問題進行及時地改善與維護。