微信生態(tài)下文獻傳遞機器人研發(fā)及其應用

朱玉強

微信公眾平臺擁有龐大的用戶群，成為圖書館移動服務的重要載體。至2019年4月13日，微信公眾號中帶“圖書館”字樣的有3218個，其中550個通過了微信官方認證[1]。42所“雙一流”高校圖書館均開通了微信公眾號，服務包括本館信息、借閱查詢、閱讀推廣、資源推廣、續(xù)借預約、信息素養(yǎng)教育、學科支撐及專利信息等。本文圍繞微信公眾平臺編寫文獻傳遞機器人，用戶僅需向公眾號發(fā)送一條消息就可在移動或PC端獲取電子文獻全文并閱讀，方便用戶使用并可提高圖書館電子資源利用率。

1 相關研究與實踐

國內外對圖書館移動服務的研究主要集中于移動服務類型、提供途徑、營銷手段及質量監(jiān)控等。郭亞軍等[2]調查美國143家城市公共圖書館，發(fā)現(xiàn)97%的圖書館提供移動網(wǎng)站或APP，服務于參考咨詢、位置導航等。王穎純等[3]考查WAP、APP、微信公眾平臺和微博在我國31家省級公共圖書館應用情況，發(fā)現(xiàn)被調查圖書館都開通了微信公眾平臺，開通APP的有27家、微博24家、WAP14家，除微博外主要開展“個人圖書館”移動服務。張曉青[4]考查國內“985工程”高校圖書館，發(fā)現(xiàn)存在門戶網(wǎng)站沒有采用自適應網(wǎng)頁設計、WAP與APP同質化、沒有基于微信的移動門戶等問題。何丹丹等[5]利用CiteSpace挖掘我國圖書館移動服務領域研究熱點，將其歸納為信息技術研究、應用服務創(chuàng)新研究和服務質量研究。

目前文獻傳遞業(yè)務面臨巨大挑戰(zhàn)。陸堯等[6]發(fā)現(xiàn)OCLC文獻傳遞服務量自2011年至2015年呈下降趨勢。梁南燕等[7]、羅鈞等[8]、徐飛等[9]分別撰文提到CASHL、CALIS和BALIS文獻傳遞量下滑已成不爭事實。面對挑戰(zhàn)，CASHL、國家科技圖書文獻中心、CALIS分別于2016年1月、4月和6月相繼開通微信平臺提供文獻傳遞移動服務，服務繼承了PC時代只面向文獻機構、不應對讀者個人請求的傳統(tǒng)。

陳建紅[10]發(fā)現(xiàn)高校圖書館對電子資源推廣不力，造成大學生對電子資源不了解，更談不上利用。常定姁[11]指出當前電子資源亟待推廣，介紹了武漢大學圖書館利用微信公眾平臺開展電子資源推廣活動案例。呂玉龍[12]介紹了上海理工大學圖書館利用PHP技術自行開發(fā)文獻傳遞系統(tǒng)和館際互借管理系統(tǒng)實例，彌補CALIS、CASHL和NSTL三大文獻傳遞系統(tǒng)只對圖書館開放、不直接面向讀者的不足，并允許用戶免費申請圖書館已購買電子資源。齊曉峰[13]介紹了華東理工大學圖書館利用網(wǎng)盤構建稀缺文獻數(shù)據(jù)庫展開文獻檢索與傳遞服務。歐陽劍等[14]采用自動代理機制實現(xiàn)移動終端對電子資源的檢索與文獻傳遞。

相對以往文獻中的PC或移動端開發(fā)實踐以及商業(yè)化遠程訪問系統(tǒng)，本文允許用戶通過使用微信發(fā)送一條消息的簡單操作即可獲取文獻全文，文獻傳遞員只需登錄微信公眾平臺并運行機器人程序，雙方操作更便捷。機器人除可獲取本機構資源，還可擴展到通過文獻傳遞員遠程訪問可獲取的機構外資源，用戶無需關注機構與機構之間傳遞詳情，充分體現(xiàn)了移動服務的便利性與易獲取性。

2 系統(tǒng)設計思路及實施方案

2.1 系統(tǒng)功能架構

系統(tǒng)總體目標為：用戶通過微信提交文獻請求，PC端文獻傳遞機器人自動獲取相關文獻并將其發(fā)送至用戶郵箱，用戶可在移動或PC端接收并閱讀文獻，推進圖書館電子資源移動服務。系統(tǒng)不搭建第三方服務器，不動用微信高級接口，利用微信公眾平臺開展近乎全自動的工作。

用戶使用微信向公眾號發(fā)送所需文獻的標題等消息，編寫PC端文獻傳遞機器人，周期性檢測微信公眾平臺有無新消息，根據(jù)有無特征字判斷新消息是否為文獻傳遞請求。有效性檢測包括：用戶是否合法；用戶有否超出當日請求限制，等等。對有效請求，程序通過操作網(wǎng)頁文檔對象提示用戶“已接單”。自動回復中包含操作員信息，可作為多終端協(xié)同作業(yè)特征符，便于任務有效性識別、分發(fā)、結單、日志分析與統(tǒng)計等?！敖訂巍焙蟪绦騼?yōu)先檢索本地磁盤，如找不到用戶請求的文獻，自動構建檢索策略從電子資源庫下載該文獻；檢測文獻質量，將達標文獻發(fā)送至用戶郵箱；記錄工作日志并將下載文獻歸檔。程序空閑時隨機自動操作網(wǎng)頁以防因長時間無操作被踢除登錄狀態(tài)。程序可滿足不同文獻傳遞員偏好，如除特定字串外允許操作員自定義自動回復與郵件內容等，在推進電子資源移動化服務同時助力個性化學科服務建設等。

2.2 系統(tǒng)模塊

系統(tǒng)由微信用戶端、微信公眾平臺、PC端文獻傳遞機器人三層結構組成，見圖1。PC端機器人收割用戶發(fā)向微信公眾平臺的消息，根據(jù)消息類型分類部署，進入“用戶認證”模塊或“文獻傳遞”模塊，按需進行環(huán)境設置、接入擴展接口等。

圖1 系統(tǒng)模塊

2.3 技術方案

主要流程如圖2所示。舍棄消息池中不含特征字的非相關消息；對相關消息，優(yōu)先執(zhí)行“用戶認證”模塊；對合法用戶和有效文獻請求，優(yōu)先檢索本地資源，若本地缺藏再檢索網(wǎng)絡數(shù)據(jù)庫并自動下載文獻，發(fā)送給用戶。

圖2 技術流程

3 關鍵方法與技術

3.1 用戶認證模塊

程序建立專用數(shù)據(jù)庫以甄別消息來源及有效性等，實現(xiàn)用戶認證。不調用微信高級接口前提下，用戶fakeID相對公眾號具全局唯一性，列為數(shù)據(jù)庫核心參數(shù)。提取類似“https：//mp.weixin.qq.com/cgi-bin/singlesendpage?tofakeid=otmpOuOqOhuGkTvm0YpVWyjmn884&t=message/send&action=index&quickReplyId=442628135...”消息鏈接，其中“otmpOuOqOhuGkTvm0 YpVWyjmn884”即為用戶fakeID。用戶申請認證時向公眾號發(fā)送類似“文獻傳遞綁定|生命科學學院|胡東?！钡母袷交谋?，程序對接圖書管理系統(tǒng)，判斷申請是否來自圖書館合法用戶，是則寫入“文獻傳遞”數(shù)據(jù)庫，用戶數(shù)據(jù)見表1。

表1 文獻傳遞用戶數(shù)據(jù)表

3.2 提取消息并分類部署模塊

模塊從微信公眾平臺獲取用戶消息，根據(jù)消息及請求有效性進行分類部署。獲取消息通過操作網(wǎng)頁文檔對象實現(xiàn)。枚舉并篩選網(wǎng)頁源碼中“href”值包含“https：//mp.weixin.qq.com/cgibin/singlesendpage?tofakeid=”的“a”標簽，跳轉后枚舉并篩選id前綴為“wxMsg”的“div”標簽，讀取其innerText值即可。分類部署時，順序判斷消息是否含“處理中”特征字，有則返回；判斷消息是否含“請求傳遞”特征字，有且申請合法時自動回復“處理中”特征字，執(zhí)行文獻傳遞并返回；如文本含“申請綁定”特征字，執(zhí)行用戶認證模塊。對不帶“文獻傳遞”特征字的普通消息不予理會。提取消息核心算法如下：

3.3 文獻傳遞模塊

提取用戶提交的文獻信息，如本地磁盤有此文獻，直接發(fā)給用戶，否則自動構建檢索策略，訪問電子資源庫下載文獻并發(fā)給用戶。

在電子資源庫執(zhí)行檢索策略并篩選結果仍通過操作網(wǎng)頁文檔對象實現(xiàn)，此不贅述。下載文獻時，通過解析網(wǎng)頁Request Headers等元素可獲取真實、靜態(tài)的下載鏈接。考慮到電子資源庫、資源發(fā)現(xiàn)系統(tǒng)類型繁多，本文采用模擬真人點擊Windows標準窗口組件操作思路，即監(jiān)測到下載會話框出現(xiàn)時自動設置存儲位置、單擊“保存”按鈕等。常規(guī)操作方法為使用Windows API函數(shù)SendMessage向文本框或按鈕發(fā)消息，改變文本框初始值或按鈕按下與釋放狀態(tài)。本文引入第三方下載器Internet Download Manager接管瀏覽器下載模塊，固定了下載會話框的窗口標題、默認下載位置、按鈕文本等，此時使用腳本語言AutoHotKey編寫代碼比常規(guī)方法更方便，核心代碼如下：

WinWaitActive，下載文件信息 ahk_exe IDMan.exe

ControlClick，開始下載(&S)，下載文件信息 ahk_exe IDMan.exe，，Left，1，NA

下載完成后使用Adobe Reader打開文檔，閱讀器窗口標題應包含文獻題名，否則或因網(wǎng)絡原因導致文檔下載失敗，藉此可粗略檢查下載作業(yè)質量。

3.4 環(huán)境設置及擴展接口模塊

對運行環(huán)境進行評測和設置，可提升程序兼容性和擴展性。當影響網(wǎng)頁文檔操作或Windows標準控件操作的進程存在時，提示用戶，提供改寫配置文件或Windows注冊表等解決方案。自動操作網(wǎng)頁文檔對象的前提是被操作網(wǎng)頁載入完畢，否則可能出現(xiàn)待操作對象為空、自動操作指令被阻塞等問題，允許操作員根據(jù)電腦配置及網(wǎng)絡狀況設置網(wǎng)頁就緒等待超時、重試刷新間隔及次數(shù)、網(wǎng)絡意外斷開時是否以合成語音或mp3音樂報警等。允許操作員進行更多個性化設置并預留接口，如本機構缺藏文獻時詢問用戶有無意愿向外機構付費申請等。

4 應用效果評價

程序可穩(wěn)定運行于32位、64位Windows 7和Windows 10操作系統(tǒng)，連續(xù)運行7×24小時無故障且功能確切。內測期間收到用戶消息936條，文獻傳遞滿足率100%。用戶可在PC或移動端(Android/iOS)下載郵箱中的PDF格式文獻并閱讀。

936條消息中與文獻傳遞相關的有875條，由397人發(fā)出。取消息首次成功率97.44%，容錯重做成功率100%，失敗原因主要為網(wǎng)絡故障導致打開網(wǎng)頁超時。875條消息中有406條申請“綁定用戶”，其中9條為同一微信賬號重復發(fā)送；有469條申請“文獻傳遞”，其中含同一賬號重復請求或申請多筆文獻。

處理綁定請求平均耗時3.17秒。處理文獻請求平均耗時62.39秒，首次成功率97.6%，容錯重做成功率100%。失敗原因有：(1)優(yōu)先檢索中國知網(wǎng)時用戶并發(fā)數(shù)已滿，導致網(wǎng)頁就緒超時；(2)網(wǎng)絡丟包導致網(wǎng)頁就緒超時；(3)等待下載對話框超時；(4)遠程訪問系統(tǒng)丟失Cookie，導致無法訪問；(5)文獻下載總量超出遠程訪問限制大??；(6)郵件服務器反垃圾系統(tǒng)拒絕發(fā)信。出錯任務平均重做3次成功，最多重做5次。程序運行于64位Windows7操作系統(tǒng)的界面如圖3所示。

由上可見，程序功能確切，自動化程度高，操作員僅需簡單設置即可由程序全自動操作。程序不搭建第三方服務器，在節(jié)省硬件、公眾號認證等投資同時，對操作員計算機操作能力要求很低。測試時30位文獻傳遞員通過單擊“幫助”按鈕查看說明即會使用，無需集中培訓。用戶提交認證、請求文獻只需向微信公眾號各發(fā)送一條格式化文本，同樣無需集中培訓。程序“接單回復”機制可有效避免單機或多機協(xié)作時有可能產生的重復勞動，可根據(jù)實際情況開啟、暫?；蛲Ｖ瓜嚓P功能，日志系統(tǒng)方便文獻傳遞主管排查錯漏、對操作員考核評價等。

圖3 文獻傳遞機器人程序主界面

5 結語

微信是圖書館創(chuàng)新工作思路、開展移動服務的重要工具。本文圍繞微信公眾平臺編制程序，全天候近乎全自動地為用戶提供文獻傳遞服務，為學科館員實踐和讀者服務工作提供新思路和新方法。實踐表明，即使不調用微信高級接口也可以方便高效地開發(fā)協(xié)作型應用。程序不綁定私有域名，只需調整少許代碼即可應用于不同圖書館或文獻傳遞機構，具推廣性。但是，因程序只供文獻傳遞員簡單操作，界面簡陋，部分外圍設置未窗口化；因程序部分使用模擬按鍵操作，無法多線程作業(yè)，處理速度不盡人意，工作電腦亦不能同時開展其他工作；因無服務器支持，用戶數(shù)據(jù)庫需手工同步等，這些都尚待完善。