韓欣怡，高銘，靳海濤

（北京信息科技大學(xué)，北京，100020）

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1 用戶信息模塊

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

2.2.2 消息模塊

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

2.2.3 工單模塊

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

2.2.4 審批模塊

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

圖2

■ 2.3 后臺(tái)網(wǎng)頁端頁面設(shè)計(jì)

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

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

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

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

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

4 結(jié)束語

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