汪 晴

(南京航空航天大學，江蘇 南京 211106)

0 引言

自2012年起，微信公眾號發(fā)展到今日，生態(tài)環(huán)境與早期已大不相同。國內(nèi)專業(yè)的公眾號大數(shù)據(jù)服務(wù)商“西瓜數(shù)據(jù)”發(fā)布的《2021年公眾號半年度生態(tài)趨勢調(diào)查報告》指出：當前已形成了以公眾號、視頻號和小程序三位一體的微信生態(tài)，微信公眾號運營者的觀念要不斷轉(zhuǎn)變，通過互動反饋機制來形成新的觀念。

隨著微信影響力的加深和讀者移動服務(wù)需求增強，微信公眾號已成為高校圖書館的主流移動業(yè)務(wù)平臺。如何緊跟微信公眾號發(fā)展趨勢，充分應(yīng)用好微信生態(tài)環(huán)境，本文提出基于微信公眾號二次開發(fā)，以圖書館服務(wù)工單系統(tǒng)開發(fā)為例，探討關(guān)鍵技術(shù)，以期為微信公眾號在圖書館移動服務(wù)中的應(yīng)用前景提供實踐參考。

1 研究現(xiàn)狀

微信服務(wù)模式分為訂閱型和服務(wù)型，曹慧敏等[1]選取國內(nèi)42所“雙一流”高校圖書館微服務(wù)平臺調(diào)查發(fā)現(xiàn)：42所高校圖書館都開通了微信公眾號，但僅有19所開通了服務(wù)號。圖書館微信公眾號普遍為訂閱型，即主要為讀者提供信息推送服務(wù)[2]；而服務(wù)型圖書館微信公眾號主要是通過第三方而非自行研發(fā)的移動應(yīng)用，通常是圖書館網(wǎng)站服務(wù)內(nèi)容到移動端的遷移：比如OPAC檢索、數(shù)據(jù)庫、電子書、座位預(yù)約、現(xiàn)實增強等傳統(tǒng)服務(wù)[3]。國外提出‘Micro Library’:包含傳統(tǒng)圖書館資源和服務(wù)所有內(nèi)容[4]。國內(nèi)以超星、匯文等公司為代表的移動圖書館迅速普及，但用戶不持續(xù)使用行為逐漸顯現(xiàn)[5]。

隨著微信小程序的推出，結(jié)合各個圖書館特色的輕量化的小型開發(fā)研究應(yīng)用有較大進展：廈門大學“Lib小助手”[6]通過業(yè)務(wù)操作日常記錄，實現(xiàn)圖書館日常監(jiān)管工作移動化；清華大學的“清華學者庫”[7]對學者成果進行可視化分析展示；山東師范大學的“排架游戲”[8]對讀者進行培訓，寓教于樂。便利化、低門檻是小程序應(yīng)用接地氣、得以快速發(fā)展的原因。但小程序在高校圖書館目前占比低[9]，且小程序應(yīng)用存在被遺忘率高，用戶黏性差，無法實時推送消息等問題。故本文選擇當前圖書館主流移動服務(wù)平臺微信公眾號，從微信服務(wù)的基本功能和特點出發(fā)，結(jié)合高校圖書館實際需求和應(yīng)用狀況，探討移動圖書館創(chuàng)新服務(wù)模式。

2 系統(tǒng)分析與設(shè)計

2.1 系統(tǒng)需求分析

隨著智慧化圖書館建設(shè)，圖書館中新型的資源和設(shè)備越來越豐富，需要信息化的手段來自動化管理。整個流程中最關(guān)鍵的就是問題的上報、處理和反饋，這就需要一套新型的服務(wù)工單系統(tǒng)來盡量自動化完成這些關(guān)鍵環(huán)節(jié)。李書欽等[10-11]提出基于微信企業(yè)號的高校移動辦公平臺，但該辦公平臺體系龐大，無法為讀者提供問題提出和跟蹤處理的服務(wù)平臺。陳俊杰等[12]提出了基于微信小程序提升管理工作效率，但僅限于內(nèi)部OA，對于讀者移動服務(wù)訴求沒有涉及。

因此，本文提出在微信公眾號的平臺之上，實現(xiàn)實時推送的圖書館服務(wù)工單系統(tǒng)，用于圖書館服務(wù)任務(wù)傳達，記錄、處理、跟蹤一項工作的完成情況，用來創(chuàng)建、掛起、解決讀者、內(nèi)部工作人員提交的事務(wù)請求。

2.2 系統(tǒng)架構(gòu)設(shè)計

圖書館服務(wù)工單系統(tǒng)服務(wù)于用戶、處理人員、運維人員等角色，由賬號和鑒權(quán)、前端頁面、運維面板、狀態(tài)通知以及數(shù)據(jù)庫和對象存儲等模塊組成(見圖1)。

圖1 圖書館服務(wù)工單系統(tǒng)架構(gòu)

系統(tǒng)的技術(shù)方案采用B/S架構(gòu)，前端使用Vue+Vant組件庫開發(fā)，后端使用Go+Jupyter框架開發(fā)，數(shù)據(jù)庫選擇MySQL+Gorm，對象存儲采用騰訊COS。

2.2.1 前端展示模塊

前端展示模塊負責向用戶展示數(shù)據(jù)，主要包括工單列表頁面和工單詳情頁面兩類。工單列表頁面負責展示個人提交的或者需處理的工單列表，按照時間等順序排列，方便用戶查看。

在技術(shù)方案中，前端展示模塊采用Vue+Vant框架。Vant是開源的一套輕量、可靠的移動端組件庫，具有組件豐富、使用簡便，運行時性能佳、質(zhì)量高等優(yōu)點。

2.2.2 后端運維面板

運維面板負責給運維人員提供運維管理和數(shù)據(jù)統(tǒng)計服務(wù)，包括賬號管理、工單管理和統(tǒng)計報表生成。賬號管理主要負責學校在職人員的信息同步，包括部門架構(gòu)管理、人員信息管理等，以及部分特殊賬號的人工管理。工單管理主要負責部分特殊工單的人工管理。統(tǒng)計報表生成能夠根據(jù)時間、部門、接收人，以及工單的關(guān)閉率、滿意度等多個維度輸出統(tǒng)計報表，便于發(fā)現(xiàn)問題，改進工作質(zhì)量。

2.2.3 數(shù)據(jù)庫和對象存儲

數(shù)據(jù)庫和對象存儲負責保存工單的詳細信息，包括工單基本信息、工單附件和統(tǒng)計數(shù)據(jù)。技術(shù)方案中，數(shù)據(jù)庫選型為應(yīng)用最廣泛的MySQL數(shù)據(jù)庫，并選擇Gorm作為ORM庫與數(shù)據(jù)庫交互，其優(yōu)點是使用便捷、性能良好，兼容性好、支持多種數(shù)據(jù)庫。Gorm初始化后，會自動根據(jù)此類型生成MySQL表結(jié)構(gòu)。

此外，因為工單中有照片和視頻等多媒體信息，需要對象存儲來管理這些多媒體數(shù)據(jù)。本系統(tǒng)采用騰訊COS對象存儲的技術(shù)方案，并封裝了對象存儲的通用接口，便于后續(xù)適配其他對象存儲的接口，例如Minio、本地磁盤等。

2.3 微信公眾平臺關(guān)鍵技術(shù)應(yīng)用

2.3.1 賬號和鑒權(quán)：智能識別用戶角色

賬號和鑒權(quán)模塊，與現(xiàn)有圖書館公眾號使用相同的賬號認證體系，無需二次登錄，并以只讀方式對接校圖書館內(nèi)部的部門和人員信息，進行角色鑒權(quán)，確保每個用戶只能看到角色相關(guān)的數(shù)據(jù)。

在技術(shù)方案中，把鑒權(quán)封裝為一個通用的中間件函數(shù)，在提交、查看或者處理工單時使用這個中間件函數(shù)進行鑒權(quán)。鑒權(quán)邏輯如下：

(1)先嘗試從Context緩存中獲取，如果成功則返回。

(2)否則再從Cookie中獲取，如果成功，保存到Context緩存中，并返回。

(3)如果從Cookie獲取失敗，最后再通過微信code獲取賬號信息。微信公眾號提供了獲取用戶信息的HTTP接口，包括對AppID和AppSecret的校驗、鑒權(quán)等，安全性有相同保障。這里有兩點需要特別注意：AppSecret是應(yīng)用密鑰，涉及此服務(wù)的相關(guān)權(quán)限，安全性要求較高，只能保存在服務(wù)端，不能傳遞到前端瀏覽器，更不能寫死在前端代碼中；所有HTTP參數(shù)都可以通過query參數(shù)形式傳給服務(wù)器，因此需要使用url.QueryEscape進行轉(zhuǎn)義。

(4)鑒權(quán)成功后通過ctx.SetCookie設(shè)置到前端瀏覽器中，無需頻繁調(diào)用微信服務(wù)鑒權(quán)。

2.3.2 消息推送：實時掌握工單狀態(tài)

圖書館服務(wù)工單系統(tǒng)的使用對象主要是學校師生以及圖書館工作人員，一般都會使用微信做日常聯(lián)絡(luò)工具，狀態(tài)通知模塊負責在工單狀態(tài)發(fā)生變化時實時通知到相關(guān)人員。選擇微信公眾號的模板消息作為技術(shù)方案，具有用戶體驗好、使用范圍廣、開發(fā)成本低等優(yōu)勢。預(yù)定義的模板消息內(nèi)容如下：

標題 服務(wù)工單提醒

行業(yè) IT科技 - IT軟件與服務(wù)

詳細內(nèi)容 {{first.DATA}}

編號：{{keyword1.DATA}}

來自：{{keyword2.DATA}}

摘要：{{keyword3.DATA}}

{{remark.DATA}}

本系統(tǒng)把發(fā)送模板消息封裝為通用的函數(shù)庫，便于后續(xù)復(fù)用：

func WXSendMsg(touser string, data map[string]interface{}) {

b, _ := jsoniter.Marshal(data)

//省略部分加密和編碼內(nèi)容

url := fmt.Sprintf("http://x.nuaa.edu.cn /sendMsg?touser=%v&_time=%v&pushMsgtype=%v&push_enc=%v&pushData=%v", touser, time, type, end, b2)

resp := map[string]interface{}{}

util.HTTPGetJSON(url, &resp)

針對高校引入實時推送服務(wù)，筆者提出以下建議：(1)在引入實時推送服務(wù)時，需要慎重控制提醒批次。實時推送服務(wù)的目的是及時提醒相關(guān)人員對變化的狀態(tài)進行響應(yīng)，如果過度提醒，可能會適得其反。(2)在使用實時推送服務(wù)時，需要謹慎管理推送服務(wù)的應(yīng)用密鑰。應(yīng)用密鑰一般分為AppKey和SecretKey，前者用于標識推送服務(wù)的應(yīng)用信息，后者用于應(yīng)用的身份鑒定。如果密鑰泄露，一方面可能給服務(wù)工單系統(tǒng)帶來安全隱患，另一方面推送服務(wù)會禁用該應(yīng)用，導(dǎo)致推送功能不可用。

2.3.3 二維碼：隨手記錄故障設(shè)備

對每個設(shè)備進行編號，并生成唯一的二維碼。在出現(xiàn)故障、用戶提交工單時，可以通過掃描二維碼來記錄具體是哪個設(shè)備發(fā)生故障，提升故障解決效率。

首先在.wxml寫一個text組件，通過點擊這個text來實現(xiàn)掃碼功能：

{{scanCode}}

其中bindtap是給text綁定的點擊事件；{{scanCode}}給這個text顯示文本，賦值的數(shù)據(jù)在.js文件的data里初始化。.js內(nèi)容：

Page({

data: {

scanCode: '掃碼',

},

scanCodeEvent: function () {

var that = this;

wx.scanCode({

onlyFromCamera: true,

success(res) {

console.log("掃碼成功：" + JSON.stringify(res))

//掃碼成功后在此處理接下來的邏輯

}

})

},

})

掃碼中有幾個可配置的參數(shù)注意下：

onlyFromCamera：默認是false，允許從相機和相冊掃碼；如果設(shè)置為true，則只允許從相機掃碼；

scanType：['barCode', 'qrCode']數(shù)組類型，這個字段來設(shè)置掃碼類型；

success：掃碼接口調(diào)用成功的回調(diào)函數(shù)；

fail：掃碼接口調(diào)用失敗的回調(diào)函數(shù)。

前端將原始數(shù)據(jù)發(fā)回給服務(wù)端存儲，服務(wù)端記錄為故障設(shè)備ID。

2.3.4 GPS：自動識別故障場地

在沒有二維碼的設(shè)備或場所，我們通過GPS信息獲取大概的地理位置，方便運維人員定位和分析故障。首先獲取用戶的地理位置，需要在app.json里聲明permission字段，要告訴用戶地理位置的作用是什么：

"permission": {

"scope.userLocation": {

"desc": "您的位置信息將用于工單系統(tǒng)獲取故障位置信息，便于定位故障"

}

}

.js中獲取地理位置的代碼：

wx.getLocation({

type: "wgs84",

success (res) {

}

})

參數(shù)type：wgs84返回gps坐標，gcj02 返回可用于wx.openLocation的坐標；前端會把位置結(jié)果通過接口上報到服務(wù)端，供運維人員定位故障使用。

2.3.5 拍照：真實還原故障現(xiàn)場

通過二維碼和GPS可以定位故障位置，但是具體的故障信息如果有直觀的照片，就能輕松描述清楚，還原第一現(xiàn)場。

調(diào)用相機，需要首先在.wxml頁面中生命carmera元素：

拍照

在.js文件中調(diào)用接口進行拍照：

const ctx = wx.createCameraContext()

ctx.takePhoto({

quality: 'high',

success: (res) => {

this.setData({

src: res.tempImagePath

})

}

})

前端拿到照片數(shù)據(jù)后，通過HTTP接口把照片上傳到后端的對象存儲服務(wù)中，并拿到對象存儲返回的文件ID，再在提交工單時把對象存儲ID關(guān)聯(lián)到工單信息，供運維人員分析故障。

3 應(yīng)用效果

3.1 實現(xiàn)效果

圖書館服務(wù)工單系統(tǒng)主要面向用戶、圖書館工作人員、運維人員等角色，不同角色看到的內(nèi)容會有所不同，收到的提醒信息也有所不同，實現(xiàn)效果如圖2所示。

圖2 待辦工單列表和新工單提醒

3.2 應(yīng)用數(shù)據(jù)

圖書館服務(wù)工單系統(tǒng)增加實時推送提醒，自上線后各項服務(wù)質(zhì)量提升明顯：平均問題響應(yīng)時間從46.5小時降低到5.7小時，平均問題關(guān)閉時間從75.2小時降低到18.6小時，年度問題閉環(huán)率從63.90%提升到86.1%。詳細數(shù)據(jù)如圖3所示。

圖3 圖書館服務(wù)工單系統(tǒng)應(yīng)用效果

4 結(jié)語

本文以圖書館服務(wù)工單系統(tǒng)為例，展現(xiàn)了基于微信公眾平臺的多個開發(fā)關(guān)鍵技術(shù)和應(yīng)用場景，以期為其他高校圖書館移動服務(wù)建設(shè)拋磚引玉。實踐證明，充分利用微信公眾號提供的靈活豐富的API接口，結(jié)合圖書館業(yè)務(wù)需求，能夠?qū)崿F(xiàn)圖書館移動服務(wù)創(chuàng)新，提升管理效率，符合智慧化建設(shè)發(fā)展思路。

隨著移動技術(shù)的發(fā)展，筆者也將繼續(xù)探索嘗試更多應(yīng)用場景，并充分利用系統(tǒng)積累的數(shù)據(jù)，進行統(tǒng)計與分析，填補圖書館資源管理工作統(tǒng)計數(shù)據(jù)的空白；發(fā)掘圖書館資源建設(shè)中的隱藏問題，為后續(xù)建設(shè)提供數(shù)據(jù)決策依據(jù)。