專利名稱：業(yè)務(wù)跟蹤方法及跟蹤代理、跟蹤控制服務(wù)器和跟蹤系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通訊技術(shù)領(lǐng)域，具體涉及一種業(yè)務(wù)跟蹤方法以及相應(yīng)的跟蹤代 理、跟蹤控制服務(wù)器和跟蹤系統(tǒng)。
背景技術(shù)：
隨著通信行業(yè)的不斷發(fā)展，竟?fàn)幦遮吋ち?，為了提高用戶的滿意度，需要 能夠快速解決用戶關(guān)于業(yè)務(wù)/應(yīng)用故障的投訴，對業(yè)務(wù)流進行跟蹤是進行故障
分析和定位的有效手段。開放移動聯(lián)盟(OMA: Open Mobile Alliance)提出 的管理和維護業(yè)務(wù)生命周期及負責(zé)業(yè)務(wù)跟蹤的系統(tǒng)(OSPE: OMA Service Provider Environment)中與業(yè)務(wù)跟蹤相關(guān)的部分包括三個模塊跟蹤控制服務(wù) 器(OSPE服務(wù)器)、跟蹤代理以及負責(zé)存儲和維護業(yè)務(wù)目錄及模型的業(yè)務(wù)數(shù) 據(jù)庫(SMAC: Service Model And Catalogue )。常見的業(yè)務(wù)跟蹤方式可分為兩 類
一、 普通跟蹤方式。
如圖1所示。該方式的主要流程為OSPE服務(wù)器控制各個被跟蹤組件上 的跟蹤代理打開跟蹤；OSPE服務(wù)器下發(fā)跟蹤任務(wù)給各個跟蹤代理；跟蹤代理 跟蹤指定的業(yè)務(wù)，并進行相應(yīng)的跟蹤處理，包括監(jiān)測業(yè)務(wù)執(zhí)行情況，生成跟蹤 日志等；跟蹤代理上報跟蹤日志給OSPE服務(wù)器；OSPE服務(wù)器控制被跟蹤組 件上的跟蹤代理關(guān)閉跟蹤。
二、 下發(fā)S艮蹤令片皁(SLT Token: Service Level Tracing Token ) 3艮蹤的方式。 如圖2所示。該方式的主要流程為OSPE服務(wù)器控制各個被跟蹤組件上
的跟蹤代理打開跟蹤；OSPE服務(wù)器下發(fā)SLT Token給首個被跟蹤代理；SLT Token隨被跟蹤的業(yè)務(wù)按照業(yè)務(wù)在各個組件的執(zhí)行順序傳遞于各個跟蹤代理 中；跟蹤代理判斷Token是否為所需要跟蹤的SLT Token, —般可根據(jù)Token 所攜帶的跟蹤標記來進行判斷；跟蹤代理進行相應(yīng)的跟蹤處理，包括監(jiān)測業(yè)務(wù) 執(zhí)行情況，生成跟蹤日志等；跟蹤代理上報跟蹤日志給OSPE服務(wù)器；OSPE 服務(wù)器控制被跟蹤組件上的跟蹤代理關(guān)閉跟蹤。
在上述兩種跟蹤方式中通常所采用的關(guān)閉跟蹤流程為OSPE請求者向 OSPE服務(wù)器發(fā)送關(guān)閉業(yè)務(wù)跟蹤消息；OSPE服務(wù)器收到該關(guān)閉業(yè)務(wù)跟蹤消息 后向SMAC查詢業(yè)務(wù)目錄，然后根據(jù)SMAC返回的查詢結(jié)果分別關(guān)閉各個跟 蹤代理，并將跟蹤日志發(fā)送給OSPE請求者。
這種關(guān)閉跟蹤處理方式需要基于OSPE請求者發(fā)出關(guān)閉跟蹤請求，其缺陷 在于，OSPE請求者往往難以準確判斷下發(fā)關(guān)閉請求的適當(dāng)時機。從OSPE請 求者發(fā)送打開跟蹤請求，令OSPE服務(wù)器開始跟蹤，到OSPE請求者發(fā)送關(guān)閉 跟蹤請求，令OSPE服務(wù)器關(guān)閉跟蹤的這段時期內(nèi)被跟蹤業(yè)務(wù)可能已經(jīng)交互 了多次，產(chǎn)生并上報了大量的跟蹤數(shù)據(jù)，這會給OSPE請求者正確分析定位業(yè) 務(wù)錯誤帶來很大的困難；然而也有可能被跟蹤業(yè)務(wù)一次交互都沒有完成，上報 了無用的跟蹤日志，這同樣不利于錯誤的分析及定位。
為應(yīng)對上述缺陷，也有提出一種用于普通跟蹤的定時關(guān)閉方法，如圖3 所示，其特點在于在OSPE服務(wù)器端增加一個定時單元來進行定時，當(dāng)時間 到達時自動關(guān)閉跟蹤。這種方法雖然不再需要OSPE請求者來發(fā)起關(guān)閉跟蹤， 但與前面的關(guān)閉跟蹤處理方式相比沒有實質(zhì)性的差別，只是將OSPE請求者的 即時人為控制變成了預(yù)先設(shè)置的定時控制，同樣無法從根本上避免跟蹤過度或 跟蹤不足情況的出現(xiàn)，浪費系統(tǒng)資源。

發(fā)明內(nèi)容
本發(fā)明的目的在于提供一種能夠有效控制跟蹤范圍，實現(xiàn)精確跟蹤的業(yè)務(wù) 跟蹤方法以及相應(yīng)的跟蹤代理、跟蹤控制服務(wù)器和跟蹤系統(tǒng)。
為達到本發(fā)明的目的，所采取的技術(shù)方案是 一種業(yè)務(wù)跟蹤方法，包括 跟蹤控制服務(wù)器向跟蹤代理下發(fā)跟蹤令牌，所述跟蹤令牌中設(shè)置有關(guān)閉跟蹤條 件；獲得跟蹤令牌的跟蹤代理判斷所述關(guān)閉跟蹤條件是否達成，若達成則主動 發(fā)起跟蹤關(guān)閉，若未達成則繼續(xù)執(zhí)行業(yè)務(wù)跟蹤流程。
獲得跟蹤令牌的跟蹤代理可采用這樣的執(zhí)行步驟或者先執(zhí)行本代理的跟 蹤處理，再判斷所述關(guān)閉跟蹤條件是否達成，若未達成則將所述跟蹤令牌傳遞 給下一個跟蹤代理；或者先判斷所述關(guān)閉跟蹤條件是否達成，若未達成則執(zhí)行 本代理的3艮蹤處理，并將所述3艮蹤令牌傳遞纟會下一個S艮蹤^理。
所述關(guān)閉跟蹤條件可以由跟蹤請求者生成，通過業(yè)務(wù)跟蹤請求發(fā)送給跟蹤
控制服務(wù)器，由跟蹤控制服務(wù)器設(shè)置在跟蹤令牌中；或者，也可以由跟蹤控制 服務(wù)器生成，并設(shè)置在跟蹤令牌中。
所述跟蹤令牌中還設(shè)置有跟蹤代理標識；所述跟蹤代理標識可以由跟蹤請 求者指定，通過業(yè)務(wù)跟蹤請求發(fā)送給跟蹤控制服務(wù)器，由跟蹤控制服務(wù)器設(shè)置 在跟蹤令牌中；或者，也可以由跟蹤控制服務(wù)器生成，并設(shè)置在跟蹤令牌中。
跟蹤代理獲得跟蹤令牌后，還可以先判斷是否為需要執(zhí)行跟蹤任務(wù)的跟蹤 令牌，若是則上報跟蹤日志，并判斷所述關(guān)閉跟蹤條件是否達成；若否則將所 述跟蹤令牌傳遞給下一個跟蹤代理。
優(yōu)選的是，所述跟蹤代理主動發(fā)起跟蹤關(guān)閉包括向所述跟蹤控制服務(wù)器 發(fā)送關(guān)閉業(yè)務(wù)跟蹤消息，跟蹤控制服務(wù)器即執(zhí)行關(guān)閉業(yè)務(wù)跟蹤流程；或者，先 關(guān)閉本代理的跟蹤再向所述跟蹤控制服務(wù)器發(fā)送通知消息，由跟蹤控制服務(wù)器 執(zhí)行其它跟蹤代理的關(guān)閉業(yè)務(wù)跟蹤流程。
所述跟蹤控制服務(wù)器執(zhí)行關(guān)閉業(yè)務(wù)跟蹤流程可包括跟蹤控制服務(wù)器查詢 業(yè)務(wù)目錄；跟蹤控制服務(wù)器根據(jù)查詢結(jié)果向相應(yīng)跟蹤代理下發(fā)關(guān)閉跟蹤命令； 跟蹤控制服務(wù)器判斷各個跟蹤代理都正確反饋后，將跟蹤結(jié)果發(fā)送給跟蹤請求 者。
本發(fā)明還提供一種跟蹤代理，包括跟蹤處理模塊、跟蹤關(guān)閉發(fā)起模塊；所 述跟蹤處理模塊接收跟蹤令牌，判斷當(dāng)前傳送的跟蹤令牌是否為需要執(zhí)行跟蹤 任務(wù)的令牌，根據(jù)判斷結(jié)果或者繼續(xù)傳遞跟蹤令牌，或者執(zhí)行跟蹤處理并向所 述跟蹤關(guān)閉發(fā)起才莫塊轉(zhuǎn)發(fā)跟蹤令牌；所述跟蹤關(guān)閉發(fā)起模塊接收所述跟蹤處理 模塊轉(zhuǎn)發(fā)的跟蹤令牌，判斷所述跟蹤令牌中設(shè)置的關(guān)閉跟蹤條件是否達成，根 據(jù)判斷結(jié)果確定是否發(fā)起跟蹤關(guān)閉。
優(yōu)選的是，所述跟蹤關(guān)閉發(fā)起模塊確定發(fā)起跟蹤關(guān)閉時，還向所述跟蹤處 理模塊發(fā)送關(guān)閉命令。
本發(fā)明并提供一種跟蹤控制服務(wù)器，包括跟蹤代理控制模塊和跟蹤令牌生 成模塊；所述跟蹤代理控制模塊將跟蹤任務(wù)信息通知到所述跟蹤令牌生成模 塊，產(chǎn)生并下發(fā)打開跟蹤命令和關(guān)閉跟蹤命令；所述跟蹤令牌生成模塊包括跟
蹤令牌處理模塊，所述跟蹤令牌處理模塊根據(jù)所述跟蹤任務(wù)信息產(chǎn)生跟蹤令
牌；所述跟蹤令牌生成模塊還包括關(guān)閉條件添加模塊，所述關(guān)閉條件添加模塊 在所述跟蹤令牌處理模塊產(chǎn)生的跟蹤令牌中設(shè)置關(guān)閉跟蹤條件。
本發(fā)明同時提供一種跟蹤系統(tǒng)，包括跟蹤控制服務(wù)器和跟蹤代理，所述跟 蹤控制服務(wù)器控制跟蹤代理的打開跟蹤或關(guān)閉跟蹤，生成并向跟蹤代理下發(fā)跟 蹤令牌，接收跟蹤代理上報的跟蹤日志；所述跟蹤代理接收并傳遞跟蹤令牌， 根據(jù)跟蹤令牌執(zhí)行跟蹤處理；所述跟蹤控制服務(wù)器還在下發(fā)的跟蹤令牌中設(shè)置 關(guān)閉跟蹤條件，接收跟蹤代理發(fā)送的關(guān)閉業(yè)務(wù)跟蹤消息，并根據(jù)所述關(guān)閉業(yè)務(wù) 跟蹤消息控制跟蹤代理的關(guān)閉；所述跟蹤代理還判斷所述跟蹤令牌中設(shè)置的關(guān) 閉跟蹤條件是否達成，根據(jù)判斷結(jié)果確定是否向所述跟蹤控制服務(wù)器發(fā)送關(guān)閉 業(yè)務(wù)跟蹤消息。
上述跟蹤系統(tǒng)還可包括業(yè)務(wù)數(shù)據(jù)庫；所述跟蹤控制服務(wù)器向所述業(yè)務(wù)數(shù)據(jù) 庫發(fā)送查詢命令，進行業(yè)務(wù)目錄查詢，根據(jù)查詢結(jié)果控制跟蹤令牌的生成以及 相應(yīng)跟蹤代理的打開跟蹤或關(guān)閉跟蹤；所述業(yè)務(wù)數(shù)據(jù)庫將被查詢信息發(fā)送給所 述跟蹤控制服務(wù)器。
采用上述技術(shù)方案，本發(fā)明有益的技術(shù)效果在于本發(fā)明采用在跟蹤令牌 中設(shè)置關(guān)閉跟蹤條件，由跟蹤代理在關(guān)閉跟蹤條件達成時主動發(fā)起跟蹤關(guān)閉的 方法，由于跟蹤令牌隨同被跟蹤的業(yè)務(wù)流一同傳送，因此能夠精確的控制跟蹤 范圍，根據(jù)跟蹤任務(wù)的需要有效獲取有價值的跟蹤結(jié)果，解決了無法確定適當(dāng) 跟蹤關(guān)閉時機的困難，避免了系統(tǒng)資源的浪費。


下面通過具體實施方式
并結(jié)合附圖對本發(fā)明作進一步的詳細說明。
圖l是現(xiàn)有技術(shù)的一種普通跟蹤方式示意圖2是現(xiàn)有技術(shù)的基于Token的跟蹤方式示意圖3是現(xiàn)有技術(shù)的采用定時關(guān)閉的普通跟蹤方式示意圖4是本發(fā)明實施例一業(yè)務(wù)跟蹤方法流程示意圖5是實施例一中打開跟蹤下發(fā)Token的信令流程示意圖6是實施例一中跟蹤代理進行跟蹤業(yè)務(wù)處理的信令流程示意圖7是實施例一中OSPE服務(wù)器關(guān)閉業(yè)務(wù)跟蹤的信令流程示意圖； 圖8是應(yīng)用例一中打開跟蹤下發(fā)Token的信令流程示意圖； 圖9是應(yīng)用例一中跟蹤代理進行跟蹤業(yè)務(wù)處理的信令流程示意圖； 圖IO是應(yīng)用例一中OSPE服務(wù)器關(guān)閉業(yè)務(wù)跟蹤的信令流程示意圖； 圖11是應(yīng)用例二業(yè)務(wù)跟蹤流程示意圖； 圖12是本發(fā)明實施例二業(yè)務(wù)跟蹤方法流程示意圖； 圖13是本發(fā)明實施例三跟蹤代理模塊結(jié)構(gòu)示意圖； 圖14是本發(fā)明實施例四0SPE服務(wù)器模塊結(jié)構(gòu)示意圖； 圖15是本發(fā)明實施例五OSPE系統(tǒng)模塊結(jié)構(gòu)示意圖； 圖16是實施例五OSPE系統(tǒng)采用實施例三、四設(shè)備的示意圖； 圖17是實施例五OSPE系統(tǒng)混合組網(wǎng)示意圖； 圖18是實施例六OSPE系統(tǒng)模塊結(jié)構(gòu)示意圖。
具體實施例方式
本發(fā)明提供了 一種業(yè)務(wù)跟蹤方法，其核心思想是，擴展SLTToken的內(nèi)容， 在其中添加關(guān)閉跟蹤條件，由跟蹤代理在對SLTToken的處理過程中根據(jù)關(guān)閉 跟蹤條件是否達成來確定是否主動發(fā)起跟蹤關(guān)閉。觸發(fā)關(guān)閉業(yè)務(wù)跟蹤的關(guān)閉跟 蹤條件可以由OSPE請求者生成，也可以由OSPE服務(wù)器生成。跟蹤代理在確 定需要發(fā)起業(yè)務(wù)跟蹤關(guān)閉時，可以直接發(fā)送關(guān)閉請求給OSPE服務(wù)器，也可以 先自行跟蹤關(guān)閉然后再通知OSPE服務(wù)器，由OSPE服務(wù)器進行其他跟蹤代理 的關(guān)閉。本發(fā)明還提供應(yīng)用于上述跟蹤方法的跟蹤設(shè)備和系統(tǒng)。以下分別對本 發(fā)明方法、設(shè)備和系統(tǒng)進行詳細說明。
實施例一、 一種業(yè)務(wù)跟蹤方法，流程如圖4所示，包括
Al、 OSPE服務(wù)器向跟蹤代理下發(fā)SLT Token, Token中設(shè)置有關(guān)閉跟蹤
條件；
當(dāng)OSPE服務(wù)器收到OSPE請求者的業(yè)務(wù)跟蹤請求時， 一次業(yè)務(wù)跟蹤流程 就開始了， OSPE服務(wù)器需要執(zhí)行打開跟蹤，下發(fā)SLTToken等操作。
通常的SLT Token是用來存放跟蹤標識、跟蹤條件等信息的數(shù)據(jù)塊，由 OSPE服務(wù)器下發(fā)到被跟蹤組件上的跟蹤代理，并且隨著被跟蹤的業(yè)務(wù)流在各
個跟蹤代理間傳送，直到關(guān)閉業(yè)務(wù)跟蹤。本發(fā)明中擴展了 SLTToken,進行了 關(guān)閉跟蹤條件的設(shè)置。關(guān)閉跟蹤條件可以由OSPE請求者生成，通過業(yè)務(wù)跟蹤 請求發(fā)送給OSPE服務(wù)器；也可以由OSPE服務(wù)器生成；當(dāng)然，對于一些可能 在實際中經(jīng)常被應(yīng)用的關(guān)閉跟蹤條件，也可以制定出生成模板或選擇類，以便 于使用。
按照通常OSPE系統(tǒng)的架構(gòu)，業(yè)務(wù)模型以及與之相關(guān)的組件的數(shù)據(jù)集中由 SMAC進行存儲和維護，因此OSPE服務(wù)器在執(zhí)行業(yè)務(wù)跟蹤相關(guān)操作時，需要 先到SMAC進行業(yè)務(wù)目錄的查詢，獲得與被跟蹤業(yè)務(wù)相關(guān)聯(lián)組件的描述，以 便執(zhí)行對相應(yīng)組件的跟蹤代理的打開跟蹤或關(guān)閉跟蹤控制；
本實施例采用的打開跟蹤下發(fā)SLTToken的信令流程如圖5所示，包括
al、 OSPE請求者向OSPE服務(wù)器發(fā)送業(yè)務(wù)跟蹤請求；該請求中通常包含 需要打開跟蹤的業(yè)務(wù)以及相關(guān)的跟蹤任務(wù)，還可包括關(guān)閉跟蹤條件以及指定的 跟蹤組件或跟蹤代理標識(ID );
a2、 OSPE服務(wù)器根據(jù)業(yè)務(wù)跟蹤請求中的信息查詢SMAC業(yè)務(wù)目錄；本文 中所稱業(yè)務(wù)目錄指存儲了業(yè)務(wù)與組件(組件上有跟蹤代理)之間的依賴關(guān)系的 部件；
a3、 SMAC返回查詢結(jié)果給OSPE服務(wù)器；查詢結(jié)果包括所需跟蹤業(yè)務(wù)的 依賴組件信息等；
a4、 OSPE服務(wù)器4艮據(jù)查詢結(jié)果向相應(yīng)各個跟蹤組件上的跟蹤代理發(fā)送打 開跟蹤命令，通知跟蹤代理需要跟蹤的業(yè)務(wù)和跟蹤任務(wù)；
a5、各個跟蹤代理打開被跟蹤組件上的跟蹤功能，下發(fā)跟蹤任務(wù)，并向 OSPE服務(wù)器反饋打開結(jié)果；圖5中各代理均反饋打開成功；
a6、 OSPE服務(wù)器根據(jù)跟蹤請求中指定的首個跟蹤組件或者SMAC中指定 的首個跟蹤組件(以跟蹤請求中指定的為優(yōu)先)，向該組件的跟蹤代理下發(fā)SLT Token; SLTToken中設(shè)置有由OSPE請求者生成的關(guān)閉跟蹤條件，若業(yè)務(wù)跟蹤 請求中未包含關(guān)閉跟蹤條件，也可由OSPE服務(wù)器根據(jù)跟蹤任務(wù)生成相應(yīng)的關(guān) 閉跟蹤條件添加到SLTToken中；
a7、首個跟蹤代理反饋下發(fā)結(jié)果；圖5中首個跟蹤代理反饋SLTToken下
發(fā)成功。
A2、 SLTToken下發(fā)后，隨同業(yè)務(wù)流在跟蹤代理之間傳遞，跟蹤代理的處 理步驟包括
A21 、獲得SLT Token的跟蹤代理執(zhí)行相應(yīng)的跟蹤處理；通常跟蹤代理在 收到一個SLT Token后需要先根據(jù)Token所包含的跟蹤標識等信息判斷是否為 需要跟蹤的業(yè)務(wù)，確認后，執(zhí)行相應(yīng)的跟蹤處理，可以是上報被跟蹤組件的跟 蹤日志、將當(dāng)前跟蹤代理信息寫入Token等操作；
A22 、跟蹤代理判斷SLT Token所攜帶的關(guān)閉跟蹤條件是否達成，若是則 執(zhí)行A23 ，若否則轉(zhuǎn)到A24;
A23、跟蹤代理向OSPE服務(wù)器發(fā)送關(guān)閉業(yè)務(wù)跟蹤消息，由OSPE服務(wù)器 來執(zhí)行后續(xù)的關(guān)閉業(yè)務(wù)跟蹤操作A3;
A24、跟蹤代理將SLT Token傳遞給下一個跟蹤代理，由下一個跟蹤代理 重復(fù)上述處理過程；
需要說明的是，若某個跟蹤代理不具備對關(guān)閉跟蹤條件的判斷能力，則在 收到Token后僅按照常規(guī)方式執(zhí)行跟蹤任務(wù)的判斷和處理，在后續(xù)的Token傳 遞過程中將由具有能力的跟蹤代理對關(guān)閉跟蹤條件進行判斷和處理，因此，本 發(fā)明方法的實現(xiàn)并不要求所有的跟蹤代理都具備主動發(fā)起跟蹤關(guān)閉的能力，應(yīng) 用系統(tǒng)中的跟蹤代理可以具有混合的形態(tài)；
上述跟蹤代理進行跟蹤業(yè)務(wù)處理的信令流程如圖6所示，包括
bl、來自于終端的指定被跟蹤業(yè)務(wù)到達某個被跟蹤組件，隨同業(yè)務(wù)流傳送 的SLT Token到達該組件的跟蹤代理；
b2、跟蹤代理判斷該業(yè)務(wù)是否需要被跟蹤；圖6中跟蹤代理的判斷結(jié)果為 是，啟動跟蹤；
b3、跟蹤代理執(zhí)行跟蹤處理，上報被跟蹤組件的跟蹤日志給OSPE服務(wù)器； b4、跟蹤代理判斷SLT Token中設(shè)置的關(guān)閉跟蹤條件是否達成，如果達 成則執(zhí)行b6，否則執(zhí)行b5;
b5 、跟蹤代理將SLT Token下發(fā)到跟蹤路徑中的下一個跟蹤代理。
b6、跟蹤代理向OSPE服務(wù)器發(fā)送關(guān)閉業(yè)務(wù)跟蹤消息；為便于OSPE服務(wù)
器的判斷處理，請求中需要攜帶當(dāng)前Token的跟蹤標記(ID),還可以選擇攜 帶當(dāng)前關(guān)閉的原因；
A3、 OSPE服務(wù)器收到跟蹤代理的關(guān)閉業(yè)務(wù)跟蹤消息后，執(zhí)行關(guān)閉業(yè)務(wù)跟 蹤流程；這個過程可采用現(xiàn)有OSPE服務(wù)器進行跟蹤關(guān)閉的操作方式，其信令 流程如圖7所示，包括
cl、 OSPE服務(wù)器收到關(guān)閉業(yè)務(wù)跟蹤消息后根據(jù)請求中Token的ID所表 明的被跟蹤業(yè)務(wù)向SMAC查詢業(yè)務(wù)目錄；
c2、 SMAC返回查詢結(jié)果給OSPE服務(wù)器；
c3、 OSPE服務(wù)器根據(jù)查詢結(jié)果分別向被跟蹤業(yè)務(wù)所依賴各個跟蹤組件的 跟蹤代理下發(fā)關(guān)閉跟蹤命令；
c4、各個跟蹤代理關(guān)閉被跟蹤組件上的跟蹤功能，并向OSPE服務(wù)器反饋 關(guān)閉結(jié)果；圖7中各代理均反饋關(guān)閉確認信息；
c5 、 OSPE服務(wù)器判斷所有的跟蹤組件都正確反饋后向OSPE請求者發(fā)送 跟蹤結(jié)果，跟蹤結(jié)果中可包括跟蹤日志及確認信息等內(nèi)容， 一次業(yè)務(wù)跟蹤流程 結(jié)束。
在實際應(yīng)用過程中，為達到不同的跟蹤目的，實現(xiàn)不同的跟蹤效果，可以 對Token中的關(guān)閉跟蹤條件進行各種不同形式的設(shè)置，為更好的理解本發(fā)明， 對本發(fā)明跟蹤方法在實際應(yīng)用中的執(zhí)行過程舉例如下
應(yīng)用例一、代理ID定位5艮蹤
本例中OSPE請求者下達的跟蹤任務(wù)為上報業(yè)務(wù)1經(jīng)過跟蹤代理的跟蹤 日志；
與業(yè)務(wù)1對應(yīng)的SLT Token ID為T01; OSPE請求者給出的關(guān)閉跟蹤條件為跟蹤代理ID-B; OSPE請求者指定的跟蹤代理ID = A、 B、 C; SMAC中指定業(yè)務(wù)1的首個跟蹤組件上的跟蹤代理ID-A; 本例中關(guān)閉跟蹤條件，所需跟蹤的跟蹤代理ID由OSPE請求者指定，當(dāng) 然也可以采用由OSPE服務(wù)器生成的方式。
OSPE服務(wù)器下發(fā)的Token中所攜帶的主要信息如下表所示
Token ID跟蹤代理ID關(guān)閉跟蹤條件
T01ABC跟蹤代理ID-B
業(yè)務(wù)跟蹤信令流程為
① 打開跟蹤業(yè)務(wù)1下發(fā)SLTToken,如圖8所示，包括
dl、 OSPE請求者向OSPE服務(wù)器發(fā)送業(yè)務(wù)跟蹤請求；指明需要跟蹤的業(yè) 務(wù)1及所要跟蹤的代理ID = A、 B、 C;
d2、 OSPE服務(wù)器向SMAC查詢業(yè)務(wù)1的相關(guān)業(yè)務(wù)目錄；
d3、 SMAC返回查詢結(jié)果給OSPE服務(wù)器；查詢結(jié)果包括指定業(yè)務(wù)1的首 個跟蹤組件上的跟蹤代理ID = A;
d4、 OSPE服務(wù)器打開跟蹤代理A、 B、 C;
d5、跟蹤代理A、 B、 C向OSPE服務(wù)器反饋打開成功；
d6、 OSPE服務(wù)器根據(jù)SMAC中指定的首個跟蹤組件向該組件的跟蹤代理 A下發(fā)SLT Token;
d7、跟蹤代理A反饋下發(fā)成功；
② 跟蹤代理進行跟蹤業(yè)務(wù)處理，如圖9所示，包括 el、被跟蹤的業(yè)務(wù)1到達跟蹤代理A;
e2、跟蹤代理A判斷出業(yè)務(wù)1需要被跟蹤； e3、跟蹤代理A上報跟蹤日志給OSPE服務(wù)器；
e4、跟蹤代理A判斷SLTToken中設(shè)置的關(guān)閉跟蹤條件"跟蹤代理ID = B"不能達成；
e5、跟蹤代理A將SLTToken下發(fā)到跟蹤路徑中的下一個跟蹤代理，即跟 蹤代理B;
e6、跟蹤代理B判斷出業(yè)務(wù)1需要被跟蹤； e7、跟蹤代理B上報跟蹤日志給OSPE服務(wù)器；
e8、跟蹤代理B判斷SLTToken中設(shè)置的關(guān)閉跟蹤條件"跟蹤代理ID-B"可以達成；
e9、跟蹤代理B向OSPE服務(wù)器發(fā)送關(guān)閉業(yè)務(wù)1跟蹤請求；
③ OSPE服務(wù)器執(zhí)行關(guān)閉業(yè)務(wù)跟蹤流程，如圖10所示，包括
fl 、 OSPE服務(wù)器收到跟蹤代理B的關(guān)閉業(yè)務(wù)1跟蹤請求后向SMAC查詢
業(yè)務(wù)l的相關(guān)業(yè)務(wù)目錄；
f2、 SMAC返回查詢結(jié)果給OSPE服務(wù)器；
f3、 OSPE服務(wù)器向跟蹤代理A、 B、 C下發(fā)關(guān)閉跟蹤命令；
f4、跟蹤代理A、 B、 C向OSPE服務(wù)器反饋關(guān)閉確認信息；
f5、 OSPE服務(wù)器向OSPE請求者發(fā)送跟蹤結(jié)果，跟蹤結(jié)果中包括跟蹤代
理A、 B上報的跟蹤日志及確認信息等內(nèi)容，業(yè)務(wù)1跟蹤流程結(jié)束。
本應(yīng)用例給出了在不具體了解業(yè)務(wù)流行經(jīng)路徑的情況下，獲得業(yè)務(wù)在一次
交互中到達某指定組件所經(jīng)歷過程中跟蹤結(jié)果的情況。 應(yīng)用例二、判斷重復(fù)代理跟蹤
某些業(yè)務(wù)在正常過程中有可能會經(jīng)過A、 B、 C、 D、 E...等大量組件，并 且在一次業(yè)務(wù)交互中會重復(fù)經(jīng)過其中的某個跟蹤代理。本例中OSPE請求者下 達的跟蹤任務(wù)為記錄業(yè)務(wù)2的經(jīng)歷，精確獲得業(yè)務(wù)2在開始跟蹤直到其第一 次重復(fù)經(jīng)過某個跟蹤代理之間的所有日志，該代理事先并不確定。
與業(yè)務(wù)2對應(yīng)的SLT Token ID為T02;
OSPE請求者給出的關(guān)閉跟蹤條件為當(dāng)前代理的ID存在于Token的經(jīng) 歷記錄中；
SMAC中指定業(yè)務(wù)2的首個跟蹤組件上的跟蹤代理ID = A;
本例中關(guān)閉跟蹤條件由OSPE請求者指定，所需跟蹤的跟蹤代理ID由 OSPE服務(wù)器查詢SMAC獲得。
假定業(yè)務(wù)2的路徑順序為A、 D、 C、 A……，業(yè)務(wù)2跟蹤的流程如圖11 所示，包括
Bl、 OSPE服務(wù)器在SLT Token中添加了關(guān)閉跟蹤條件，并下發(fā)到跟蹤代 理A;
B2、跟蹤代理A上報跟蹤日志給OSPE服務(wù)器；
B3、跟蹤代理A判斷關(guān)閉跟蹤條件不能達成，因為Token只經(jīng)過了一次 代理A;
B4、跟蹤代理A將Token傳遞到跟蹤路徑中的下一個組件跟蹤代理D;
B5、跟蹤代理D上報跟蹤日志給OSPE服務(wù)器； B6、跟蹤代理D判斷關(guān)閉跟蹤條件不能達成；
B7、跟蹤代理D將Token傳遞到跟蹤路徑中的下一個組件跟蹤代理C; B8、跟蹤代理C上才艮跟蹤日志給OSPE服務(wù)器； B9、跟蹤代理C判斷關(guān)閉跟蹤條件不能達成；
BIO、跟蹤代理C將Token傳遞到跟蹤路徑中的下一個組件跟蹤代理A; Bll、跟蹤代理A上報跟蹤日志給OSPE服務(wù)器；
B12、跟蹤代理A判斷關(guān)閉跟蹤條件可以達成，因為Token現(xiàn)在是第二次 經(jīng)過代理A;
B13、跟蹤代理A向OSPE服務(wù)器發(fā)送關(guān)閉業(yè)務(wù)2跟蹤請求； B14、 OSPE服務(wù)器關(guān)閉業(yè)務(wù)2各個相關(guān)組件的跟蹤代理； B15、 OSPE服務(wù)器向OSPE請求者發(fā)送跟蹤結(jié)果，跟蹤結(jié)果中包括跟蹤 代理A上報的兩次以及跟蹤代理C、D上報的各一次跟蹤日志和確認信息等內(nèi) 容，業(yè)務(wù)2跟蹤流程結(jié)束。
本應(yīng)用例中，當(dāng)業(yè)務(wù)2兩次經(jīng)過事先并不確定的跟蹤代理A時，就立刻 觸發(fā)了主動關(guān)閉業(yè)務(wù)跟蹤的流程，精確的獲得了業(yè)務(wù)2在開始跟蹤直到其第一 次重復(fù)經(jīng)過某個跟蹤代理之間的所有日志。
本應(yīng)用例中所采用的關(guān)閉跟蹤條件在那些不是所有跟蹤代理都具有關(guān)閉 判斷能力的系統(tǒng)(以下簡稱混合系統(tǒng))中可以進行適當(dāng)?shù)男薷模恍枰獙㈥P(guān)閉 跟蹤條件改為"Token的經(jīng)歷記錄中有重復(fù)的代理ID"，由于每個跟蹤代理收 到Token時都在其經(jīng)歷記錄中加入自己的信息，即便發(fā)生重復(fù)的代理可能不具 備發(fā)起跟蹤關(guān)閉的能力，后續(xù)有能力的跟蹤代理也能及時作出判斷，關(guān)閉跟蹤。 實際應(yīng)用中的其他情況也可以仿照處理，通過對關(guān)閉跟蹤條件的合理設(shè)置，即 可同樣在硬件條件受限的混合系統(tǒng)中使用本發(fā)明方法。 應(yīng)用例三、計數(shù)跟蹤
本例中OSPE請求者下達的跟蹤任務(wù)為對業(yè)務(wù)3所經(jīng)歷的組件進行計數(shù)， 獲得業(yè)務(wù)3在開始跟蹤直到預(yù)先設(shè)定的第n個組件(n為預(yù)先設(shè)定值，該組件 本身并不知曉)之間的所有日志。
OSPE請求者給出的關(guān)閉跟蹤條件為計數(shù)值為n;
本例中關(guān)閉跟蹤條件由OSPE請求者指定，所需跟蹤的跟蹤代理ID由 OSPE服務(wù)器查詢SMAC獲得。若在混合系統(tǒng)情況下執(zhí)行本例跟蹤任務(wù)，將 關(guān)閉跟蹤條件修改為計數(shù)值達到或大于n,即可。具體跟蹤過程參照實施例 一進行，不再贅述。
應(yīng)用例四、計時if艮蹤
本例中OSPE請求者下達的跟蹤任務(wù)為對業(yè)務(wù)4的經(jīng)歷進行計時，獲得 業(yè)務(wù)4從開始跟蹤直到預(yù)先設(shè)定的時間n達到或超過時，所經(jīng)歷的所有組件的 曰志。
OSPE請求者給出的關(guān)閉跟蹤條件為計時值達到或大于n;
本例中關(guān)閉跟蹤條件由OSPE請求者指定，所需跟蹤的跟蹤代理ID由 OSPE服務(wù)器查詢SMAC獲得。若在混合系統(tǒng)情況下執(zhí)行本例跟蹤任務(wù)，可 不必修改關(guān)閉跟蹤條件。
應(yīng)用例五、判斷延遲if艮蹤
本例中OSPE請求者下達的跟蹤任務(wù)為記錄業(yè)務(wù)5經(jīng)歷各組件的時刻， 獲得業(yè)務(wù)5在某組件的跟蹤代理的日志，業(yè)務(wù)5經(jīng)由該組件與其之前組件的時 間延遲超過了事先定義的延遲。
OSPE請求者給出的關(guān)閉跟蹤條件為當(dāng)前時間與上一個代理記錄的時間 比較差值大于n;
本例中關(guān)閉跟蹤條件由OSPE請求者指定，所需跟蹤的跟蹤代理ID由 OSPE服務(wù)器查詢SMAC獲得。
實施例二、 一種業(yè)務(wù)跟蹤方法，流程如圖12所示，包括
Cl、 OSPE服務(wù)器向跟蹤代理下發(fā)SLT Token, Token中設(shè)置有關(guān)閉跟蹤
條件；
C2、 SLTToken下發(fā)后，隨同業(yè)務(wù)流在跟蹤代理之間傳遞，跟蹤代理的處 理步驟包括
C21 、獲得SLT Token的跟蹤代理執(zhí)行相應(yīng)的跟蹤處理；
C22 、跟蹤代理判斷SLT Token所攜帶的關(guān)閉跟蹤條件是否達成，若是則 執(zhí)行C23，若否則轉(zhuǎn)到C25;
C23、跟蹤代理關(guān)閉本代理的業(yè)務(wù)跟蹤；
C24、確認本代理關(guān)閉跟蹤后，跟蹤代理向OSPE服務(wù)器發(fā)送通知消息， 由OSPE服務(wù)器來執(zhí)行后續(xù)的關(guān)閉業(yè)務(wù)跟蹤操作C3;
C25 、跟蹤代理將SLT Token傳遞給下一個跟蹤代理，由下一個跟蹤代理 重復(fù)上述處理過程；
C3、 OSPE服務(wù)器收到跟蹤代理的通知消息后，執(zhí)行關(guān)閉業(yè)務(wù)跟蹤流程， 關(guān)閉其它跟蹤代理的跟蹤。
本實施例與實施例一的區(qū)別在于，跟蹤代理判斷所述關(guān)閉跟蹤條件達成后 主動發(fā)起的跟蹤關(guān)閉過程為，先關(guān)閉本代理的跟蹤再向所述跟蹤控制服務(wù)器發(fā) 送通知消息。
實施例三、 一種跟蹤代理，如圖13所示，用于部署在被跟蹤部件上進行 業(yè)務(wù)跟蹤處理，包括跟蹤處理模塊ll、跟蹤關(guān)閉發(fā)起模塊12;
跟蹤處理模塊11完成通常跟蹤代理所執(zhí)行的操作接收SLTToken;判斷 當(dāng)前傳送的SLT Token是否為需要執(zhí)行跟蹤任務(wù)的Token,如果判斷為是，則 執(zhí)行跟蹤處理，例如發(fā)送跟蹤日志等，如果判斷為否則繼續(xù)傳遞SLTToken; 該模塊也會向Token中記錄自身的基本信息，例如代理ID,到達時間等；
本發(fā)明為跟蹤代理增加了新模塊，即跟蹤關(guān)閉發(fā)起模塊12，跟蹤處理模 塊11在執(zhí)行跟蹤任務(wù)后將SLT Token轉(zhuǎn)發(fā)給跟蹤關(guān)閉發(fā)起模塊12;
跟蹤關(guān)閉發(fā)起模塊12接收跟蹤處理模塊11轉(zhuǎn)發(fā)的Token,判斷Token中 設(shè)置的關(guān)閉跟蹤條件是否達成根據(jù)判斷結(jié)果確定是否發(fā)起跟蹤關(guān)閉；跟蹤關(guān)閉 發(fā)起模塊12也可以選擇在確定發(fā)起跟蹤關(guān)閉的時候，先發(fā)送關(guān)閉命令關(guān)閉跟 蹤處理模塊11的業(yè)務(wù)跟蹤，如圖13中虛線箭頭所示，跟蹤處理模塊11即關(guān) 閉相應(yīng)組件的跟蹤功能并反饋關(guān)閉結(jié)果給跟蹤關(guān)閉發(fā)起模塊12,跟蹤關(guān)閉發(fā) 起模塊12收到跟蹤處理模塊11的確認后再發(fā)起跟蹤關(guān)閉；
跟蹤關(guān)閉發(fā)起;f莫塊12在進行關(guān)閉跟蹤條件是否達成的判斷時，可基于關(guān) 閉跟蹤條件的要求進行相應(yīng)信息的收集和獲取，例如取得其所在跟蹤代理模塊 的基本信息，包括當(dāng)前代理的名稱、ID、狀態(tài)、系統(tǒng)時間、運行時間等；還可
以按照關(guān)閉跟蹤條件的要求取得Token中其他部分的信息，例如Token中記錄 的所經(jīng)歷跟蹤代理的歷史記錄等，以作為關(guān)閉跟蹤條件判斷的依據(jù)。
實施例四、 一種OSPE服務(wù)器，如圖14所示，用于跟蹤活動的管理，包 括跟蹤代理控制模塊21、 Token生成模塊22;
跟蹤代理控制模塊21將跟蹤任務(wù)信息通知到Token生成模塊22，產(chǎn)生并 下發(fā)打開跟蹤命令和關(guān)閉跟蹤命令，以及執(zhí)行業(yè)務(wù)目錄的查詢等；通常跟蹤任 務(wù)信息來自于OSPE請求者的業(yè)務(wù)跟蹤請求，跟蹤代理控制模塊21根據(jù)打開 和關(guān)閉業(yè)務(wù)跟蹤消息來控制跟蹤的打開和關(guān)閉；
Token生成模塊22包括Token處理模塊221, Token處理模塊221完成通 常Token生成模塊所執(zhí)行的操作根據(jù)跟蹤任務(wù)信息產(chǎn)生SLTToken,為Token 設(shè)置諸如Token ID、代理ID等參數(shù)，并下發(fā)Token;
本發(fā)明為Token生成模塊22增加了新的功能模塊，即關(guān)閉條件添加模塊 222,關(guān)閉條件添加模塊222在Token處理模塊221產(chǎn)生的SLT Token中設(shè)置 關(guān)閉跟蹤條件，Token處理模塊221下發(fā)添加了關(guān)閉跟蹤條件的Token。
實施例五、 一種OSPE系統(tǒng)，如圖15所示，用于進行業(yè)務(wù)跟蹤，包括跟 蹤代理l、 OSPE服務(wù)器2，跟蹤代理l可以有若干個；
OSPE服務(wù)器2控制跟蹤代理1的打開跟蹤或關(guān)閉跟蹤，生成并向跟蹤代 理1下發(fā)SLT Token,在下發(fā)的Token中設(shè)置關(guān)閉跟蹤條件，接收跟蹤代理1 上報的跟蹤日志以及關(guān)閉業(yè)務(wù)跟蹤消息，并根據(jù)該關(guān)閉業(yè)務(wù)跟蹤消息控制跟蹤 代理1的關(guān)閉；
跟蹤代理1接收并傳遞SLT Token,根據(jù)SLT Token執(zhí)行跟蹤處理；判斷 Token中設(shè)置的關(guān)閉跟蹤條件是否達成，根據(jù)判斷結(jié)果確定是否向OSPE服務(wù) 器2發(fā)送關(guān)閉業(yè)務(wù)跟蹤消息。
本實施例中所使用的跟蹤代理1、 OSPE服務(wù)器2可分別采用實施例三、 四中提供的模塊結(jié)構(gòu)，如圖16所示(清楚起見，圖中只表示出了首個跟蹤代 理，余可類推)跟蹤代理1的跟蹤處理模塊11接收OSPE服務(wù)器2的Token 生成模塊22下發(fā)的帶有關(guān)閉條件的SLTToken,發(fā)送跟蹤日志到OSPE服務(wù)器 2的跟蹤代理控制模塊21;跟蹤代理1的跟蹤關(guān)閉發(fā)起模塊12發(fā)送關(guān)閉業(yè)務(wù)
跟蹤消息到OSPE服務(wù)器2的跟蹤代理控制模塊21; OSPE服務(wù)器2的跟蹤代 理控制模塊21下發(fā)打開跟蹤命令和關(guān)閉跟蹤命令到跟蹤代理1的跟蹤處理模 塊11。
在本發(fā)明系統(tǒng)中，除了采用本發(fā)明提供的跟蹤代理外，也可包含不具有關(guān) 閉發(fā)起功能的普通跟蹤代理，這種混合組網(wǎng)的形式如圖17所示，普通跟蹤代 理不具備跟蹤關(guān)閉發(fā)起模塊，不進行關(guān)閉條件的判斷。如前所述，只要恰當(dāng)設(shè) 置關(guān)閉跟蹤條件，混合組網(wǎng)形式下也能使本發(fā)明方法得到較好的實現(xiàn)。
實施例六、 一種OSPE系統(tǒng)，如圖18所示，本實施例與實施例五的區(qū)別 在于，還包括SMAC 3, OSPE服務(wù)器2向SMAC 3發(fā)送查詢命令進行業(yè)務(wù)目 錄查詢，獲得SMAC3返回的查詢信息，OSPE服務(wù)器2根據(jù)查詢結(jié)果，例如 被跟蹤業(yè)務(wù)所依賴的組件ID等，進行跟蹤令牌的生成以及相應(yīng)跟蹤代理的打 開跟蹤或關(guān)閉跟蹤。
以上對本發(fā)明所提供的業(yè)務(wù)跟蹤方法以及相應(yīng)的跟蹤代理、跟蹤控制服務(wù) 器和跟蹤系統(tǒng)進行了詳細介紹，本文中應(yīng)用了具體個例對本發(fā)明的原理及實施 方式進行了闡述，以上實施例的說明只是用于幫助理解本發(fā)明的方法及其核心 思想；同時，對于本領(lǐng)域的一般技術(shù)人員，依據(jù)本發(fā)明的思想，在具體實施方 式及應(yīng)用范圍上均會有改變之處，綜上所述，本說明書內(nèi)容不應(yīng)理解為對本發(fā) 明的限制。
權(quán)利要求
1、一種業(yè)務(wù)跟蹤方法，其特征在于，包括跟蹤控制服務(wù)器向跟蹤代理下發(fā)跟蹤令牌，所述跟蹤令牌中設(shè)置有關(guān)閉跟蹤條件；獲得跟蹤令牌的跟蹤代理判斷所述關(guān)閉跟蹤條件是否達成，若達成則主動發(fā)起跟蹤關(guān)閉，若未達成則繼續(xù)執(zhí)行業(yè)務(wù)跟蹤流程。
2、 根據(jù)權(quán)利要求1所述的業(yè)務(wù)跟蹤方法，其特征在于獲得跟蹤令牌的 跟蹤代理或者先執(zhí)行本代理的跟蹤處理，再判斷所述關(guān)閉跟蹤條件是否達成， 若未達成則將所述跟蹤令牌傳遞給下一個跟蹤代理；或者先判斷所述關(guān)閉跟蹤條件是否達成，若未達成則執(zhí)行本代理的跟蹤處 理，并將所述跟蹤令牌傳遞給下一個跟蹤代理。
3、 根據(jù)權(quán)利要求2所述的業(yè)務(wù)跟蹤方法，其特征在于 所述關(guān)閉跟蹤條件由跟蹤請求者生成，通過業(yè)務(wù)跟蹤請求發(fā)送給跟蹤控制服務(wù)器，由跟蹤控制服務(wù)器設(shè)置在跟蹤令牌中；或者所述關(guān)閉跟蹤條件由跟蹤控制服務(wù)器生成，并設(shè)置在跟蹤令牌中。
4、 根據(jù)權(quán)利要求1 3任意一項所述的業(yè)務(wù)跟蹤方法，其特征在于所述 跟蹤令牌中還設(shè)置有跟蹤代理標識；所述跟蹤代理標識由跟蹤請求者指定，通過業(yè)務(wù)跟蹤請求發(fā)送給跟蹤控制 服務(wù)器，由跟蹤控制服務(wù)器設(shè)置在跟蹤令牌中；或者所述跟蹤代理標識由跟蹤控制服務(wù)器生成，并設(shè)置在跟蹤令牌中。
5、 根據(jù)權(quán)利要求1 3任意一項所述的業(yè)務(wù)跟蹤方法，其特征在于跟蹤 代理獲得跟蹤令牌后，先判斷是否為需要執(zhí)行跟蹤任務(wù)的跟蹤令牌，若是則上 報跟蹤日志，并判斷所述關(guān)閉跟蹤條件是否達成；若否則將所述跟蹤令牌傳遞 給下一個跟蹤代理。
6、 根據(jù)權(quán)利要求1 3任意一項所述的業(yè)務(wù)跟蹤方法，其特征在于所述 跟蹤代理主動發(fā)起跟蹤關(guān)閉包括，向所述跟蹤控制服務(wù)器發(fā)送關(guān)閉業(yè)務(wù)跟蹤消息，跟蹤控制服務(wù)器即執(zhí)行關(guān) 閉業(yè)務(wù)跟蹤流程；或者， 先關(guān)閉本代理的跟蹤再向所述跟蹤控制服務(wù)器發(fā)送通知消息，由跟蹤控制 服務(wù)器執(zhí)行其它跟蹤代理的關(guān)閉業(yè)務(wù)跟蹤流程。
7、 根據(jù)權(quán)利要求6所述的業(yè)務(wù)跟蹤方法，其特征在于，所述跟蹤控制服 務(wù)器執(zhí)行關(guān)閉業(yè)務(wù)跟蹤流程包括跟蹤控制服務(wù)器查詢業(yè)務(wù)目錄；跟蹤控制服務(wù)器根據(jù)查詢結(jié)果向相應(yīng)跟蹤代理下發(fā)關(guān)閉跟蹤命令； 跟蹤控制服務(wù)器判斷各個跟蹤代理都正確反饋后，將跟蹤結(jié)果發(fā)送給跟蹤 請求者。
8、 一種跟蹤代理，其特征在于包括跟蹤處理模塊、跟蹤關(guān)閉發(fā)起模塊； 所述跟蹤處理模塊接收跟蹤令牌，判斷當(dāng)前傳送的跟蹤令牌是否為需要執(zhí)行跟蹤任務(wù)的令牌，根據(jù)判斷結(jié)果或者繼續(xù)傳遞跟蹤令牌，或者執(zhí)行跟蹤處理 并向所述跟蹤關(guān)閉發(fā)起模塊轉(zhuǎn)發(fā)跟蹤令牌；所述跟蹤關(guān)閉發(fā)起模塊接收所述跟蹤處理模塊轉(zhuǎn)發(fā)的跟蹤令牌，判斷所述 跟蹤令牌中設(shè)置的關(guān)閉跟蹤條件是否達成，根據(jù)判斷結(jié)果確定是否發(fā)起跟蹤關(guān) 閉。
9、 根據(jù)權(quán)利要求8所述的跟蹤代理，其特征在于所述跟蹤關(guān)閉發(fā)起模 塊確定發(fā)起跟蹤關(guān)閉時，還向所述跟蹤處理模塊發(fā)送關(guān)閉命令。
10、 一種跟蹤控制服務(wù)器，包括跟蹤代理控制模塊和跟蹤令牌生成模塊； 所述跟蹤代理控制才莫塊將跟蹤任務(wù)信息通知到所述跟蹤令牌生成模塊，產(chǎn)生并下發(fā)打開跟蹤命令和關(guān)閉跟蹤命令；所述跟蹤令牌生成模塊包括跟蹤令牌處理模塊，所述跟蹤令牌處理模塊根 據(jù)所述跟蹤任務(wù)信息產(chǎn)生跟蹤令牌；其特征在于所述跟蹤令牌生成模塊還包括關(guān)閉條件添加模塊，所述關(guān)閉 條件添加模塊在所述跟蹤令牌處理模塊產(chǎn)生的跟蹤令牌中設(shè)置關(guān)閉跟蹤條件。
11、 一種跟蹤系統(tǒng)，包括跟蹤控制服務(wù)器和跟蹤代理， 所述跟蹤控制服務(wù)器控制跟蹤代理的打開跟蹤或關(guān)閉跟蹤，生成并向跟蹤代理下發(fā)跟蹤令牌，接收跟蹤代理上報的跟蹤日志；所述跟蹤代理接收并傳遞跟蹤令牌，根據(jù)跟蹤令牌執(zhí)行跟蹤處理； 其特征在于所述跟蹤控制服務(wù)器還在下發(fā)的跟蹤令牌中設(shè)置關(guān)閉跟蹤條 件，接收跟蹤代理發(fā)送的關(guān)閉業(yè)務(wù)跟蹤消息，并根據(jù)所述關(guān)閉業(yè)務(wù)跟蹤消息控 制跟蹤代理的關(guān)閉；所述跟蹤代理還判斷所述跟蹤令牌中設(shè)置的關(guān)閉跟蹤條件是否達成，根據(jù) 判斷結(jié)果確定是否向所述跟蹤控制服務(wù)器發(fā)送關(guān)閉業(yè)務(wù)跟蹤消息。12、根據(jù)權(quán)利要求11所述的跟蹤系統(tǒng)，其特征在于還包括業(yè)務(wù)數(shù)據(jù)庫；所述跟蹤控制服務(wù)器向所述業(yè)務(wù)數(shù)據(jù)庫發(fā)送查詢命令，進行業(yè)務(wù)目錄查 詢，根據(jù)查詢結(jié)果控制跟蹤令牌的生成以及相應(yīng)跟蹤代理的打開跟蹤或關(guān)閉跟 蹤；所述業(yè)務(wù)數(shù)據(jù)庫將被查詢信息發(fā)送給所述跟蹤控制服務(wù)器。
全文摘要
本發(fā)明公開了一種業(yè)務(wù)跟蹤方法，其核心思想是擴展跟蹤令牌的內(nèi)容，添加設(shè)置關(guān)閉跟蹤條件，由跟蹤代理在關(guān)閉跟蹤條件達成時主動發(fā)起跟蹤關(guān)閉。本發(fā)明還提供相應(yīng)的跟蹤代理、跟蹤控制服務(wù)器和跟蹤系統(tǒng)。由于跟蹤令牌隨同被跟蹤的業(yè)務(wù)流一同傳送，因此能夠精確的控制跟蹤范圍，根據(jù)跟蹤任務(wù)的需要有效獲取有價值的跟蹤結(jié)果，解決了無法確定適當(dāng)跟蹤關(guān)閉時機的困難，避免了系統(tǒng)資源的浪費。
文檔編號H04L12/26GK101114931SQ20061009951
公開日2008年1月30日 申請日期2006年7月26日 優(yōu)先權(quán)日2006年7月26日
發(fā)明者杰 唐, 徐文華, 彥 李, 石曉旻 申請人:華為技術(shù)有限公司