以信息中心為核心的企業移動應用平臺研究

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

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

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

1 移動辦公平臺需求與技術選擇

1.1 業務需求分析

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

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

1.2 系統非功能性需求

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

1.3 技術選擇

（1）分布式系統架構技術

該技術采用的是J2EE，即Java 2 EntERPrise Edition，是以Java為主導平臺來解決問題的一種體系結構，能解決的問題主要針對解決方案在開發、管理和部署過程中出現的問題，此類問題較為復雜，簡化操作后變得更為方便。該架構的優勢是支持多種客戶端的訪問，使得程序在應用服務器下運行。

（2）構件技術

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

整個構件庫包括有三個大類，為業務構件、行業構件以及基礎構件，基礎構件，業務構件涵蓋有工具構件以及角色構件；行業構件主要針對政府，下級文件則涵蓋產品構件以及單位構件。

（3）XML技術

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

2 移動辦公平臺架構設計

移動辦公平臺的架構設計是基于移動終端系統平臺和企業應用系統之間的中間端，它既可以提供后端系統快速集成，同時在前段各個覆蓋的基礎配套服務設施下實現企業的一些業務事項、業務流程在各個移動設備中輕松操作。

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

圖1 通知待辦界面呈現

3 實現效果分析

3.1 通知待辦形式呈現

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

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

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

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

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

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

3.2 考勤管理形式呈現

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

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

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

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

圖2 考勤界面

請假事宜的操作模塊：

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

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

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