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

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

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

1 移動(dòng)辦公平臺(tái)需求與技術(shù)選擇

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

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

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

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

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

1.3 技術(shù)選擇

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

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

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

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

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

（3）XML技術(shù)

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

2 移動(dòng)辦公平臺(tái)架構(gòu)設(shè)計(jì)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖2 考勤界面

請(qǐng)假事宜的操作模塊：

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

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

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