姬 翔
(國(guó)家新聞出版廣電總局二九三臺(tái),河南 鄭州 451162)
基于微信公眾平臺(tái)的食堂訂餐系統(tǒng)研究
姬 翔
(國(guó)家新聞出版廣電總局二九三臺(tái),河南 鄭州 451162)
目前大多數(shù)單位在實(shí)施訂餐制度時(shí)還采用訂餐牌等老方法,由于無(wú)法遠(yuǎn)程訂餐,使得訂餐效率極低。為解決該問(wèn)題,文章通過(guò)提出解決思路,選取合理的技術(shù)方案,編寫符合需求的軟件邏輯,一步步實(shí)現(xiàn)了基于微信公眾平臺(tái)的食堂訂餐系統(tǒng)。
微信公眾平臺(tái)開發(fā);遠(yuǎn)程訂餐;PHP;MYSQL
隨著生活工作節(jié)奏的加快,單位食堂逐漸成為職工工作餐的主要解決途徑。但由于存在職工請(qǐng)假休息等情況,食堂就餐人員不易固定,為避免浪費(fèi)、厲行節(jié)約,多數(shù)單位普遍采取提前訂餐制度,通過(guò)在食堂設(shè)置訂餐牌來(lái)解決訂餐問(wèn)題。但在實(shí)際操作過(guò)程中發(fā)現(xiàn),該種訂餐形式必須由職工親自去食堂更改訂餐信息,不僅浪費(fèi)職工大量時(shí)間,也不利于廚師對(duì)用餐人數(shù)進(jìn)行統(tǒng)計(jì),為有效解決這一問(wèn)題,本文作者開發(fā)了基于微信公眾平臺(tái)的食堂訂餐系統(tǒng)。
目前食堂訂餐存在幾個(gè)不方便因素,首先,訂餐牌一般設(shè)立于食堂內(nèi),職工在更改訂餐需求時(shí)需要奔赴食堂才能操作,很是不便,若是因出差等原因不在單位內(nèi)則更為麻煩;其次,廚師在控制飯量多少時(shí)需要知道用餐總?cè)藬?shù),而訂餐牌只能提供用餐人員列表,還需人工進(jìn)行統(tǒng)計(jì)總數(shù);再次,由于廚師加工餐食一般需要一個(gè)半小時(shí),所以訂餐操作一般應(yīng)該在飯前一個(gè)半小時(shí)之前進(jìn)行,但由于訂餐牌不具備限時(shí)訂餐功能,若訂餐操作過(guò)晚就可能造成餐食不夠或過(guò)剩。
理想的訂餐工具應(yīng)該是可以24小時(shí)隨身攜帶,所以手機(jī)是一個(gè)理想的操作平臺(tái),編寫一款具有遠(yuǎn)程通信功能的手機(jī)APP便可滿足需求,但手機(jī)APP具有幾個(gè)致命缺點(diǎn),一是兼容性差,目前手機(jī)操作系統(tǒng)類型及版本多種多樣,一款A(yù)PP要實(shí)現(xiàn)跨平臺(tái)得進(jìn)行多次移植,工作量極大;二是食堂訂餐操作需要進(jìn)行傳輸及處理的內(nèi)容極為簡(jiǎn)單,僅僅是用戶姓名和訂餐內(nèi)容,若專門編寫APP來(lái)完成此類操作屬于“殺雞用牛刀”,不僅費(fèi)時(shí)費(fèi)力而且APP也顯得過(guò)于臃腫。
通過(guò)對(duì)多種技術(shù)方案進(jìn)行比較,發(fā)現(xiàn)基于微信公眾平臺(tái)的交互式APP最適合此類業(yè)務(wù)。該APP基于微信聊天界面,通過(guò)手機(jī)微信就能發(fā)送訂餐消息,訂餐系統(tǒng)后臺(tái)服務(wù)器接收到訂餐消息時(shí)便可修改用戶訂餐狀態(tài)?;谖⑿殴娖脚_(tái)的交互式APP除滿足訂餐的基本功能外還具有跨平臺(tái)以及輕量、穩(wěn)定等優(yōu)點(diǎn)。
3.1 基于微信公眾平臺(tái)的交互式APP開發(fā)原理
以本訂餐系統(tǒng)的架構(gòu)為例,公眾平臺(tái)服務(wù)器在整個(gè)系統(tǒng)中起到連接用戶終端與訂餐系統(tǒng)服務(wù)器的媒介作用。用戶發(fā)起的訂餐請(qǐng)求會(huì)首先發(fā)往微信公眾平臺(tái)服務(wù)器,服務(wù)器對(duì)文本進(jìn)行XM L格式封裝后發(fā)往開發(fā)者部署的訂餐系統(tǒng)服務(wù)器。服務(wù)器對(duì)信息進(jìn)行處理后回復(fù)XM L格式的結(jié)果信息給微信公眾平臺(tái)服務(wù)器,平臺(tái)對(duì)XM L格式內(nèi)容進(jìn)行核驗(yàn)和解析后回復(fù)文本信息給用戶終端,從而達(dá)到智能交互的目的。需要注意的是開發(fā)者回復(fù)的XML參數(shù)信息必須符合公眾平臺(tái)要求的格式,否則公眾平臺(tái)將忽略掉該條消息,導(dǎo)致用戶無(wú)法收到回復(fù)信息。
微信公眾平臺(tái)與開發(fā)者的服務(wù)器在通信前,開發(fā)者需在公眾平臺(tái)后臺(tái)管理頁(yè)面配置接口信息,配置內(nèi)容包括填寫開發(fā)者服務(wù)器地址(URL),Token和EncodingAESKey,其中URL是開發(fā)者用來(lái)接收微信消息和事件的接口URL,本例中即為訂餐系統(tǒng)服務(wù)腳本地址。Token可由開發(fā)者可以任意填寫,用作生成簽名,驗(yàn)證通信安全性,防止第三方請(qǐng)求惡意訪問(wèn)。EncodingAESKey由開發(fā)者手動(dòng)填寫或隨機(jī)生成,用作對(duì)消息體進(jìn)行加解密的密鑰,防止信息在傳輸環(huán)節(jié)被竊取。整個(gè)交互的主要邏輯運(yùn)行在開發(fā)者服務(wù)器上,所以整個(gè)訂餐系統(tǒng)的邏輯部分開發(fā)主要針對(duì)開發(fā)者服務(wù)器部分,本文也將主要介紹該部分的設(shè)計(jì)與實(shí)現(xiàn)。
3.2 訂餐服務(wù)腳本的設(shè)計(jì)架構(gòu)
訂餐服務(wù)器上運(yùn)行有PHP腳本以及M YSQL數(shù)據(jù)庫(kù),PHP腳本負(fù)責(zé)與公眾平臺(tái)的通信以及具體的業(yè)務(wù)邏輯,MYSQL數(shù)據(jù)庫(kù)負(fù)責(zé)用戶訂餐數(shù)據(jù)的存儲(chǔ)。所有訂餐服務(wù)腳本(以下簡(jiǎn)稱為腳本)均由PHP語(yǔ)言編寫。腳本主要分為幾個(gè)功能部分,具體是:XML格式消息處理部分,信息處理部分,業(yè)務(wù)處理部分,以及數(shù)據(jù)庫(kù)部分。下面將詳細(xì)介紹各部分的具體功能與實(shí)現(xiàn)。
3.2.1 XML格式消息處理
XM L格式消息的處理主要分為XM L格式的解析與組裝,由于平臺(tái)發(fā)送來(lái)的消息為XM L格式,不能像數(shù)組類型的數(shù)據(jù)格式那樣直接根據(jù)Key訪問(wèn)Value,所以需要通過(guò)PHP的自帶函數(shù)xm l_parse_into_struct()將數(shù)據(jù)轉(zhuǎn)為數(shù)據(jù)格式。同時(shí),在腳本處理完數(shù)據(jù)返回平臺(tái)時(shí)也需要將數(shù)組數(shù)據(jù)組裝為XM L格式,這里通過(guò)Xm lConstruct()函數(shù)實(shí)現(xiàn)。
3.2.2 信息處理部分
XM L格式解析后用戶的消息將會(huì)轉(zhuǎn)為數(shù)組傳遞給信息處理部分,用戶在微信客戶端操作訂餐系統(tǒng)通過(guò)發(fā)送文本信息實(shí)現(xiàn),所以訂餐系統(tǒng)需要通過(guò)用戶發(fā)送的文本內(nèi)容判斷用戶的目的。由于每個(gè)用戶個(gè)人習(xí)慣不盡相同,不同用戶表達(dá)同一意思發(fā)送的文本具有差異性,但機(jī)器本身無(wú)法理解人類語(yǔ)言,所以需要約定不同文本內(nèi)容所表示的操作請(qǐng)求。用戶在發(fā)送信息時(shí)只有在文本內(nèi)容與系統(tǒng)內(nèi)置文本對(duì)應(yīng)時(shí)訂餐系統(tǒng)才會(huì)執(zhí)行具體的操作,若用戶發(fā)送內(nèi)置文本之外的信息,信息處理腳本將會(huì)無(wú)法識(shí)別用戶指令,回復(fù)用戶該指令非法。若信息為系統(tǒng)內(nèi)置文本之一,信息處理腳本通過(guò)識(shí)別文本內(nèi)容,并發(fā)起請(qǐng)求到對(duì)應(yīng)的業(yè)務(wù)處理腳本。
3.2.3 業(yè)務(wù)處理部分
業(yè)務(wù)處理部分根據(jù)不同請(qǐng)求分為3部分:訂餐業(yè)務(wù),查詢業(yè)務(wù),實(shí)名綁定業(yè)務(wù),3部分由不同的處理腳本負(fù)責(zé)。
(1)訂餐腳本負(fù)責(zé)處理用戶預(yù)定和取消午飯、晚飯的操作。根據(jù)需求,預(yù)訂和取消操作需要在當(dāng)次用餐時(shí)間的1.5小時(shí)之前完成,例如午飯開飯時(shí)間為中午12點(diǎn),則用戶需在10點(diǎn)30分之前完成預(yù)定和取消操作,若操作在10點(diǎn)30分到12點(diǎn)之間,系統(tǒng)將提示該時(shí)段禁止操作,而且在12點(diǎn)之后,用戶即可對(duì)第二天的午飯預(yù)定情況進(jìn)行更改。本系統(tǒng)中單獨(dú)編寫了時(shí)間核驗(yàn)函數(shù),負(fù)責(zé)在更改訂餐狀態(tài)前判斷訂餐操作是否在合法時(shí)間段。對(duì)于合法時(shí)間段內(nèi)的操作,訂餐腳本將更改用戶在數(shù)據(jù)庫(kù)中的數(shù)據(jù)信息。
數(shù)據(jù)庫(kù)設(shè)計(jì)為5個(gè)字段,分別為id,w xid,name,ZW,W F。其中id用來(lái)記錄數(shù)據(jù)序號(hào)并標(biāo)識(shí)的數(shù)據(jù)唯一性,為數(shù)據(jù)表的主鍵,擁有自增屬性;w xid記錄了公眾平臺(tái)定義的用戶身份識(shí)別碼,每一個(gè)身份識(shí)別碼都對(duì)應(yīng)了一個(gè)唯一的微信用戶;name字段用來(lái)記錄用戶的真實(shí)姓名,為統(tǒng)計(jì)訂餐人員名單提供數(shù)據(jù)支撐;ZW,WF兩個(gè)字段分別表示用戶午飯、晚飯的預(yù)定情況,該字段為BOOLEAN數(shù)據(jù)類型,只有0,1兩個(gè)狀態(tài),其中1表示用戶預(yù)定,0表示用戶未預(yù)定。當(dāng)信息處理腳本收到用戶更改訂餐狀態(tài)的文本內(nèi)容時(shí),將操作內(nèi)容傳遞給訂餐腳本,訂餐腳本先調(diào)用時(shí)間核驗(yàn)函數(shù)檢查訂餐時(shí)間是否合法,若合法該腳本根據(jù)文本內(nèi)容修改對(duì)應(yīng)用戶名下的ZW或WF字段內(nèi)容,完成數(shù)據(jù)修改。
(2)訂餐信息查詢腳本提供了對(duì)當(dāng)前訂餐人員名單及人數(shù)的查詢服務(wù),主要供廚師統(tǒng)計(jì)訂餐人數(shù)和用戶核驗(yàn)自己訂餐狀態(tài)使用。信息處理腳本在收到用戶查詢訂餐信息的文本內(nèi)容時(shí),調(diào)用查詢信息腳本,腳本從數(shù)據(jù)庫(kù)中分別查找ZW、WF字段為1的name值,將結(jié)果分別錄入午飯、晚飯兩個(gè)數(shù)組,通過(guò)統(tǒng)計(jì)數(shù)組長(zhǎng)度得出訂餐總?cè)藬?shù)數(shù)據(jù)。隨后腳本將人員名單及總?cè)藬?shù)數(shù)據(jù)傳遞給XM L格式組裝函數(shù),將組裝好的XM L數(shù)據(jù)返回給公眾號(hào)平臺(tái),完成數(shù)據(jù)查詢操作。
(3)出于對(duì)用戶個(gè)人信息的保護(hù),微信公眾平臺(tái)在向開發(fā)者發(fā)送的消息內(nèi)容時(shí),用戶的身份特征使用身份識(shí)別碼表示,身份識(shí)別碼由一組長(zhǎng)度為28的字符串組成,wxid內(nèi)容就是典型的身份識(shí)別碼(第二到七行為筆者測(cè)試數(shù)據(jù))。由于在統(tǒng)計(jì)訂餐人員信息時(shí)需要用戶的真實(shí)姓名,所以開發(fā)了用戶實(shí)名綁定腳本處理該流程,通過(guò)該腳本,未綁定的用戶可以通過(guò)編輯發(fā)送“綁定+個(gè)人姓名”的方式實(shí)現(xiàn)實(shí)名綁定。具體流程如下:信息處理腳本在收到以“綁定”開頭的文本內(nèi)容時(shí),將文本信息傳遞給實(shí)名綁定腳本,該腳本先將“+”以后的文本內(nèi)容截取出來(lái),然后將此文本內(nèi)容填入該用戶w xid對(duì)應(yīng)的name欄,完成實(shí)名用戶綁定。
3.2.4 數(shù)據(jù)庫(kù)部分
本系統(tǒng)數(shù)據(jù)庫(kù)采用了與PHP兼容性良好的MYSQL數(shù)據(jù)庫(kù),數(shù)據(jù)庫(kù)部分除負(fù)責(zé)訂餐數(shù)據(jù)的存儲(chǔ)外還為各業(yè)務(wù)腳本提供增、刪、改、查服務(wù),各腳本每次操作都會(huì)收到數(shù)據(jù)庫(kù)發(fā)出的操作反饋,反饋內(nèi)容主要為操作是否成功,對(duì)于未成功的操作,各腳本在收到反饋后也會(huì)通知用戶錯(cuò)誤信息,保證每次用戶操作都有真實(shí)反饋。
該系統(tǒng)實(shí)現(xiàn)了通過(guò)手機(jī)等移動(dòng)端設(shè)備遠(yuǎn)程修改訂餐狀態(tài)的功能,不僅簡(jiǎn)單方便而且輕量、穩(wěn)定、低成本,在不占用手機(jī)空間的同時(shí)實(shí)現(xiàn)了跨平臺(tái)的效果。系統(tǒng)同時(shí)還具備其他優(yōu)秀特性,如訂餐時(shí)間段的設(shè)置讓用戶主動(dòng)在餐前1.5小時(shí)前訂餐,杜絕了臨時(shí)訂餐的情況;用餐人數(shù)自動(dòng)統(tǒng)計(jì)功能免去了人工計(jì)數(shù)的低效率方法;數(shù)據(jù)庫(kù)狀態(tài)信息定時(shí)備份功能也使得食堂管理人員統(tǒng)計(jì)歷史用餐信息變得非常簡(jiǎn)便。
基于微信公眾平臺(tái)的食堂訂餐系統(tǒng)的部署,大大簡(jiǎn)化了職工日常訂餐流程,同時(shí),該系統(tǒng)不僅規(guī)范了訂餐制度,訂餐數(shù)據(jù)統(tǒng)計(jì)功能也為食堂管理工作提供了有力的技術(shù)支撐。在下一步的完善工作中,系統(tǒng)將會(huì)作出升級(jí)調(diào)整:(1)將系統(tǒng)遷移至云端服務(wù)器,使用第三方平臺(tái)提供的云服務(wù)將徹底解決服務(wù)器硬件崩潰等問(wèn)題,而且由于本系統(tǒng)需要的寬帶流量極少,使用云服務(wù)也能使每天運(yùn)維費(fèi)用降低到一元錢以內(nèi),大大節(jié)省了系統(tǒng)運(yùn)行成本。(2)對(duì)微信公眾平臺(tái)界面進(jìn)行按鈕化升級(jí),使用戶通過(guò)點(diǎn)擊按鈕便可完成訂餐操作,簡(jiǎn)化操作步驟。
[1]httpclient概念.[EB/OL].(2016-08-26)[2017-05-09].百度百科.http://baike.baidu.com/view/2476238.htm.
[2]鐘志勇.微信公眾平臺(tái)應(yīng)用開發(fā)實(shí)戰(zhàn)[M].北京:機(jī)械工業(yè)出版社,2013.
[3]WELLING L,THOMSON L.PHP和MySQL Web開發(fā)[M].北京:機(jī)械工業(yè)出版社,2005.
Study on the dining room ordering system based on the WeChat public platform
Ji Xiang
(293 Station of State Adm inistration of Press and Publication, Radio, Film and Television of the People’s Republic of China, Zhengzhou 451162, China)
At present, most of the units still adopt old ordering method like reservation card while implementing the reservation system. The reservation efficiency is extremely low because the remote reservation is unavailable. To solve this problem, this paper has implemented the dining room ordering system based on the WeChat public platform through putting forward the solutions, selecting reasonable technical proposal and w riting down software logic meeting its requirements.
WeChat public platform development; remote order meal; PHP; MYSQL
姬翔(1988— ),男,陜西延安,本科,助理工程師;研究方向:軟件開發(fā)。