生力軍 戰(zhàn) 菲
(1.武漢船舶職業(yè)技術(shù)學(xué)院,湖北武漢 430050;2.武漢軟件工程職業(yè)學(xué)院,湖北武漢 430205)
?
高職學(xué)生學(xué)籍管理數(shù)據(jù)接口處理過程研究
生力軍 戰(zhàn) 菲
(1.武漢船舶職業(yè)技術(shù)學(xué)院,湖北武漢 430050;2.武漢軟件工程職業(yè)學(xué)院,湖北武漢 430205)
學(xué)籍管理工作過程伴隨的是學(xué)籍信息數(shù)據(jù)的變化,當(dāng)數(shù)據(jù)的變化需要在不同的系統(tǒng)之間進行同步的時候,系統(tǒng)間的數(shù)據(jù)接口處理是一個關(guān)鍵角色。本文抽象出了當(dāng)前高職學(xué)籍管理系統(tǒng)數(shù)據(jù)架構(gòu)模型,總結(jié)了學(xué)籍管理數(shù)據(jù)接口處理在傳統(tǒng)工作模式下的最優(yōu)轉(zhuǎn)換流程,并給出在網(wǎng)絡(luò)信息時代下實現(xiàn)自動轉(zhuǎn)換的框架模型。
學(xué)籍管理;數(shù)據(jù)接口;處理過程;自動轉(zhuǎn)換;Web Service
高等學(xué)校學(xué)籍管理工作是高校教學(xué)管理工作中的重要內(nèi)容,在很大程度上直接影響高校的教學(xué)效果和辦學(xué)質(zhì)量。一般來說,可以把高校學(xué)籍管理工作分為三大板塊[1]:一是對高考錄取的學(xué)生進行資格審查并給予學(xué)籍;二是按照不同學(xué)科門類不同專業(yè)方向的教學(xué)計劃進行成績的考核并給與相應(yīng)的學(xué)籍異動處理;三是對學(xué)生在校期間所取得的所有成績(包括課程成績,英語、計算機過級情況等)及綜合表現(xiàn)審定是否具備獲得畢業(yè)證、學(xué)位證的資格。
隨著我國高等職業(yè)教育改革的深入進行,高職院校得到了前所未有的發(fā)展,學(xué)籍管理正在逐步邁向管理信息現(xiàn)代化,許多學(xué)校也建立了自己的學(xué)籍管理系統(tǒng)。但總的來說,各個學(xué)校建立的學(xué)籍管理系統(tǒng)都是一個“信息孤島”,表現(xiàn)在:學(xué)籍信息共享性差,與其他系統(tǒng)的數(shù)據(jù)同步困難,數(shù)據(jù)導(dǎo)入導(dǎo)出繁瑣且容易出錯等。所以,盡管許多高職院校都在使用學(xué)籍管理系統(tǒng),但大多感覺并沒有有效改善本校的管理現(xiàn)狀,學(xué)籍管理還是陷入了繁雜的日常事務(wù)管理。
目前,最為權(quán)威的學(xué)籍信息庫是教育部的學(xué)信網(wǎng)學(xué)籍學(xué)歷管理信息平臺(下稱學(xué)信網(wǎng)平臺)。同時,各個學(xué)校都有自己的一套校內(nèi)學(xué)籍管理系統(tǒng)(一般是依托教學(xué)管理系統(tǒng)),有的學(xué)校因為部門分工的原因,還擁有學(xué)工管理系統(tǒng)、收費管理系統(tǒng)等,這就造成了事實上的數(shù)據(jù)冗余,學(xué)籍信息存在于兩個或兩個以上的獨立系統(tǒng)當(dāng)中。當(dāng)前的學(xué)籍管理系統(tǒng)數(shù)據(jù)架構(gòu)模型如圖1所示。
圖1 當(dāng)前學(xué)籍管理系統(tǒng)數(shù)據(jù)架構(gòu)模型示意圖
學(xué)籍管理工作過程伴隨的是學(xué)籍信息數(shù)據(jù)的變化,當(dāng)數(shù)據(jù)的變化同時發(fā)生在多個獨立系統(tǒng)的時候,如何保證數(shù)據(jù)的準確性和一致性是一個核心問題。由圖1可以看出,當(dāng)學(xué)籍?dāng)?shù)據(jù)的變化需要在不同的系統(tǒng)之間進行同步的時候,系統(tǒng)間的數(shù)據(jù)接口處理是一個關(guān)鍵角色。這里的數(shù)據(jù)接口處理是一個抽象的概念,其本質(zhì)是要將適合某種系統(tǒng)的數(shù)據(jù)格式轉(zhuǎn)換為適合另一種系統(tǒng)的數(shù)據(jù)格式,它既可以是受控的一系列轉(zhuǎn)換流程,也可以是通過某種機制的自動轉(zhuǎn)換。本文將總結(jié)學(xué)籍管理數(shù)據(jù)接口處理在傳統(tǒng)模式下的最優(yōu)轉(zhuǎn)換流程,并給出在網(wǎng)絡(luò)信息時代下實現(xiàn)自動轉(zhuǎn)換的框架模型。
由圖1可以看出,在整個學(xué)籍管理過程中,數(shù)據(jù)接口處理存在于三個主要的同步過程,一是學(xué)信網(wǎng)平臺與校內(nèi)學(xué)籍管理系統(tǒng)間,二是校內(nèi)學(xué)籍管理系統(tǒng)和本校其他管理系統(tǒng)間,三是校內(nèi)學(xué)籍管理系統(tǒng)和各種數(shù)據(jù)報表間。這三個過程中的數(shù)據(jù)接口處理各不相同,下面分別闡述。
2.1 學(xué)信網(wǎng)平臺與校內(nèi)學(xué)籍管理系統(tǒng)間的數(shù)據(jù)接口處理
學(xué)信網(wǎng)平臺數(shù)據(jù)關(guān)系到學(xué)生的唯一合法學(xué)生身份,是學(xué)生維護自身合法權(quán)益的唯一法律憑證。因此,學(xué)信網(wǎng)平臺與校內(nèi)學(xué)籍管理系統(tǒng)間的數(shù)據(jù)統(tǒng)一和同步非常重要,兩者間的數(shù)據(jù)交換也是非常頻繁的,這就對兩者間的數(shù)據(jù)接口處理過程的準確性提出了很高的要求。從單個學(xué)生的角度看,學(xué)籍管理數(shù)據(jù)的流程是以入學(xué)注冊為起點,到畢業(yè)時的學(xué)歷注冊為終點,無論是進口還是出口都要通過該數(shù)據(jù)接口。下面以入學(xué)注冊為例,說明該數(shù)據(jù)接口處理的流程。
入學(xué)注冊的數(shù)據(jù)源有兩個,一是學(xué)信網(wǎng)平臺提供的招生數(shù)據(jù),為dbf格式。這是最為權(quán)威準確的學(xué)籍信息來源,但對于高職學(xué)校來說,學(xué)生的報到率一般達不到100%,所以不能直接以該數(shù)據(jù)作為注冊學(xué)籍的數(shù)據(jù)源;另一個數(shù)據(jù)源是學(xué)生報到時由其他部門提供的學(xué)生信息表,為xls格式。此數(shù)據(jù)源總?cè)藬?shù)準確,但容易出現(xiàn)學(xué)生個人信息錯誤的情況,如果不加處理直接上傳,不僅注冊不能成功,還有可能出現(xiàn)張冠李戴的現(xiàn)象。所以需要將以上兩個數(shù)據(jù)源結(jié)合起來,通過數(shù)據(jù)接口處理,才能成為可用的注冊數(shù)據(jù),最后導(dǎo)入學(xué)信網(wǎng)平臺和校內(nèi)學(xué)籍管理系統(tǒng)。
dbf和xls是兩種不同的數(shù)據(jù)格式,為了高效準確地結(jié)合這兩個數(shù)據(jù)源,最好的方法是將兩種數(shù)據(jù)格式都統(tǒng)一導(dǎo)入Access數(shù)據(jù)庫,生成mdb文件。學(xué)信網(wǎng)平臺的數(shù)據(jù)生成一張數(shù)據(jù)表,報到的學(xué)生信息生成另一張數(shù)據(jù)表,然后利用SQL的表連接操作,以考生號或者身份證號作為連接字段來完成兩個數(shù)據(jù)表的連接,之后再對合成的數(shù)據(jù)進行姓名的自動比對,比對不成功的數(shù)據(jù)進行手工校驗,其處理過程如圖2表示。經(jīng)過這樣處理過的數(shù)據(jù),其準確率可達到100%。
圖2 學(xué)信網(wǎng)平臺與校內(nèi)學(xué)籍管理系統(tǒng)間的數(shù)據(jù)接口處理過程(以入學(xué)注冊為例)
除入學(xué)注冊外,學(xué)年注冊、學(xué)歷注冊、批量調(diào)整專業(yè)等操作都可以采用同樣的數(shù)據(jù)接口處理過程,都是使用ACCESS作為不同數(shù)據(jù)類型的中介,利用其強大的SQL操作語句來實現(xiàn)各種數(shù)據(jù)的篩選、連接、統(tǒng)計和整理,最終將數(shù)據(jù)轉(zhuǎn)換成所需要的格式從數(shù)據(jù)接口導(dǎo)出。
2.2 校內(nèi)學(xué)籍管理系統(tǒng)和本校其他管理系統(tǒng)間的數(shù)據(jù)接口處理
學(xué)籍管理一個重要的方面就是反映學(xué)生在學(xué)校的狀態(tài)。按照教育部學(xué)年注冊的要求,校內(nèi)學(xué)籍管理系統(tǒng)需要從本校其他管理系統(tǒng)中獲取學(xué)生其他方面的狀態(tài),這就涉及到如何將不同系統(tǒng)中的信息進行準確同步。在未構(gòu)建統(tǒng)一的數(shù)據(jù)共享平臺時,定時同步是多數(shù)學(xué)校采用的方法。下面以學(xué)生繳費狀態(tài)的同步為例,說明該數(shù)據(jù)接口處理的流程。
繳費狀態(tài)的同步,信息來源有兩個,一是校內(nèi)學(xué)籍管理系統(tǒng)種的學(xué)生基本信息表,以xls文件的形式從校內(nèi)學(xué)籍管理系統(tǒng)中導(dǎo)出;另一個是收費管理系統(tǒng)中的學(xué)生繳費狀態(tài)表,以xls文件的形式從收費管理系統(tǒng)中導(dǎo)出。兩個數(shù)據(jù)源的格式都為xls文件,可以使用EXCEL中的nslookup函數(shù)來進行數(shù)據(jù)表的連接,但是當(dāng)數(shù)據(jù)表過大時,nslookup函數(shù)容易導(dǎo)致程序卡死和崩潰,所以并不推薦使用。這里還是使用ACCESS作為數(shù)據(jù)的中介,將兩張xls數(shù)據(jù)表的內(nèi)容導(dǎo)入到ACCESS數(shù)據(jù)庫中的表,利用SQL的表連接操作,以考生號或者身份證號作為連接字段來完成兩個數(shù)據(jù)表的連接,即可快速準確得到結(jié)果,最后再按照校內(nèi)學(xué)籍管理系統(tǒng)規(guī)定的數(shù)據(jù)導(dǎo)入格式整理成dbf文件將繳費信息導(dǎo)入,其處理過程如圖3表示。
圖3 校內(nèi)學(xué)籍管理系統(tǒng)和其他管理系統(tǒng)間的數(shù)據(jù)接口處理過程(以繳費狀態(tài)同步為例)
2.3 校內(nèi)學(xué)籍管理系統(tǒng)和數(shù)據(jù)報表間的數(shù)據(jù)接口處理
一般的校內(nèi)學(xué)籍管理系統(tǒng)都帶有一些預(yù)定義的數(shù)據(jù)報表,但各個學(xué)校的需求情況各不相同,自帶的預(yù)定義報表不一定能夠滿足所有的需求,這樣就需要學(xué)籍管理人員自己制作數(shù)據(jù)報報表。如果沒有專業(yè)工具的幫助,制作數(shù)據(jù)報表的工作量往往是巨大的,缺乏可重用性,實現(xiàn)效率也十分低下。如果能夠借助ACCESS數(shù)據(jù)庫和Crystal Report作為數(shù)據(jù)接口處理的工具,就能十分快速地制作可重用的自定義報表。下面以制作學(xué)生信息核對單為例,說明該數(shù)據(jù)接口處理的流程。
為了保證學(xué)籍信息的準確性,往往需要在入學(xué)后對于學(xué)生的學(xué)籍信息進行本人核對簽字,此時就需要按照班級打印出學(xué)生信息的核對單。制作信息核對單的數(shù)據(jù)源只有一個,即校內(nèi)學(xué)籍管理系統(tǒng)中的學(xué)生基本信息表,以xls文件的形式從學(xué)籍管理系統(tǒng)中導(dǎo)出。Crystal Report作為優(yōu)秀的報表設(shè)計工具,并不能以xls文件作為數(shù)據(jù)源,所以需要將xls文件導(dǎo)入ACCESS數(shù)據(jù)庫中的數(shù)據(jù)表。為了實現(xiàn)按班級打印,在設(shè)計報表的時候需要使用子報表。首先需要在ACCESS數(shù)據(jù)庫中生成班級的視圖,將此視圖作為父報表的數(shù)據(jù)源。然后在父報表中插入子報表,子報表的數(shù)據(jù)源設(shè)置為學(xué)生基本信息表,連接字段為班級名稱,其處理過程如圖4表示。
圖4 校內(nèi)學(xué)籍管理系統(tǒng)和數(shù)據(jù)報表間的數(shù)據(jù)接口處理過程(以制作學(xué)生信息核對單為例)
由以上三類數(shù)據(jù)接口處理過程可以看出,ACCESS在其中都扮演了數(shù)據(jù)中介的角色,將不同的數(shù)據(jù)格式統(tǒng)一成關(guān)系數(shù)據(jù)表,然后便可以利用其強大的SQL操作語句來實現(xiàn)各種數(shù)據(jù)的篩選、連接、統(tǒng)計和整理,最終將數(shù)據(jù)轉(zhuǎn)換成所需要的格式。
隨著網(wǎng)絡(luò)和軟件技術(shù)的飛速發(fā)展,數(shù)據(jù)接口技術(shù)也發(fā)生了日新月異的變化,為了解決信息孤島的問題,很多最新的接口技術(shù)都可以應(yīng)用。校內(nèi)學(xué)籍管理系統(tǒng)由于和其他管理系統(tǒng)處于同一個校園網(wǎng)內(nèi),所以可以通過數(shù)字化校園的共享數(shù)據(jù)平臺實現(xiàn)數(shù)據(jù)接口的同步處理,其實現(xiàn)技術(shù)多種多樣且比較成熟。而學(xué)信網(wǎng)平臺與校內(nèi)學(xué)籍管理系統(tǒng)間的數(shù)據(jù)接口一直是各院校比較頭疼的問題,至今沒有可行的方案。但在互聯(lián)網(wǎng)服務(wù)中,Web Service技術(shù)是一種可以借鑒的解決方案。如果學(xué)信網(wǎng)平臺能夠開發(fā)Web Service應(yīng)用程序接口,將數(shù)據(jù)的導(dǎo)出、導(dǎo)入、查詢和更新通過Web Service接口開放,將能徹底解決學(xué)信網(wǎng)平臺數(shù)據(jù)和校內(nèi)學(xué)籍管理系統(tǒng)數(shù)據(jù)的一致性問題。
3.1 使用Web Service技術(shù)的優(yōu)點
圖5詳細描述了Web Service體系結(jié)構(gòu)。Web Service體系結(jié)構(gòu)中定義了幾種不同功能角色,他們分別是服務(wù)提供者(Service Provider)、服務(wù)請求者(Service Requester)和服務(wù)注冊中心(Service Registry)。服務(wù)提供者通常也被稱為服務(wù)過程化提供者。定義服務(wù)后生成接口文件,并把服務(wù)發(fā)布到Service Provider是他的主要工作和任務(wù)。服務(wù)請求者通常也被稱為服務(wù)過程化請求者。他的工作機制是Service Requester通過搜索Service Registry,與Service Provider建立聯(lián)系,根據(jù)獲得的服務(wù)接口信息執(zhí)行綁定操作,運行所需要的Web Service。服務(wù)注冊中心的主要作用是記錄服務(wù),它的工作對象是Service Provider和Service Requester。服務(wù)描述通常是Service Provider在Service Registry定義的,在Service Registry定義的目的是可以使Service Requester方便發(fā)現(xiàn)、查詢和使用該服務(wù)。
圖5 Web Service體系結(jié)構(gòu)
從技術(shù)層面來說,采用Web Service技術(shù)進行系統(tǒng)化開發(fā)和部署具體應(yīng)用程序具有以下一些優(yōu)點[2]:
(1)跨平臺應(yīng)用??缙脚_性和跨系統(tǒng)是Web Service的一個主要特征,因為數(shù)據(jù)不具備可執(zhí)行性,與操作系統(tǒng)性質(zhì)無關(guān)。這一特點使得Web Service在各個平臺上都能得到廣泛的應(yīng)用。
(2)良好的的封裝性。因為Web Service是一種部署在Web上的對象,所以它具備了對象的良好封裝性,通過使用者能且僅能看到該對象提供的功能列表。
(3)松散耦合。Web Service采用的是對象/組件技術(shù),所以組件是松散耦合的。調(diào)用者不會因為其中的一個Web Service的實現(xiàn)發(fā)生變化而感覺到有什么變化。只要保持Web Service的調(diào)用界面沒有變化,Web Service的實現(xiàn)變更對他們都是透明的。
3.2 Web Service框架結(jié)構(gòu)
在學(xué)信網(wǎng)平臺和校內(nèi)學(xué)籍管理系統(tǒng)之間,如果引入Web Service體系結(jié)構(gòu),學(xué)信網(wǎng)平臺由于其數(shù)據(jù)權(quán)威的特性,將充當(dāng)服務(wù)提供者的角色,而校內(nèi)學(xué)籍管理系統(tǒng)則是服務(wù)請求者的角色。整個數(shù)據(jù)接口的框架結(jié)構(gòu)如圖6所示。
圖6 基于Web Service的學(xué)信網(wǎng)平臺與校內(nèi)學(xué)籍管理系統(tǒng)間的數(shù)據(jù)接口框架
校內(nèi)學(xué)籍管理系統(tǒng)作為服務(wù)請求者,在實現(xiàn)了本地的學(xué)籍管理操作后,根據(jù)服務(wù)提供者的接口描述,生成相應(yīng)的參數(shù)并傳遞給學(xué)信網(wǎng)平臺。學(xué)信網(wǎng)平臺作為服務(wù)提供者接收到校內(nèi)學(xué)籍管理系統(tǒng)發(fā)送的參數(shù)后,首先應(yīng)進行身份驗證,然后再將所接收的參數(shù)交由系統(tǒng)進行處理,最后將處理的結(jié)果返回給校內(nèi)學(xué)籍管理系統(tǒng)。校內(nèi)學(xué)籍管理系統(tǒng)將學(xué)信網(wǎng)平臺返回的反饋信息及時通知用戶并做相應(yīng)的處理。
要實現(xiàn)該數(shù)據(jù)接口框架,所需解決的關(guān)鍵問題主要有以下幾點:
(1)確定服務(wù)提供者接口功能。學(xué)信網(wǎng)平臺需要與高校及校內(nèi)學(xué)籍管理系統(tǒng)開發(fā)方進行需求溝通,確定開放哪些Web Service功能,根據(jù)需求來設(shè)計Web Service服務(wù)的類型、參數(shù)等。如果在缺乏需求調(diào)研的基礎(chǔ)上盲目開放Web Service接口,不僅不能滿足數(shù)據(jù)同步的需要,反而會帶來一系列安全問題。
(2)服務(wù)請求者功能升級。校內(nèi)學(xué)籍管理系統(tǒng)在學(xué)信網(wǎng)平臺確定了開放哪些Web Service接口功能后,需要進行系統(tǒng)升級,將傳統(tǒng)需要經(jīng)過人工導(dǎo)入導(dǎo)出的數(shù)據(jù)接口處理過程改由Web Service調(diào)用方式實現(xiàn)。實際上,如果每一個數(shù)據(jù)變化的操作都能夠通過Web Service接口實現(xiàn)的話,就可以避免傳統(tǒng)操作中的定時同步,減少學(xué)信網(wǎng)平臺和校內(nèi)學(xué)籍管理系統(tǒng)間的單次大量數(shù)據(jù)流動。
(3)安全強化。在引入Web Service接口后,對于學(xué)信網(wǎng)平臺數(shù)據(jù)的操作大多都是通過校內(nèi)學(xué)籍管理系統(tǒng)調(diào)用Web Service接口實現(xiàn),這就對于學(xué)信網(wǎng)平臺的數(shù)據(jù)安全和身份認證提出了更高的要求。在數(shù)據(jù)讀取方面,要保證權(quán)威學(xué)籍?dāng)?shù)據(jù)不能通過非法Web Service調(diào)用而泄露。在數(shù)據(jù)寫入方面,要保證不要讓錯誤的、過期的臟數(shù)據(jù)寫入。身份驗證方面要防止非法用戶假冒身份模擬Web Service調(diào)用。
在整個學(xué)籍管理系統(tǒng)架構(gòu)中,數(shù)據(jù)接口處理部分處于關(guān)鍵位置,直接關(guān)系到數(shù)據(jù)的準確性、一致性、數(shù)據(jù)處理的高效性。目前,學(xué)籍?dāng)?shù)據(jù)接口的處理大部分還是依賴于利用工具軟件,靠一套規(guī)范的流程來進行人工處理。但隨著我國教育事業(yè)和網(wǎng)絡(luò)信息技術(shù)的不斷發(fā)展,學(xué)籍?dāng)?shù)據(jù)接口的處理也將朝著自動化、網(wǎng)絡(luò)化的方向發(fā)展。Web Service作為互聯(lián)網(wǎng)的熱門技術(shù),具有跨平臺應(yīng)用、良好的的封裝性和松散耦合等優(yōu)勢,將它運用在學(xué)信網(wǎng)平臺和校內(nèi)學(xué)籍管理系統(tǒng)間構(gòu)建數(shù)據(jù)接口框架不失為一種可行的方法。
1 董明偉. 網(wǎng)絡(luò)平臺下高校學(xué)籍管理的實踐與研究[J]. 教學(xué)研究, 2008,31(4)
2 郝榮國. SAP系統(tǒng)中接口技術(shù)研究與應(yīng)用[D].南京:東南大學(xué),2013
3 苑舒斌,宋啟寧,洪為. SAP接口技術(shù)在人力資源系統(tǒng)中的研究與應(yīng)用[J].硅谷,2012(16)
(責(zé)任編輯:譚銀元)
Data Interface Processing Procedure of Student Enrollment Status Management in Higher Vocational College
SHENG Li-jun1,ZHAN Fei2
(1.Wuhan Institute of Shipbuilding Technology, Wuhan 430050, China;2.Wuhan Vocational College of Software and Engineering, Wuhan 430205, China)
Procedure of enrollment management works with data changes of enrollment information. Process of data interface between different systems is very pivotal when data changes synchronize between them. In this paper, it is summarized that data architecture model of modern enrollment management system and optimal conversion process of processing procedure in data interface of enrollment management in traditional working pattern, with architecture model of automatic conversion given.
enrollment management; data interface; processing procedure; automatic conversion; Web Service
課題項目:本文系湖北省高等教育學(xué)會學(xué)籍管理專業(yè)委員會2014-2015年度課題項目“基于網(wǎng)絡(luò)信息化的高職學(xué)籍管理工作過程研究》的階段性成果(課題編號:XJ14-15-02)。
2014-12-16
生力軍,男,講師,碩士研究生,研究方向為計算機技術(shù)及應(yīng)用。
TP392
A
1671-8100(2015)03-0046-05