以信息中心為核心的企業(yè)移動應(yīng)用平臺研究

跨境銀行間支付清算有限責(zé)任公司 萬 鵬

信息化辦公相比人工辦公模式，有著應(yīng)用合理、辦公高效的特點，市場上的主流企業(yè)要實現(xiàn)信息化辦公多采用的是B/S結(jié)構(gòu)下的OA系統(tǒng)，通過對不同需求下該系統(tǒng)的設(shè)計和運用可以使得企業(yè)的辦公平臺更為的模塊化、層次化和結(jié)構(gòu)性。企業(yè)的移動應(yīng)用平臺的建設(shè)應(yīng)該緊緊圍繞信息化為核心來建設(shè)，其的建設(shè)能夠突出兩點優(yōu)勢，一方面能夠?qū)崿F(xiàn)企業(yè)自身在信息化方面的升級改造，另外一方面促進傳統(tǒng)的信息化變得更為完善。

本文以某企業(yè)移動辦公平臺項目為論文支撐，該公司在規(guī)模日益擴大的情況下，出現(xiàn)了分子公司、部門之間信息的斷層情況，資源不能實現(xiàn)有機整合，信息溝通出現(xiàn)效率低的情況，問題的暴露使得企業(yè)需要作出建設(shè)一體化協(xié)同辦公系統(tǒng)的需求變得越來越迫切。設(shè)計以決策主導(dǎo)核心，以紐帶帶動核心的高水平系統(tǒng)，以期望達到運營成本的降低、管理模式的優(yōu)化、公司資源的整合、辦公流程的規(guī)范、信息流通的加快等目標(biāo)。

1 移動辦公平臺需求與技術(shù)選擇

1.1 業(yè)務(wù)需求分析

需求方面需要重點創(chuàng)建管理員角色和操作對象角色，管理員角色的權(quán)限較為高級，其系統(tǒng)模塊下能夠進行人事操作。

例如可以查看到內(nèi)部的人事信息并且對該人員信息的角色進行調(diào)整，起到管理的職能。另一類為對象角色，為應(yīng)用方，通過移動端來行使系統(tǒng)職能，對各類辦公業(yè)務(wù)進行處理。要實現(xiàn)的業(yè)務(wù)功能包括門戶功能、公文處理、人事管理、薪酬績效、行政服務(wù)、合規(guī)服務(wù)、財務(wù)管理、項目管理等模塊。

1.2 系統(tǒng)非功能性需求

系統(tǒng)非功能性需求包括：①用戶容量：能夠做到支持200以上用戶訪問，支持新增部門以及子公司管理。②安全防護：OA系統(tǒng)安裝部署在本地服務(wù)器，部署兩套，一套純內(nèi)網(wǎng)，一套支持外網(wǎng)訪問；辦內(nèi)部資料存儲在本地服務(wù)器上；局域網(wǎng)外互聯(lián)網(wǎng)設(shè)備需通過安全的VPN連接訪問OA系統(tǒng)。③移動辦公：支持在這些移動終端上進行移動辦公。

1.3 技術(shù)選擇

（1）分布式系統(tǒng)架構(gòu)技術(shù)

該技術(shù)采用的是J2EE，即Java 2 EntERPrise Edition，是以Java為主導(dǎo)平臺來解決問題的一種體系結(jié)構(gòu)，能解決的問題主要針對解決方案在開發(fā)、管理和部署過程中出現(xiàn)的問題，此類問題較為復(fù)雜，簡化操作后變得更為方便。該架構(gòu)的優(yōu)勢是支持多種客戶端的訪問，使得程序在應(yīng)用服務(wù)器下運行。

（2）構(gòu)件技術(shù)

構(gòu)件技術(shù)是一種可以復(fù)用的軟件組成成分，不僅可以用作軟件的構(gòu)造組成，也可以是軟件架構(gòu)、文檔、分析件等功能性模塊。

整個構(gòu)件庫包括有三個大類，為業(yè)務(wù)構(gòu)件、行業(yè)構(gòu)件以及基礎(chǔ)構(gòu)件，基礎(chǔ)構(gòu)件，業(yè)務(wù)構(gòu)件涵蓋有工具構(gòu)件以及角色構(gòu)件；行業(yè)構(gòu)件主要針對政府，下級文件則涵蓋產(chǎn)品構(gòu)件以及單位構(gòu)件。

（3）XML技術(shù)

XML技術(shù)主要對不同數(shù)量的標(biāo)記文檔進行定義，其保留了SGML的可擴展的功能，還可以使得信息結(jié)構(gòu)以嵌套的方式進行存在，弊端上，較HTML語言來說，不能做到對標(biāo)簽進行預(yù)先定義并且直接使用，只能在初始上進行需求設(shè)計而達到定義的目的。

2 移動辦公平臺架構(gòu)設(shè)計

移動辦公平臺的架構(gòu)設(shè)計是基于移動終端系統(tǒng)平臺和企業(yè)應(yīng)用系統(tǒng)之間的中間端，它既可以提供后端系統(tǒng)快速集成，同時在前段各個覆蓋的基礎(chǔ)配套服務(wù)設(shè)施下實現(xiàn)企業(yè)的一些業(yè)務(wù)事項、業(yè)務(wù)流程在各個移動設(shè)備中輕松操作。

系統(tǒng)可以分為四個服務(wù)層次，該平臺可實現(xiàn)在移動APP、PC電腦端、微信集成以及平板集成等多元辦公條件，其他包括平臺的前端應(yīng)用層，包括公文處理、行政服務(wù)、薪酬績效等日常辦公模塊。支撐引擎層中既包括組織權(quán)限、流程引擎等模塊，同時包括集成中心、日志中心等模塊。在后端中還建立有數(shù)據(jù)資源層，作為系統(tǒng)的存儲機制。項目包括有分析決策數(shù)據(jù)庫、公文文檔庫、會議管理庫等資源，能作為應(yīng)急方案而防止數(shù)據(jù)丟失。

圖1 通知待辦界面呈現(xiàn)

3 實現(xiàn)效果分析

3.1 通知待辦形式呈現(xiàn)

通常待辦模塊主要考慮的是實務(wù)的通知、查詢以及出現(xiàn)失誤后的撤回、刪除功能，呈現(xiàn)效果如圖1所示。

（1）通知待辦模塊的設(shè)計包括管理員角色以及對象操作角色，登入時均需要進行身份驗證，驗證成功后方可進入。

（2）進入模塊后無需新建待辦事宜，管理員進行操作后，/todo-service/todos 接口接收到POST發(fā)出的操作命令，針對數(shù)據(jù)會激活TodoService的工作，方法采用saveTodo()。

（3）0TodoService進行一系列復(fù)雜的處理操作，采用saveTodo()方法有個好處就是能夠進行錯誤反饋，針對數(shù)據(jù)的完整性而得到不一樣的反饋結(jié)果。進入下一步后，我們的系統(tǒng)需要通過TodoMapper來進行待辦事宜的操作，方法采用insertTodo()，最后完成待辦事宜的操作后信息將會保持在系統(tǒng)中，結(jié)果根據(jù)在todo和todouserre表中進行存儲。

（4）通過完成待辦事宜的操作后，系統(tǒng)內(nèi)部的緩沖信息將會進一步更新，最后做出反饋，反饋信息直接反饋給前段。

（5）前段在收到反饋信息后需要對完成的事項進行更新，結(jié)果再通知待辦列表中顯示，使用的是GET/todo-service/todos 接口。

3.2 考勤管理形式呈現(xiàn)

系統(tǒng)設(shè)計的考勤管理模塊在人事管理中，本項目設(shè)計的考勤管理關(guān)注的問題主要包括打卡信息、是否缺勤、請假的情況、上下班時間節(jié)點、工作時長以及考勤記錄的記憶功能等要點，其呈現(xiàn)界面如圖2所示。

（1）考勤系統(tǒng)是員工常用的一個子模塊，企業(yè)的員工假如需要完成考勤，則移動端或者PC端均需要在特定的網(wǎng)絡(luò)條件下進行打卡活動，點擊該標(biāo)簽來進行操作。

（2）設(shè)計使用/checkin-service/checkin/{type}接口來接受移動端發(fā)出的POST打開命令，系統(tǒng)可設(shè)置簽到類型，通過不同的序號來進行上班狀態(tài)下班狀態(tài)的標(biāo)簽標(biāo)記，上班下班打卡后我們首先需要進行網(wǎng)關(guān)傳輸，進入到checkin-service服務(wù)，該服務(wù)我們采用的是saveCheckIn()中的方法來進一步處理數(shù)據(jù)。

（3）使用saveCheckIn()方法的方法同樣取決于其兼容性，為了系統(tǒng)穩(wěn)定性考慮我們同樣設(shè)計了驗證反饋程序，此操作的驗證具有覆蓋性，針對多次打卡的指令我們優(yōu)先反饋最新的打開記錄，不同時間對應(yīng)不同的時段我們使用不同的type值來進行添加，offdutycheckintime字段對應(yīng)type值為“下班”的狀態(tài)；ondutycheckintime字段對應(yīng)type值為“上班”的狀態(tài)，信息的操作同樣會得以保持，我們設(shè)計用CheckInMapper中的insertCheckIn()方法來完成最后的考勤記錄，該考勤記錄可根據(jù)需求調(diào)整保存時長。

圖2 考勤界面

請假事宜的操作模塊：

（1）我們把請假事宜模塊設(shè)計入人事模塊中，上面涵蓋有請假字樣的標(biāo)簽，員工的請假通過該標(biāo)簽完成。

（2）根據(jù)/checkin-service/takeleave 接口來接受員工的發(fā)送的GET請假需求，此模塊下，我們需要進行請假類型的篩選，不同的請假類型將進入不一樣的數(shù)據(jù)庫，包括有年假、事假以及病假等，選擇完請假類型后系統(tǒng)重復(fù)以上操作，經(jīng)過網(wǎng)關(guān)傳輸后由checkin-service進行接收，緊接著會激活TakeLeaveService進行工作，激活后的TakeLeaveService采用saveTakeLeave()方法進行完整性驗證，方法同上；最終啟動TakeLeaveMapper進行工作，該工作方法采用insertTakeLeave()方法，操作完成后該用戶的請假信息會存入take_Ieave表中。

結(jié)束語：系統(tǒng)的設(shè)計均要考慮需求和技術(shù)的可行性兩個方面，本文介紹了項目中分布式系統(tǒng)架構(gòu)技術(shù)、構(gòu)件技術(shù)以及XML等關(guān)鍵技術(shù)，提出了用戶容量、安全防護以及移動辦公等方面的非功能性需求，在移動辦公平臺整體架構(gòu)下列舉了操作日志、通知待辦以及考勤記錄等子模塊的呈現(xiàn)形式以及操作方式，整個系統(tǒng)架構(gòu)設(shè)計中在實用、可靠性以及接入點方向防控等方面較為薄弱，其優(yōu)化空間還需校驗。移動辦公應(yīng)用平臺在互聯(lián)網(wǎng)接入端普遍存在脆弱性的情況下，強化應(yīng)急管理控制安全風(fēng)險是一個需要重點關(guān)注的問題。