孫謙誠 江蘇省廣播電視總臺(tái)

基于WEBAPP和B/S的媒體生產(chǎn)調(diào)度系統(tǒng)

孫謙誠 江蘇省廣播電視總臺(tái)

本文研究了基于手機(jī)微信端的WEBAPP和PC端基于B/S架構(gòu)的內(nèi)容生產(chǎn)管理平臺(tái)的設(shè)計(jì)和實(shí)現(xiàn)。該調(diào)度系統(tǒng)通過對(duì)微信企業(yè)號(hào)的定制開發(fā)，結(jié)合傳統(tǒng)PC端的使用，形成以移動(dòng)設(shè)備為簡單處理工作及收集發(fā)布用戶信息，PC設(shè)備為全功能媒體內(nèi)容管理的系統(tǒng)平臺(tái)。

微信企業(yè)號(hào) B/S架構(gòu) 工作流引擎 沖突自動(dòng)檢測

一、引言

江蘇省廣播電視總臺(tái)的大規(guī)模設(shè)備更新擴(kuò)建，眾多的演播室、轉(zhuǎn)播車及衛(wèi)星車添加到總臺(tái)媒體生產(chǎn)的設(shè)備中。這些以演播室、轉(zhuǎn)播車和衛(wèi)星車為設(shè)備集合稱之為單元。節(jié)目單元申請(qǐng)表是技術(shù)部門供節(jié)目部門提交單元申請(qǐng)，使各單元得到有效高效管理的手段。本文介紹的基于WEBAPP和B/S的媒體生產(chǎn)調(diào)度系統(tǒng)可滿足節(jié)目部門申請(qǐng)單元、查看單元審批，提升單元調(diào)度管理人員的管理效率。

二、媒體生產(chǎn)管理系統(tǒng)分析

2.1 系統(tǒng)需求分析

2.1.1 單元分析

根據(jù)媒體生產(chǎn)的業(yè)務(wù)特點(diǎn)以工作地點(diǎn)為分類標(biāo)準(zhǔn)，將總臺(tái)的媒體生產(chǎn)單元分為演播室、轉(zhuǎn)播車、衛(wèi)星車。設(shè)備單元所需的屬性包含：單元序號(hào)、使用單位、預(yù)約時(shí)間、使用日期、開始時(shí)間、結(jié)束時(shí)間、單元用途以及單元使用情況。

2.1.2 業(yè)務(wù)需求

通過對(duì)原有網(wǎng)站的調(diào)研，明確原有網(wǎng)站在日常業(yè)務(wù)工作中的缺失。對(duì)于新建的媒體生產(chǎn)調(diào)度系統(tǒng)，需要提供以下功能：

（1）提供全信息的查詢功能，解決原有系統(tǒng)不可對(duì)單元具體信息以及參與媒體生產(chǎn)工作人員排班情況信息查詢的問題；

（2）提供單元申請(qǐng)的自動(dòng)沖突檢測判斷，彌補(bǔ)原有系統(tǒng)需人工判斷的不足；

（3）提供全流程電子信息化申請(qǐng)；

（4）提供傳統(tǒng)PC端和移動(dòng)端操作；

（5）提供廣域網(wǎng)登錄支持，通過瀏覽器和微信端直接登錄；

（6）提供用戶角色權(quán)限設(shè)置，將系統(tǒng)中的角色設(shè)定為單元管理員、頻道負(fù)責(zé)人、單元調(diào)度員、權(quán)限管理員、消息管理員等；

（7）提供豐富的信息發(fā)布手段，提供系統(tǒng)用戶手機(jī)短信和微信端的信息發(fā)布，完善原有系統(tǒng)信息發(fā)布渠道單一的問題；

（8）提供使用后的數(shù)據(jù)統(tǒng)計(jì)。

2.2 系統(tǒng)架構(gòu)

由于系統(tǒng)面向廣域網(wǎng)及移動(dòng)終端的訪問，系統(tǒng)選擇基于公有云來開發(fā)和運(yùn)行。系統(tǒng)部署在新浪SAE平臺(tái)上，該平臺(tái)具有發(fā)展時(shí)間長，功能完善，文檔完整；支持PHP、Java、Python等語言開發(fā)，支持使用SVN進(jìn)行代碼的高效維護(hù)；覆蓋各大城市的多路骨干網(wǎng)絡(luò)CDN節(jié)點(diǎn)，訪問速度得到保障；提供綜合性短信服務(wù)等眾多優(yōu)勢。

系統(tǒng)為滿足PC端及移動(dòng)端的訪問需求，針對(duì)PC的訪問需求，系統(tǒng)選擇瀏覽器作為用戶入口，針對(duì)移動(dòng)端的訪問需求，系統(tǒng)選擇微信企業(yè)號(hào)作為用戶入口。PC端選擇瀏覽器作為用戶入口可免去用戶安裝和更新軟件，同時(shí)瀏覽器具有跨平臺(tái)的通用性，更好的兼容該系統(tǒng)。移動(dòng)端選擇微信企業(yè)號(hào)作為用戶入口，免去用戶安裝及更新APP的麻煩，關(guān)注企業(yè)號(hào)則相對(duì)操作簡單，減輕系統(tǒng)開發(fā)的運(yùn)維成本。

系統(tǒng)的整體架構(gòu)由三方面組成：用戶終端、微信公眾號(hào)后臺(tái)系統(tǒng)以及SAE后臺(tái)系統(tǒng)。用戶終端提供PC端的瀏覽器訪問系統(tǒng)和移動(dòng)端的微信企業(yè)號(hào)訪問系統(tǒng)。微信企業(yè)號(hào)面向移動(dòng)端用戶，負(fù)責(zé)將用戶的訪問請(qǐng)求轉(zhuǎn)發(fā)至SAE后臺(tái)，同時(shí)把SAE后臺(tái)系統(tǒng)的信息反饋給用戶。后臺(tái)系統(tǒng)是系統(tǒng)處理核心，處理來自PC端瀏覽器和移動(dòng)端微信企業(yè)號(hào)的用戶訪問需求。媒體生產(chǎn)調(diào)度系統(tǒng)整體架構(gòu)如圖1所示。

圖1 媒體生產(chǎn)調(diào)度系統(tǒng)整體架構(gòu)

2.3 業(yè)務(wù)流程分析

2.3.1 單元申請(qǐng)流程

用戶使用PC端通過瀏覽器進(jìn)行單元申請(qǐng)，也可以使用移動(dòng)端通過微信進(jìn)行單元申請(qǐng)，單元申請(qǐng)流程如圖2所示。

圖2 單元申請(qǐng)流程

2.3.2 單元申請(qǐng)修改

在單元申請(qǐng)的流程下，系統(tǒng)提供了單元申請(qǐng)修改功能。單元的類型分為共享型單元和非共享型單元。共享型單元是指該單元已經(jīng)被申請(qǐng)期間內(nèi)允許其他部門申請(qǐng)使用。非共享型單元是指該單元已被申請(qǐng)使用的期間不允許其他部門申請(qǐng)使用。

2.3.3 單元申請(qǐng)撤銷

在單元申請(qǐng)流程下，提供單元申請(qǐng)撤銷功能。單元申請(qǐng)撤銷是指在申請(qǐng)過程中由于節(jié)目錄制計(jì)劃的修改。

2.3.4 用戶及權(quán)限管理

用戶角色分為節(jié)目人員、頻道負(fù)責(zé)人、電視技術(shù)部單元受理執(zhí)行人員、單元調(diào)度人員、權(quán)限管理員、消息管理員、超級(jí)管理員等。用戶及權(quán)限管理如圖3所示。

圖3 用戶及權(quán)限管理

三、媒體生產(chǎn)管理提供功能設(shè)計(jì)和實(shí)現(xiàn)

3.1 PC端系統(tǒng)功能實(shí)現(xiàn)

3.1.1 界面設(shè)計(jì)實(shí)現(xiàn)

通過HTML5/CSS代碼實(shí)現(xiàn)，將主頁分為菜單欄和工作區(qū)。菜單欄中的我的菜單包括“用戶信息”和“單元管理”，工作區(qū)內(nèi)顯示的功能在選擇如單元申請(qǐng)、單元管理等具體功能后顯示。

3.1.2 單元申請(qǐng)、撤銷、修改及審批

選擇工作欄中的單元申請(qǐng)。填寫單元起始日期、時(shí)間和結(jié)束日期、時(shí)間。申請(qǐng)時(shí)，提出關(guān)門時(shí)間這一概念，即申請(qǐng)時(shí)間必須在關(guān)門時(shí)間之外。頻道工作人員在申請(qǐng)單元前，單元的使用情況是其判斷是否可申請(qǐng)的條件。單元狀態(tài)查詢的結(jié)果通過顏色進(jìn)行區(qū)分。白色背景的單元狀態(tài)，表示該單元可以被申請(qǐng)，藍(lán)色背景的單元狀態(tài)，顯示在查詢時(shí)間段內(nèi)的申請(qǐng)可能與其他單元申請(qǐng)單產(chǎn)生沖突。產(chǎn)生沖突的原因可以通過點(diǎn)擊“可能沖突”查看可能產(chǎn)生沖突的其他申請(qǐng)單。這一類顯示“可能沖突”的單元仍然可以申請(qǐng)。背景顏色為紅色的單元查詢結(jié)果表示不可用。單元申請(qǐng)頁面如圖4所示。

圖4 單元申請(qǐng)頁面

系統(tǒng)提供了單元撤銷，可對(duì)已經(jīng)完成審核的申請(qǐng)單進(jìn)行撤銷。用戶可以選擇申請(qǐng)單元部分撤銷或者整體撤銷。

系統(tǒng)提供了單元修改的功能區(qū)。單元修改只針對(duì)共享型單元。非共享型單元由于其特定的設(shè)備要求，如果需要修改，可以先整體撤銷再重新申請(qǐng)。

單元審批作為單元申請(qǐng)流程中的重要節(jié)點(diǎn)，系統(tǒng)提供了完整的三級(jí)審批流程。這些關(guān)鍵流程節(jié)點(diǎn)包括頻道負(fù)責(zé)人、單元管理員和單元負(fù)責(zé)人審批。根據(jù)用戶權(quán)限的設(shè)置，不同用戶登錄系統(tǒng)時(shí)只顯示對(duì)應(yīng)權(quán)限的審批任務(wù)。

3.1.3 單元申請(qǐng)流程可視化顯示

查看審批流程可對(duì)審批全鏈路了解單元審核進(jìn)程所處狀態(tài)。通過顏色來區(qū)分審批流程節(jié)點(diǎn)狀態(tài)，綠色代表單元申請(qǐng)審核正在進(jìn)行中，紅色表示單元申請(qǐng)拒絕，藍(lán)色表示單元申請(qǐng)審批完成。對(duì)于節(jié)點(diǎn)審批結(jié)果的具體信息，提供具體信息懸停顯示功能。流程可視化顯示如圖5所示。

圖5 流程可視化顯示

3.2 移動(dòng)端系統(tǒng)功能實(shí)現(xiàn)

移動(dòng)端系統(tǒng)功能通過手機(jī)微信實(shí)現(xiàn)。移動(dòng)端的系統(tǒng)簡化PC端的功能，提供用戶快速簡便的單元申請(qǐng)需求。功能上實(shí)現(xiàn)了用戶的在線注冊(cè)，單元申請(qǐng)，單元申請(qǐng)管理，人員管理以及根據(jù)用戶角色的消息推送。

3.2.1 移動(dòng)端系統(tǒng)主頁面實(shí)現(xiàn)

作為移動(dòng)端常用的系統(tǒng)功能，包括單元申請(qǐng)、我的申請(qǐng)單、我的撤銷單、我的修改單、我的排班表等，在移動(dòng)端的顯示更多是對(duì)申請(qǐng)審核的確認(rèn)的消息，而需要在移動(dòng)端中進(jìn)行的操作并不多。微信移動(dòng)端頁面如圖6所示。

圖6 微信移動(dòng)端頁面

3.2.2 公眾號(hào)、用戶驗(yàn)證等功能實(shí)現(xiàn)

實(shí)名認(rèn)證是通過微信端關(guān)注公眾號(hào)后，系統(tǒng)后期根據(jù)用戶錄入的信息，通過人工審核，從而確定是否通過認(rèn)證。

移動(dòng)端的單元申請(qǐng)和PC端的單元申請(qǐng)規(guī)則一致，但對(duì)申請(qǐng)信息做了簡化，其中只對(duì)節(jié)目名稱，開始、結(jié)束時(shí)間等信息進(jìn)行填寫。

通過系統(tǒng)申請(qǐng)的各類單據(jù)，它的審核情況都可以在移動(dòng)端查詢。頁面將自動(dòng)呈現(xiàn)各類申請(qǐng)單的狀況。

四、系統(tǒng)核心功能設(shè)計(jì)與實(shí)現(xiàn)

4.1 流程驅(qū)動(dòng)引擎

超級(jí)單元表使用流程引擎作為模塊工具，自主開發(fā)，充分吸收國內(nèi)使用JBPM開發(fā)BOSS中遇到的問題，工作流引擎只負(fù)責(zé)參數(shù)的收集和流程的流轉(zhuǎn)，具體業(yè)務(wù)的控制，交給每一個(gè)流程定制的控制類去實(shí)現(xiàn)。

工作流定義和工作流引擎密切相關(guān)，工作流的定義工具負(fù)責(zé)將現(xiàn)實(shí)世界多種確定的業(yè)務(wù)流程翻譯并執(zhí)行工作流定義。充分利用PHP語言的特點(diǎn)，流程設(shè)計(jì)基于數(shù)據(jù)庫，程序上采用OO設(shè)計(jì)，但采用重對(duì)象的方法，不將可視化設(shè)計(jì)流程的工作交給最終用戶，而是在設(shè)計(jì)時(shí)完成，因此不用考慮流程版本更新的問題。

4.1.1 工作流數(shù)據(jù)表設(shè)計(jì)

工作流數(shù)據(jù)最直接的區(qū)分是將存儲(chǔ)在業(yè)務(wù)系統(tǒng)中的數(shù)據(jù)稱為業(yè)務(wù)數(shù)據(jù)，將存儲(chǔ)于工作流系統(tǒng)中的數(shù)據(jù)稱為工作流數(shù)據(jù)。而工作流數(shù)據(jù)分為工作流控制數(shù)據(jù)和工作流相關(guān)數(shù)據(jù)。工作流控制數(shù)據(jù)是工作流系統(tǒng)管理的數(shù)據(jù)，這些數(shù)據(jù)包括了參與流程和任務(wù)的執(zhí)行數(shù)據(jù)。工作流相關(guān)數(shù)據(jù)是在流程中參與業(yè)務(wù)執(zhí)行的相關(guān)數(shù)據(jù)。

4.1.2 PHP實(shí)現(xiàn)

在PHP實(shí)現(xiàn)時(shí)，首先定義工作流驅(qū)動(dòng)類Workflow，由它去完成流程跳轉(zhuǎn)邏輯的實(shí)現(xiàn)，它根據(jù)節(jié)點(diǎn)類型以及節(jié)點(diǎn)執(zhí)行的返回?cái)?shù)據(jù)自動(dòng)實(shí)現(xiàn)流程驅(qū)動(dòng)。數(shù)據(jù)庫采用MySQL。在Workflow類創(chuàng)建時(shí)，其構(gòu)造函數(shù)會(huì)初始化創(chuàng)建的是哪種流程，根據(jù)流程執(zhí)行節(jié)點(diǎn)查詢調(diào)用該流程模板每個(gè)節(jié)點(diǎn)對(duì)應(yīng)的執(zhí)行函數(shù)，實(shí)現(xiàn)業(yè)務(wù)執(zhí)行的流程驅(qū)動(dòng)。

以initThread方法實(shí)現(xiàn)為例，該方法是初始化為工作流內(nèi)部的調(diào)用，通過從表t_proc_node中讀取進(jìn)程名稱procName和節(jié)點(diǎn)ID nodeID。將表中的initFunction流程初始函數(shù)、nodeType節(jié)點(diǎn)類型、nodeIndex節(jié)點(diǎn)序號(hào)、prevNodeIndex前一節(jié)點(diǎn)序號(hào)和nodeName節(jié)點(diǎn)名稱讀取，并將流程初始函數(shù)等值存儲(chǔ)于initArr數(shù)組中，接著更新數(shù)據(jù)庫信息。在數(shù)據(jù)無出錯(cuò)的情況下進(jìn)入節(jié)點(diǎn)類型的選擇。在情況1下，意味著該節(jié)點(diǎn)類型需要手動(dòng)處理，后續(xù)工作需要人工處理后調(diào)用，此時(shí)將在數(shù)據(jù)庫中新建節(jié)點(diǎn)，將節(jié)點(diǎn)序號(hào)、節(jié)點(diǎn)名稱等值添加到數(shù)據(jù)節(jié)點(diǎn)中。在此過程中如果對(duì)初始化函數(shù)已經(jīng)有了設(shè)置，初始化結(jié)果則返回設(shè)置的進(jìn)程序號(hào)。在情況2下，意味著該節(jié)點(diǎn)類型為自動(dòng)處理節(jié)點(diǎn)，將自動(dòng)更新節(jié)點(diǎn)信息，并執(zhí)行節(jié)點(diǎn)。在情況3下，假設(shè)情況是判斷節(jié)點(diǎn)，需要調(diào)用上一節(jié)點(diǎn)的數(shù)據(jù)來判斷下一節(jié)點(diǎn)走向，為依靠外部數(shù)據(jù)來響應(yīng)。情況4下，為分支并行的節(jié)點(diǎn)，通過for語句獲取表中所有的子節(jié)點(diǎn)信息。情況5下是將分支節(jié)點(diǎn)合并。情況6是結(jié)束節(jié)點(diǎn)。以下以偽代碼形式顯示：

初始化讀取數(shù)據(jù)

if 數(shù)據(jù)庫表不存在該數(shù)據(jù)

then 跳轉(zhuǎn)錯(cuò)誤結(jié)束處理

else 讀取表中initFunction、nodeType等變量數(shù)據(jù)、修改process

表節(jié)點(diǎn)為當(dāng)前節(jié)點(diǎn)

if 有錯(cuò)誤

then initResult返回error，直接跳轉(zhuǎn)至結(jié)束

else swich（$nodeType）判斷當(dāng)前節(jié)點(diǎn)類型

case1 手動(dòng)處理節(jié)點(diǎn)，需后續(xù)人工處理

case2 自動(dòng)處理節(jié)點(diǎn)

case3 先調(diào)用上一節(jié)點(diǎn)數(shù)據(jù)，判斷節(jié)點(diǎn)走向

case4 分支并行

for（i=0，i

讀取節(jié)點(diǎn)ID，進(jìn)程ID

case5 合并運(yùn)行節(jié)點(diǎn)

case6 結(jié)束節(jié)點(diǎn)

執(zhí)行進(jìn)程方法runThread方法和transitThread方法也使用類似情況判斷方法來執(zhí)行。

新建流程、獲取臨時(shí)保存參數(shù)、初始化進(jìn)程、初始化線程、獲取線程ID、結(jié)束進(jìn)程、增加線程、保存線程、執(zhí)行線程等方法的實(shí)現(xiàn)組成了整個(gè)工作流引擎功能。

4.2 智能化沖突檢測

在申請(qǐng)單沖突檢測算法中有四個(gè)判斷節(jié)點(diǎn)，分別是每一項(xiàng)時(shí)間申請(qǐng)的開始時(shí)間是否大于結(jié)束時(shí)間，申請(qǐng)單元是否為共享單元以及兩個(gè)節(jié)點(diǎn)的沖突判斷。

開始時(shí)需提取申請(qǐng)單、子項(xiàng)目的起止時(shí)間等，再將獲取的時(shí)間換算成秒。在此基礎(chǔ)上對(duì)每一項(xiàng)時(shí)間做是否是跨天申請(qǐng)的判斷。對(duì)該單元是否為非共享單元判斷，如果是則將申請(qǐng)單的總起止時(shí)間和已經(jīng)審核通過的申請(qǐng)單總起止時(shí)間比對(duì)，如果不是非共享單元?jiǎng)t分別對(duì)每個(gè)子項(xiàng)時(shí)間作比對(duì)。對(duì)這些數(shù)據(jù)進(jìn)行比對(duì)后，如比對(duì)結(jié)果沖突則返回沖突值，若不沖突則結(jié)束檢測。體現(xiàn)在申請(qǐng)業(yè)務(wù)中即是可否申請(qǐng)?jiān)搯卧?。申?qǐng)單沖突檢測算法如圖7所示。

圖7 申請(qǐng)單沖突檢測算法

申請(qǐng)單中有關(guān)時(shí)間的子項(xiàng)信息眾多，且這些時(shí)間信息往往跨越很多天，在判斷中如果將之作為整體數(shù)據(jù)進(jìn)行比較，則會(huì)出現(xiàn)總時(shí)間計(jì)算實(shí)現(xiàn)復(fù)雜。而以申請(qǐng)單編譯表為代表的后端研發(fā)主要包括：代表式列表以及字節(jié)代碼兩部分開發(fā)。

申請(qǐng)單編譯表，將申請(qǐng)單拆分為每一天的申請(qǐng)單，對(duì)每天的申請(qǐng)單做沖突判斷，所以在算法設(shè)計(jì)上對(duì)于跨天的單元申請(qǐng)只需要對(duì)結(jié)束時(shí)間增加24小時(shí)，這樣做簡化了判斷，更可以根據(jù)用戶需求，對(duì)申請(qǐng)單中的某幾日做修改等。

通過PHP語言將函數(shù)dysqdCompile實(shí)現(xiàn)，該函數(shù)的變量是申請(qǐng)單的單號(hào)。通過對(duì)數(shù)據(jù)表t_thread中dysqdID的提取，將跟隨單號(hào)下的申請(qǐng)時(shí)間，包括總起止時(shí)間等信息從data數(shù)組中提取。將以“-”為分隔符的填寫時(shí)間“Y-m-d”組成臨時(shí)時(shí)間數(shù)組temp1_arr、temp2_ arr，使用mktime方法將兩個(gè)數(shù)組的數(shù)據(jù)轉(zhuǎn)化成day1和day2數(shù)據(jù)，申請(qǐng)單的總天數(shù)days則是通過(（day2-day1）/3600/24)+1的方法實(shí)現(xiàn)。days數(shù)據(jù)做為申請(qǐng)單編譯表拆分的重要數(shù)據(jù)，將申請(qǐng)單中申請(qǐng)時(shí)間數(shù)據(jù)拆分成以一天為單位的多個(gè)申請(qǐng)單。

4.3 自動(dòng)化消息通知及確認(rèn)機(jī)制

自動(dòng)化消息通知及確認(rèn)機(jī)制主要分為微信和短信消息兩部分。微信消息通知主要利用微信后臺(tái)系統(tǒng)建立模板消息，系統(tǒng)調(diào)用微信公眾平臺(tái)提供的接口實(shí)現(xiàn)模板消息的發(fā)送。

短信通知功能則為自行研發(fā)，通過短信貓實(shí)現(xiàn)短信的發(fā)送。

五、總結(jié)

基于WEBAPP和B/S的媒體生產(chǎn)設(shè)備管理系統(tǒng)的創(chuàng)新點(diǎn)主要有以下五點(diǎn)：

（1）以微信公眾號(hào)為入口，采用B/S架構(gòu)同時(shí)支持移動(dòng)端和PC端操作。

（2）系統(tǒng)采用工作流引擎驅(qū)動(dòng)，實(shí)現(xiàn)流程可視化操作。

（3）具備多種信息發(fā)布手段，實(shí)現(xiàn)自動(dòng)化的消息推送通知。

（4）利用公有云平臺(tái)資源，最大限度降低了開發(fā)和運(yùn)維量。

（5）采用智能的沖突互斥算法，大大提高單元申請(qǐng)和審批的效率。

該項(xiàng)目解決了節(jié)目生產(chǎn)過程中對(duì)設(shè)備單元申請(qǐng)使用等方面的問題，滿足了江蘇電視臺(tái)現(xiàn)代化生產(chǎn)的需求。