專利名稱：文件任務管理工具的制作方法
技術領域：
本申請涉及計算機技術領域，特別是涉及一種文件任務管理工具。
背景技術：
傳統(tǒng)的文件分發(fā)方式為，以單個設備為中心，將文件分發(fā)到多個設備上。在文件 分發(fā)的過程中，現(xiàn)有的文件任務管理工具在分發(fā)任務的過程中一般采用單線程順序方式分 發(fā)，在分發(fā)完一個處理設備后，再依次對其它處理設備進行分發(fā)，處理時間長；且在分發(fā)結 束后，任務管理工具不能獲知任務是否分發(fā)成功，不能及時對任務進行更新管理?？梢姮F(xiàn)有的文件任務管理工具在文件分發(fā)過程中，分發(fā)速度慢，且不能和任務處 理服務器進行有效交互。

發(fā)明內容
為解決上述技術問題，本申請實施例提供一種文件任務管理工具，以多線程方式 對任務進行分發(fā)，提高任務的分發(fā)速度，且設置有任務執(zhí)行狀態(tài)處理模塊，實現(xiàn)了與任務處 理服務器之間的交互。技術方案如下一種文件任務管理工具，包括任務接收模塊、任務處理模塊、任務發(fā)送模塊和任 務執(zhí)行狀態(tài)處理模塊；其中所述任務接收模塊用于接收文件總任務；所述任務處理模塊用于讀取所述任務接收模塊接收的文件總任務，并根據(jù)系統(tǒng)配 置生成所述文件總任務的子任務；所述任務發(fā)送模塊用于啟動多線程將所述任務處理模塊生成的子任務發(fā)送至系 統(tǒng)中的任務處理服務器；所述任務執(zhí)行狀態(tài)處理模塊用于接收所述任務處理服務器發(fā)送的對所述子任務 的執(zhí)行狀態(tài)的信息，并根據(jù)所述信息對所述任務接收模塊接收的文件總任務進行更新。上述的管理工具，優(yōu)選的，所述任務接收模塊接收的文件總任務是文件分發(fā)過程 中所有屬性描述信息以及需要分發(fā)該文件的客戶信息；包括外部用戶提交的任務和系統(tǒng)內 部提交的任務。上述的管理工具，優(yōu)選的，所述任務接收模塊接收外部用戶提交的任務時還包括 對外部用戶的驗證過程。上述的管理工具，優(yōu)選的，所述驗證過程包括對用戶的用戶名、密碼及有效性的驗 證。上述的管理工具，優(yōu)選的，所述任務處理模塊根據(jù)系統(tǒng)配置并根據(jù)預設策略生成 所述文件總任務的子任務。上述的管理工具，優(yōu)選的，所述任務發(fā)送模塊以http協(xié)議將所述子任務發(fā)送至任 務處理服務器，每次發(fā)送的任務數(shù)量不超預設閥值；所述閥值的大小根據(jù)任務處理服務器的處理能力進行設定。上述的管理工具，優(yōu)選的，所述任務執(zhí)行狀態(tài)處理模塊接收到任務處理服務器發(fā) 送的對所述子任務的執(zhí)行狀態(tài)信息后，對所述執(zhí)行狀態(tài)信息進行判斷，包括
判斷所述分發(fā)任務的任務處理服務器是否分發(fā)任務成功；判斷分發(fā)成功的任務處理服務器是否可發(fā)送任務至其它任務處理服務器；判斷接收后，根據(jù)判斷結果對任務結構模塊接收的文件總任務進行更新。由以上本申請實施例提供的技術方案可見，本發(fā)明提供的文件任務管理工具，設 置有任務處理模塊，將文件總任務根據(jù)系統(tǒng)配置生成文件子任務，任務發(fā)送模塊啟動多線 程，將生成的文件子任務，發(fā)送至任務管理服務器，每個線程可以同時發(fā)送多個任務至任務 管理服務器，提高了任務的分發(fā)速度和分發(fā)效率；同時該管理工具中設置有任務執(zhí)行狀態(tài) 處理模塊，可以接收任務處理服務器反饋的任務處理狀態(tài)信息，根據(jù)任務處理狀態(tài)信息，對 任務的執(zhí)行狀態(tài)進行判斷，得出判斷結果，對文件的總任務進行更新，實現(xiàn)了與任務處理服 務器之間的信息交互。


為了更清楚地說明本申請實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn) 有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本 申請中記載的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下， 還可以根據(jù)這些附圖獲得其他的附圖。圖1為本申請實施例提供的文件任務管理工具的結構示意圖；圖2為本申請實施例提供的文件任務管理工具的另一個結構示意圖；圖3為本申請實施例提供的設置了驗證模塊的文件任務管理工具的結構示意圖；圖4為本申請實施例提供的設置了策略模塊的文件任務管理工具的結構示意圖；圖5為本申請實施例提供的設置了判斷模塊的文件任務管理工具的結構示意圖。
具體實施例方式為了使本技術領域的人員更好地理解本申請方案。下面將結合本申請實施例中的 附圖，對本申請實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是 本申請一部分實施例，而不是全部的實施例。基于本申請中的實施例，本領域普通技術人員 在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都應當屬于本申請保護的范圍。本申請實施例提供的文件任務管理工具的結構示意圖如圖1所示，包括任務結 構模塊101、任務處理模塊102、任務發(fā)送模塊103和任務執(zhí)行狀態(tài)處理模塊104 ；其中任務接收模塊101用于接收文件總任務；系統(tǒng)提供標準的http協(xié)議接口接收任務；任務處理模塊102用于讀取任務接收模塊101接收的文件總任務，并根據(jù)系統(tǒng)配 置生成所述文件總任務的子任務；任務發(fā)送模塊103用于啟動多線程將任務處理模塊102生成的子任務發(fā)送至系統(tǒng) 中的任務處理服務器105 ；任務執(zhí)行狀態(tài)處理模塊104用于接收任務處理服務器105發(fā)送的對子任務的執(zhí)行狀態(tài)的信息，并根據(jù)所述信息對任務接收模塊101接收的文件總任務進行更新。本申請實施例提供的文件任務管理工具中任務接收模塊接收的文件總任務是指 以個需要分發(fā)的文件所有描述信息，以及需要分發(fā)這個文件的客戶信息；任務處理模塊生 成的子任務是指以個文件所需要分發(fā)到的設備的信息。其中總任務包括外部用戶提交的任務和系統(tǒng)內部提交的任務。外部用戶提交任務時，系統(tǒng)會對客戶的身份進行驗證，包括用戶名、密碼、有效性 等。系統(tǒng)內部提交任務時不需要進行驗證，只要格式符合則可以對提交的任務進行保存。本申請實施例提供的文件任務管理工具的另一個結構示意圖如圖2，任務接收模 塊101可以將整個系統(tǒng)的任務以及配置存儲在數(shù)據(jù)庫106中，任務處理模塊102讀取存儲 在數(shù)據(jù)庫中的總任務，根據(jù)系統(tǒng)的配置生成子任務。本申請實施例提供的設置了驗證模塊的文件任務管理工具的結構示意圖如圖3 所示，文件任務管理工具中的任務接收模塊101中設置有驗證模塊，用于對用戶上傳任務 時，對用戶進行驗證。本申請實施例提供的設置了策略模塊的文件任務管理工具的結構示意圖如圖4 所示，文件任務管理工具中的任務處理模塊102中設置有策略模塊108，策略模塊中預設有 預設子任務生成策略，任務處理模塊102根據(jù)策略模塊108中預設的策略生成子任務，根據(jù) 策略進行子任務生成的過程包括判斷用戶的狀態(tài)是否可用，如不可用，則不生成任務；判斷用戶的優(yōu)先級狀態(tài)，對優(yōu)先級高的用戶首先生成子任務；判斷所有需要分發(fā)子任務的任務處理服務器是否工作正常，如果文件任務處理服 務器不可用，則不生成任務；判斷所有需要分發(fā)子任務的任務處理服務器是否共享同一個存儲(此處存儲的 概念為多個設備用NFS共享同一個存儲單元)，如果多個設備共享同一個存儲，則選擇一個 此時任務最少的設備進行分發(fā)；判斷設備使用何種協(xié)議進行同步，如果為P2P協(xié)議則沒有上層任務處理服務器， 如果為http，或UDP協(xié)議則需要指定上層任務處理服務器。本申請實施例提供的文件任務管理工具中任務發(fā)送模塊將已經(jīng)生成的子任務以 http協(xié)議方式發(fā)送到多個任務處理服務器上，發(fā)送任務時，以多線程方式發(fā)送，每個線程負 責多個任務處理服務器，每個設備的任務一次發(fā)送，每次發(fā)送的任務數(shù)量不超過預先設置 的閥值，如100個，該閥值的大小可根據(jù)任務處理服務器的處理能力進行設定，發(fā)送任務會 不停的重試，直至任務發(fā)送成功。本申請實施例提供的文件任務管理工具中任務執(zhí)行狀態(tài)處理模塊負責接收任務 處理服務器任務執(zhí)行狀態(tài)的反饋；本申請實施例提供的設置了判斷模塊的文件任務管理工 具的結構示意圖如圖5所示，在接收到任務執(zhí)行狀態(tài)的反饋信息后，判斷模塊109會判斷任 務執(zhí)行情況，包括判斷是否所有需要分發(fā)的任務處理服務器都分發(fā)任務成功；判斷分發(fā)任務成功的任務處理服務器是否可以繼續(xù)對其下層的任務處理服務器 進行任務分發(fā)；根據(jù)判斷的結果對任務接收模塊接收的文件總任務或存儲在數(shù)據(jù)庫中的文件總
5任務進行更新。 本說明書中的各個實施例均采用遞進的方式描述，各個實施例之間相同相似的部 分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。以上所述僅是本 申請的具體實施方式
，應當指出，對于本技術領域的普通技術人員來說，在不脫離本申請原 理的前提下，還可以做出若干改進和潤飾，這些改進和潤飾也應視為本申請的保護范圍。
權利要求
一種文件任務管理工具，其特征在于，包括任務接收模塊、任務處理模塊、任務發(fā)送模塊和任務執(zhí)行狀態(tài)處理模塊；其中所述任務接收模塊用于接收文件總任務；所述任務處理模塊用于讀取所述任務接收模塊接收的文件總任務，并根據(jù)系統(tǒng)配置生成所述文件總任務的子任務；所述任務發(fā)送模塊用于啟動多線程將所述任務處理模塊生成的子任務發(fā)送至系統(tǒng)中的任務處理服務器；所述任務執(zhí)行狀態(tài)處理模塊用于接收所述任務處理服務器發(fā)送的對所述子任務的執(zhí)行狀態(tài)的信息，并根據(jù)所述信息對所述任務接收模塊接收的文件總任務進行更新。
2.根據(jù)權利要求1所述的管理工具，其特征在于，所述任務接收模塊接收的文件總任 務是文件分發(fā)過程中所有屬性描述信息以及需要分發(fā)該文件的客戶信息；包括外部用戶提 交的任務和系統(tǒng)內部提交的任務。
3.根據(jù)權利要求2所述的管理工具，其特征在于，所述任務接收模塊接收外部用戶提 交的任務時還包括對外部用戶的驗證過程。
4.根據(jù)權利要求3所述的管理工具，其特征在于，所述驗證過程包括對用戶的用戶名、 密碼及有效性的驗證。
5.根據(jù)權利要求1所述的管理工具，其特征在于，所述任務處理模塊根據(jù)系統(tǒng)配置并 根據(jù)預設策略生成所述文件總任務的子任務。
6.根據(jù)權利要求1所述的管理工具，其特征在于，所述任務發(fā)送模塊以http協(xié)議將所 述子任務發(fā)送至任務處理服務器，每次發(fā)送的任務數(shù)量不超預設閥值；所述閥值的大小根 據(jù)任務處理服務器的處理能力進行設定。
7.根據(jù)權利要求1所述的管理工具，其特征在于，所述任務執(zhí)行狀態(tài)處理模塊接收到 任務處理服務器發(fā)送的對所述子任務的執(zhí)行狀態(tài)信息后，對所述執(zhí)行狀態(tài)信息進行判斷， 包括判斷所述分發(fā)任務的任務處理服務器是否分發(fā)任務成功；判斷分發(fā)成功的任務處理服務器是否可發(fā)送任務至其它任務處理服務器；判斷接收后，根據(jù)判斷結果對任務結構模塊接收的文件總任務進行更新。
全文摘要
本發(fā)明公開了一種文件任務管理工具，包括任務接收模塊、任務處理模塊、任務發(fā)送模塊和任務執(zhí)行狀態(tài)處理模塊；其中任務處理模塊，將文件總任務根據(jù)系統(tǒng)配置生成文件子任務，任務發(fā)送模塊啟動多線程，將生成的文件子任務，發(fā)送至任務管理服務器，每個線程可以同時發(fā)送多個任務至任務管理服務器，提高了任務的分發(fā)速度和分發(fā)效率；同時該管理工具中設置有任務執(zhí)行狀態(tài)處理模塊，可以接收任務處理服務器反饋的任務處理狀態(tài)信息，根據(jù)任務處理狀態(tài)信息，對任務的執(zhí)行狀態(tài)進行判斷，得出判斷結果，對文件的總任務進行更新，實現(xiàn)了與任務處理服務器之間的信息交互。
文檔編號G06F17/30GK101980206SQ20101053442
公開日2011年2月23日 申請日期2010年11月5日 優(yōu)先權日2010年11月5日
發(fā)明者劉賓, 周福, 楊凡, 蔣建平 申請人:北京云快線軟件服務有限公司;北京世紀互聯(lián)工程技術服務有限公司