專利名稱：一種基于訂閱的數(shù)據(jù)預(yù)警方法
技術(shù)領(lǐng)域：
本發(fā)明涉及到一種計算機應(yīng)用軟件數(shù)據(jù)預(yù)警的方法，具體地說是一種基于訂閱的 數(shù)據(jù)預(yù)警方法，特別是一種基于訂閱的計算機應(yīng)用軟件數(shù)據(jù)的預(yù)警，基于訂閱的預(yù)警實現(xiàn) 了檢測與處理的分離。
背景技術(shù)：
計算機數(shù)據(jù)預(yù)警是實時或者定時的檢測計算機系統(tǒng)中滿足某些特征值的數(shù)據(jù)，并 對其進行處理的過程。計算機數(shù)據(jù)預(yù)警通常有兩部分組成數(shù)據(jù)檢測和數(shù)據(jù)處理。由于計 算機系統(tǒng)中數(shù)據(jù)非常多，僅靠人工方式查找滿足某些特征值的數(shù)據(jù)進行處理既不及時也不 滿足自動化的需求，所以計算機數(shù)據(jù)預(yù)警是當(dāng)前計算機軟件中比較常用的一種技術(shù)。現(xiàn)有的預(yù)警主要有兩個階段構(gòu)成預(yù)警定義和預(yù)警執(zhí)行。預(yù)警定義一般有系統(tǒng)管 理員完成，接收人無法參與。在成功檢測到滿足指定特征的數(shù)據(jù)之后就會觸發(fā)數(shù)據(jù)處理。一 般情況下數(shù)據(jù)處理是一種消息通知。這種現(xiàn)有的預(yù)警方式無法滿足用戶在通知方式、通知 頻率上的個性化需求。比如用戶A希望使用郵件方式接受消息、用戶B希望使用短信方式接 受消息，并且接受方式是可以按照用戶的意愿隨意進行修改。另外在數(shù)據(jù)處理頻率上，現(xiàn)有 的預(yù)警方式只能與數(shù)據(jù)檢測頻率一致，也無法滿足用戶對接收消息頻率自定義的需求。此 外，現(xiàn)有的預(yù)警方式是由管理員或者維護人員來維護消息的接受人、發(fā)送方式和內(nèi)容的，其 他人員如果需要接收此預(yù)警只能聯(lián)系管理員修改接收人，預(yù)警維護的成本也很高。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種基于訂閱的計算機數(shù)據(jù)的預(yù)警實現(xiàn)方法。本發(fā)明的目的是按以下方式實現(xiàn)的，基于訂閱的預(yù)警方法實現(xiàn)了數(shù)據(jù)檢測與數(shù)據(jù) 處理的分離，系統(tǒng)管理員或者維護人員定義數(shù)據(jù)檢測的條件及執(zhí)行頻率。普通用戶可以訂 閱此定義，并設(shè)置自己通知方式、通知內(nèi)容和訂閱頻率。數(shù)據(jù)檢測與處理分離之后，接收用 戶變成參與者，用戶可以在訂閱中定義自己喜好的通知方式、通知內(nèi)容和訂閱頻率。數(shù)據(jù)檢 測頻率和訂閱頻率可以不一致，滿足了不同用戶對數(shù)據(jù)及時性和頻度不同需求的支持，同 一個預(yù)警可以在不同的時間以不同的通知方式告知。比如周末有人要求不接受通知，出差 時間不接受通知?；谟嗛喌臄?shù)據(jù)預(yù)警方法有定義時和運行時兩階段構(gòu)成。定義時有數(shù)據(jù)檢測定 義、訂閱定義兩個部分實現(xiàn)。運行時有生成取數(shù)計劃、執(zhí)行取數(shù)、存儲取數(shù)數(shù)據(jù)、分發(fā)訂閱四 部分組成。1)定義時定義時主要完成對預(yù)警的定義，定義時主要分為數(shù)據(jù)檢測定義和訂閱定義，數(shù)據(jù) 檢測定義與訂閱定義的關(guān)系如圖一所示，它們的關(guān)系是一對多的關(guān)系，一個數(shù)據(jù)檢測定義 可被訂閱。數(shù)據(jù)檢測定義和訂閱定義的流程圖如圖二。c)數(shù)據(jù)檢測定義的主要步驟有
>步驟一數(shù)據(jù)檢測頻率定義。定義預(yù)警檢測的頻率和開始、結(jié)束時間。>步驟二 數(shù)據(jù)檢測定義。數(shù)據(jù)檢測定義有預(yù)警條件定義和數(shù)據(jù)結(jié)果結(jié)構(gòu)定義兩 部分組成。>步驟三訂閱參數(shù)定義。定義數(shù)據(jù)檢測定義(即預(yù)警條件)中可被訂閱者賦值 的參數(shù)。優(yōu)選的，步驟二中提到的預(yù)警條件定義是定義預(yù)警的數(shù)據(jù)源和在數(shù)據(jù)源上的過濾 條件，過濾條件的值可以設(shè)置為訂閱參數(shù)，由訂閱用戶在訂閱時賦值。優(yōu)選的，步驟二中提到的數(shù)據(jù)結(jié)果結(jié)構(gòu)定義是定義預(yù)警結(jié)果集的數(shù)據(jù)結(jié)構(gòu)，訂閱 用戶可以使用此數(shù)據(jù)結(jié)構(gòu)訪問訂閱到的數(shù)據(jù)，并組織通知內(nèi)容。優(yōu)選的，預(yù)警執(zhí)行時會根據(jù)訂閱參數(shù)的賦值情況生成取數(shù)計劃并執(zhí)行預(yù)警。d)訂閱定義的主要步驟有>步驟一訂閱參數(shù)賦值。定義訂閱者關(guān)心的預(yù)警過濾條件的實際值。>步驟二訂閱頻率定義。定義訂閱的接收頻率。筍步驟三數(shù)據(jù)再加工條件定義。在取數(shù)計劃提取的數(shù)據(jù)基礎(chǔ)上再進行條件過濾， 此次過濾之后的數(shù)據(jù)是真正預(yù)警的數(shù)據(jù)。>步驟四訂閱定義。定義通知方式定義、通知內(nèi)容定義和接收人定義。優(yōu)選的，步驟二中的訂閱頻率需要從數(shù)據(jù)檢測頻率中選取，不能是數(shù)據(jù)檢測頻率 之外的時間。優(yōu)選的，步驟二中訂閱頻率也可以指定有效期，比如只能在工作日和工作時間內(nèi) 訂閱預(yù)警。優(yōu)選的，步驟四中的通知方式定義主要選擇系統(tǒng)支持的通知方式，比如郵件方式、
短信方式等。優(yōu)選的，步驟四中的通知內(nèi)容是定義通知的格式和參數(shù)，在發(fā)送通知時，系統(tǒng)會把 參數(shù)替換為預(yù)警數(shù)據(jù)，形成通知并發(fā)送。2)運行時運行時主要有生成取數(shù)計劃、取數(shù)、數(shù)據(jù)存儲、分發(fā)訂閱四部分組成。分發(fā)訂閱又 有訂閱用戶數(shù)據(jù)再加工、生成通知、發(fā)送通知三部分組成。具體的處理流程如圖三所示。運行時按照流程的具體執(zhí)行步驟如下>步驟一生成取數(shù)計劃。由于訂閱頻率與數(shù)據(jù)檢測頻率的不同，與數(shù)據(jù)檢測定義 對應(yīng)的所有訂閱并不都需要執(zhí)行，并且由于訂閱參數(shù)可能存在相同的情況，為了過濾有效 訂閱者并提高預(yù)警執(zhí)行的效率，所以在預(yù)警執(zhí)行時需要首先生成取數(shù)計劃。取數(shù)計劃的內(nèi) 容包括取數(shù)條件、訂閱參數(shù)值和訂閱列表。>步驟二 取數(shù)。生成取數(shù)計劃之后，系統(tǒng)會對取數(shù)計劃中的任務(wù)逐一執(zhí)行。>步驟三數(shù)據(jù)存儲。取數(shù)完成之后，系統(tǒng)會把結(jié)果集，以及結(jié)果集與訂閱列表進 行存儲。>步驟四分發(fā)訂閱。按照取數(shù)計劃中記錄的訂閱列表發(fā)布訂閱信息。分發(fā)訂閱 有數(shù)據(jù)再加工、生成通知、發(fā)送通知組成。優(yōu)選的，步驟一中的過濾有效訂閱者的規(guī)則為如果訂閱頻率中存在與當(dāng)前預(yù)警 執(zhí)行的時間點相同的時間，并且當(dāng)前預(yù)警時間點滿足訂閱者對訂閱有效期的限制，則認為此訂閱是本次預(yù)警的有效訂閱。優(yōu)選的，步驟一中過濾出有效訂閱者之后，系統(tǒng)根據(jù)每個訂閱者的訂閱參數(shù)賦值 情況生成取數(shù)計劃。生成取數(shù)計劃的規(guī)則為如果一個訂閱者的訂閱參數(shù)與其他訂閱者的 訂閱參數(shù)的賦值情況完全相同，則認為這些訂閱可以合并為一次取數(shù)，并生成一個計劃，此 計劃與這些訂閱關(guān)聯(lián)。優(yōu)選的，步驟四中的數(shù)據(jù)再加工是指在數(shù)據(jù)存儲完畢之后，系統(tǒng)會針對每個訂閱 觸發(fā)一個流程，此流程根據(jù)數(shù)據(jù)與訂閱的對照關(guān)系逐個觸發(fā)預(yù)警的訂閱。在訂閱中，首先根 據(jù)訂閱者設(shè)置的數(shù)據(jù)再加工條件對數(shù)據(jù)進行再次過濾，過濾之后的數(shù)據(jù)是預(yù)警的數(shù)據(jù)。優(yōu)選的，步驟四中的生成通知是把通知內(nèi)容中的參數(shù)替換為預(yù)警的數(shù)據(jù)，并生成 郵件或者短信可接收的數(shù)據(jù)格式。優(yōu)選的，步驟四中的發(fā)送通知是根據(jù)通知方式調(diào)用不同消息發(fā)送程序執(zhí)行消息的 發(fā)送。優(yōu)選的，基于訂閱的數(shù)據(jù)預(yù)警方法雖然實現(xiàn)了取數(shù)與通知的分離，但也支持現(xiàn)有 的預(yù)警方式。本發(fā)明與現(xiàn)有的預(yù)警方法相比有以下優(yōu)點基于訂閱的預(yù)警方法由預(yù)警定義和預(yù)警執(zhí)行兩大部分組成。預(yù)警定義又分為數(shù)據(jù) 檢測定義和訂閱定義；預(yù)警執(zhí)行有生成取數(shù)計劃、取數(shù)、數(shù)據(jù)存儲、分發(fā)訂閱四部分組成。分 發(fā)訂閱又有訂閱用戶數(shù)據(jù)再加工、生成通知、發(fā)送通知三部分組成?；谟嗛喌念A(yù)警方法解決現(xiàn)有預(yù)警在維護、通知方式和通知頻率個性化等方面的 需求?；谟嗛喌念A(yù)警方法實現(xiàn)了數(shù)據(jù)檢測與通知的分離，系統(tǒng)管理員或者維護人員定義 數(shù)據(jù)檢測的條件、條件參數(shù)和頻率，即數(shù)據(jù)檢測定義，普通用戶可以訂閱系統(tǒng)管理員或者維 護人員定義的取數(shù)，并設(shè)置自己的訂閱參數(shù)值、訂閱頻率、數(shù)據(jù)再加工條件、通知方式、通知 內(nèi)容和接收人。基于訂閱的預(yù)警方法在執(zhí)行時會收集訂閱者參數(shù)值生成取數(shù)計劃，如果用戶的訂 閱頻率不在此次數(shù)據(jù)檢測頻率中，則此訂閱在此輪預(yù)警中將不予執(zhí)行。基于訂閱的預(yù)警方法支持訂閱者獲取到預(yù)警數(shù)據(jù)之后進行再加工處理的功能。


圖1是預(yù)警定義時關(guān)系圖；圖2是預(yù)警定義時流程圖；圖3是預(yù)警執(zhí)行流程圖。
具體實施例方式參照說明書附圖對本發(fā)明的方法作以下詳細地說明。以下將通過對本發(fā)明的優(yōu)選實施例的詳細描述，使本發(fā)明的上述目標、特征和優(yōu) 點更加清晰、易懂。為了更容易理解本方法的實施方式，以示例進行詳細的說明。實施例場景在一個軟件產(chǎn)品的測試過程中，測試人員會針對開發(fā)人員提供的產(chǎn)品進行 測試，并把測試發(fā)現(xiàn)的問題(以下簡稱Bug)登記到一個產(chǎn)品測試問題系統(tǒng)中(以下簡稱測試系統(tǒng))。問題的處理流程為測試人員登記問題、開發(fā)人員查看問題并修改、開發(fā)人員驗 證并關(guān)閉問題三個步驟。三個步驟的處理方式如下步驟一測試人員會針對測試出的每個Bug在測試系統(tǒng)中登記一個問題，并且指 定bug的狀態(tài)為新登記狀態(tài)(以下簡稱New)，登記時間為當(dāng)前時間。步驟二 開發(fā)人員在查看問題時需要把問題的狀態(tài)修改為開發(fā)人員正在處理狀態(tài) (以下簡稱Open)，并設(shè)置此問題的計劃修復(fù)時間。步驟三開發(fā)人員把bug處理完成之后，修改把測試系統(tǒng)中對于的bug的狀態(tài)修改 為處理完成狀態(tài)(以下簡稱Fixed)。基本的數(shù)據(jù)結(jié)構(gòu)如下 測試系統(tǒng)中存在數(shù)據(jù)如下 在測試人員把Bug登記到測試系統(tǒng)系統(tǒng)之后，為了提醒開發(fā)人員及時的響應(yīng)bug 的處理，需要新建一個預(yù)警，下面是預(yù)警的定義和訂閱步驟；>步驟一定義預(yù)警，預(yù)警定義的結(jié)果如下■預(yù)警名稱新登記的Bug預(yù)警
■預(yù)警頻率每天上午8點至下午5點，每一小時預(yù)警一次■數(shù)據(jù)檢測取數(shù) SQL 為Select ID, Name, Description, CreateDate, CreaterFrom Bugs Where State = iNew' and Developer = ‘{Paramter1}’。 其 中’ {Paramterl}’是一個訂閱參數(shù)，需要訂閱者在訂閱時賦值?！鼋Y(jié)果集數(shù)據(jù)結(jié)構(gòu)定義 >步驟二 預(yù)警定義完成之后，需要開發(fā)人員訂閱此預(yù)警，用戶“張二”訂閱(以下 簡稱張二訂閱)的內(nèi)容如下■訂閱參數(shù)賦值張二■訂閱頻率只訂閱上午8點的預(yù)警■數(shù)據(jù)再加工條件不定義過濾條件。■通知定義標題待處理的Bug預(yù)警；接受方式郵件；接收人zhangerigmai 1. com內(nèi)容編號名稱描述登記人登記時間{ID} {Name} {Des} {Creater} {CreateDate}其中{ID}、{Name}、{Des}、{Creater}、{CreateDate}是參數(shù)，分別對應(yīng)結(jié)果集中 的 ID、Name、Description、Creater、CreateDate 列的值。>步驟三用戶“張三”訂閱的內(nèi)容(以下簡稱張三訂閱)如下■訂閱參數(shù)賦值張三■訂閱頻率與數(shù)據(jù)檢測的頻率一致。■數(shù)據(jù)再加工條件不定義過濾條件?！鐾ㄖx標題待處理的Bug預(yù)警；接受方式短信；接收人1390531XXXX內(nèi)容編號名稱描述登記人登記時間{ID} {Name} {Des} {Creater} {CreateDate}其中{ID}、{Name}、{Des}、{Creater}、{CreateDate}是參數(shù)，分別對應(yīng)結(jié)果集中 的 ID、Name、Description、Creater、CreateDate 列的值。
預(yù)警定義完成之后，在滿足數(shù)據(jù)檢測頻率的條件下，預(yù)警開始執(zhí)行。假設(shè)當(dāng)前時間 是上午8點，執(zhí)行的步驟如下>步驟一名稱為“新登記的Bug預(yù)警”的預(yù)警開始執(zhí)行。>步驟二 生成取數(shù)計劃“新登記的Bug預(yù)警”在執(zhí)行時，首先獲取到張二和張三 的訂閱信息，由于張二只訂閱了上午8點的預(yù)警，正好滿足本次預(yù)警的頻率，所以張二的訂 閱是有效的。由于張三訂閱全部預(yù)警，所有張三的預(yù)警也是有效的，則有效訂閱列表為張 二訂閱、張三訂閱。由于張二訂閱的訂閱參數(shù)值為“張二”，張三訂閱的訂閱參數(shù)值為“張 三”，兩個訂閱參數(shù)值不一致，無法合并為一次取數(shù)，所以生成的取數(shù)計劃為計劃一張二訂閱訂閱參數(shù)值張二計劃二 張三訂閱訂閱參數(shù)值張三>步驟三取數(shù)。取數(shù)計劃生成之后，開始執(zhí)行計劃。V根據(jù)計劃一的訂閱參數(shù)值形成的取數(shù)SQL為V Select ID,Name,Description,CreateDate,Creater From Bugs WhereState =‘New’ and Developer = ‘張二’，此取數(shù)SQL獲取到的數(shù)據(jù)集為 V根據(jù)計劃二的訂閱參數(shù)值形成的取數(shù)SQL為V Select ID, Name,Description, CreateDate, Creater From Bugs WhereState =‘New，and Developer = ‘張三，，此取數(shù)SQL獲取到的數(shù)據(jù)集為空。>步驟四數(shù)據(jù)存儲。取數(shù)計劃執(zhí)行完成之后，把取數(shù)結(jié)果集與取數(shù)計劃進行存 儲，為訂閱的分發(fā)提供預(yù)警數(shù)據(jù)。>步驟五分發(fā)訂閱。訂閱的分發(fā)按照預(yù)警執(zhí)行時生成的取數(shù)計劃進行。V計劃一由于計劃一中只有一個張二訂閱，所以只啟動一個訂閱的分發(fā)流程即可?！鰯?shù)據(jù)再次加工由于張二訂閱對數(shù)據(jù)再次加工沒有設(shè)置過濾條件，所以計劃一 的取數(shù)結(jié)果集就是張二訂閱最終的預(yù)警數(shù)據(jù)。■生成通知并發(fā)送根據(jù)張二訂閱定義的通知模板生成的通知內(nèi)容如下。并按照 生成的通知內(nèi)容發(fā)送郵件。標題待處理的Bug預(yù)警；接受方式郵件；接收人zhanger@gmai 1. com內(nèi)容 V計劃二由于計劃二的取數(shù)結(jié)果集為空，所以不進行訂閱的分發(fā)。通過此示例可以發(fā)現(xiàn)，基于訂閱的預(yù)警方法實現(xiàn)了數(shù)據(jù)檢測與通知的分離，系統(tǒng)管理員或者維護人員定義數(shù)據(jù)檢測的條件、條件參數(shù)和頻率，即數(shù)據(jù)檢測定義，普通用戶可 以訂閱系統(tǒng)管理員或者維護人員定義的取數(shù)，并設(shè)置自己的條件參數(shù)值、訂閱頻率、數(shù)據(jù)再 加工條件、通知方式、通知內(nèi)容和接收人通知。數(shù)據(jù)檢測與通知分離之后，接受用戶變成參 與者，用戶可以在訂閱中定義自己喜好的通知方式、通知內(nèi)容和通知頻率。數(shù)據(jù)檢測頻率和 訂閱頻率可以不一致，滿足了不同用戶對數(shù)據(jù)及時性和頻度不同需求的支持，同一個預(yù)警 可以在不同的時間以不同的通知方式告知。此外，基于訂閱的預(yù)警方法降低了系統(tǒng)管理員 或者維護人員的維護成本。
權(quán)利要求
一種基于訂閱的數(shù)據(jù)預(yù)警方法，其特征在于，步驟如下1)基于訂閱的預(yù)警方法實現(xiàn)數(shù)據(jù)檢測與數(shù)據(jù)處理的分離，系統(tǒng)管理員或者維護人員定義數(shù)據(jù)檢測的條件及執(zhí)行頻率，普通用戶訂閱此定義，并設(shè)置自己通知方式、通知內(nèi)容和訂閱頻率；2)數(shù)據(jù)檢測與處理分離之后，接收用戶變成參與者，用戶在訂閱中定義自己喜好的通知方式、通知內(nèi)容和訂閱頻率，允許數(shù)據(jù)檢測頻率和訂閱頻率不一致，以滿足不同用戶對數(shù)據(jù)及時性和頻度不同需求的支持，同一個預(yù)警在不同的時間以不同的通知方式告知，包括周末有人要求不接受通知，出差時間不接受通知；3)基于訂閱的數(shù)據(jù)預(yù)警方法有定義時和運行時兩階段構(gòu)成，定義時有數(shù)據(jù)檢測定義、訂閱定義兩個部分實現(xiàn)，運行時有生成取數(shù)計劃、執(zhí)行取數(shù)、存儲取數(shù)數(shù)據(jù)、分發(fā)訂閱四部分組成，其中(1)定義時，主要完成對預(yù)警的定義，定義時主要分為數(shù)據(jù)檢測定義和訂閱定義，它們的關(guān)系是一對多的關(guān)系；a)數(shù)據(jù)檢測定義的主要步驟有步驟一數(shù)據(jù)檢測頻率定義定義預(yù)警檢測的頻率和開始、結(jié)束時間；步驟二數(shù)據(jù)檢測定義，數(shù)據(jù)檢測定義有預(yù)警條件定義和數(shù)據(jù)結(jié)果結(jié)構(gòu)定義兩部分組成；步驟三訂閱參數(shù)定義。定義數(shù)據(jù)檢測定義中被訂閱者賦值的參數(shù)；步驟二中提到的預(yù)警條件定義是定義預(yù)警的數(shù)據(jù)源和在數(shù)據(jù)源上的過濾條件，過濾條件的值設(shè)置為訂閱參數(shù)，由訂閱用戶在訂閱時賦值；步驟二中提到的數(shù)據(jù)結(jié)果結(jié)構(gòu)定義是定義預(yù)警結(jié)果集的數(shù)據(jù)結(jié)構(gòu)，訂閱用戶使用此數(shù)據(jù)結(jié)構(gòu)訪問訂閱到的數(shù)據(jù)，并組織通知內(nèi)容；預(yù)警執(zhí)行時會根據(jù)訂閱參數(shù)的賦值情況生成取數(shù)計劃并執(zhí)行預(yù)警；b)訂閱定義的主要步驟有步驟一訂閱參數(shù)賦值，定義訂閱者關(guān)心的預(yù)警過濾條件的實際值；步驟二訂閱頻率定義，定義訂閱的接收頻率；步驟三數(shù)據(jù)再加工條件定義，在取數(shù)計劃提取的數(shù)據(jù)基礎(chǔ)上再進行條件過濾，此次過濾之后的數(shù)據(jù)是真正預(yù)警的數(shù)據(jù)；步驟四訂閱定義，定義通知方式定義、通知內(nèi)容定義和接收人定義；步驟二中的訂閱頻率需要從數(shù)據(jù)檢測頻率中選取，不能是數(shù)據(jù)檢測頻率之外的時間；步驟二中訂閱頻率是指定有效期，包括只能在工作日和工作時間內(nèi)訂閱預(yù)警； 步驟四中的通知方式定義主要選擇系統(tǒng)支持的通知方式，包括郵件方式、短信方式；步驟四中的通知內(nèi)容是定義通知的格式和參數(shù)，在發(fā)送通知時，系統(tǒng)會把參數(shù)替換為預(yù)警數(shù)據(jù)，形成通知并發(fā)送；(2)運行時運行時主要有生成取數(shù)計劃、取數(shù)、數(shù)據(jù)存儲、分發(fā)訂閱四部分組成，分發(fā)訂閱又有訂閱用戶數(shù)據(jù)再加工、生成通知、發(fā)送通知三部分組成，運行時按照流程的具體執(zhí)行步驟如下步驟一生成取數(shù)計劃，由于訂閱頻率與數(shù)據(jù)檢測頻率的不同，與數(shù)據(jù)檢測定義對應(yīng)的所有訂閱并不都需要執(zhí)行；在訂閱參數(shù)可能存在相同的情況下，為了過濾有效訂閱者并提高預(yù)警執(zhí)行的效率，在預(yù)警執(zhí)行時需要首先生成取數(shù)計劃，取數(shù)計劃的內(nèi)容包括取數(shù)條件、訂閱參數(shù)值和訂閱列表；步驟二取數(shù)，生成取數(shù)計劃之后，系統(tǒng)會對取數(shù)計劃中的任務(wù)逐一執(zhí)行；步驟三數(shù)據(jù)存儲，取數(shù)完成之后，系統(tǒng)會把結(jié)果集，以及結(jié)果集與訂閱列表進行存儲；步驟四分發(fā)訂閱，按照取數(shù)計劃中記錄的訂閱列表發(fā)布訂閱信息，分發(fā)訂閱有數(shù)據(jù)再加工、生成通知、發(fā)送通知組成；步驟一中的過濾有效訂閱者的規(guī)則為訂閱頻率中存在與當(dāng)前預(yù)警執(zhí)行的時間點相同的時間，并且當(dāng)前預(yù)警時間點滿足訂閱者對訂閱有效期的限制，則認為此訂閱是本次預(yù)警的有效訂閱；步驟一中過濾出有效訂閱者之后，系統(tǒng)根據(jù)每個訂閱者的訂閱參數(shù)賦值情況生成取數(shù)計劃，生成取數(shù)計劃的規(guī)則為一個訂閱者的訂閱參數(shù)與其他訂閱者的訂閱參數(shù)的賦值情況完全相同，則認為這些訂閱合并為一次取數(shù)，并生成一個計劃，此計劃與這些訂閱關(guān)聯(lián)；步驟四中的數(shù)據(jù)再加工是指在數(shù)據(jù)存儲完畢之后，系統(tǒng)會針對每個訂閱觸發(fā)一個流程，此流程根據(jù)數(shù)據(jù)與訂閱的對照關(guān)系逐個觸發(fā)預(yù)警的訂閱，在訂閱中，首先根據(jù)訂閱者設(shè)置的數(shù)據(jù)再加工條件對數(shù)據(jù)進行再次過濾，過濾之后的數(shù)據(jù)是預(yù)警的數(shù)據(jù)；步驟四中的生成通知是把通知內(nèi)容中的參數(shù)替換為預(yù)警的數(shù)據(jù)，并生成郵件或者短信可接收的數(shù)據(jù)格式；步驟四中的發(fā)送通知是根據(jù)通知方式調(diào)用不同消息發(fā)送程序執(zhí)行消息的發(fā)送；基于訂閱的數(shù)據(jù)預(yù)警方法雖然實現(xiàn)了取數(shù)與通知的分離，但也支持現(xiàn)有的預(yù)警方式。FSA00000054640300011.tif,FSA00000054640300012.tif,FSA00000054640300013.tif,FSA00000054640300014.tif,FSA00000054640300015.tif,FSA00000054640300016.tif,FSA00000054640300017.tif,FSA00000054640300021.tif,FSA00000054640300022.tif,FSA00000054640300023.tif,FSA00000054640300024.tif
全文摘要
本發(fā)明提供一種基于訂閱的數(shù)據(jù)預(yù)警方法，是基于訂閱的預(yù)警方法實現(xiàn)了數(shù)據(jù)檢測與數(shù)據(jù)處理的分離，系統(tǒng)管理員或者維護人員定義數(shù)據(jù)檢測的條件及執(zhí)行頻率。普通用戶可以訂閱此定義，并設(shè)置自己通知方式、通知內(nèi)容和訂閱頻率。數(shù)據(jù)檢測與處理分離之后，接收用戶變成參與者，用戶可以在訂閱中定義自己喜好的通知方式、通知內(nèi)容和訂閱頻率。數(shù)據(jù)檢測頻率和訂閱頻率可以不一致，滿足了不同用戶對數(shù)據(jù)及時性和頻度不同需求的支持，同一個預(yù)警可以在不同的時間以不同的通知方式告知。比如周末有人要求不接受通知，出差時間不接受通知等等。
文檔編號G06F11/36GK101882093SQ20101012402
公開日2010年11月10日 申請日期2010年3月15日 優(yōu)先權(quán)日2010年3月15日
發(fā)明者張在峰, 鄭偉波, 陳磊, 魏亮 申請人:浪潮集團山東通用軟件有限公司