Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

          目前SAP BusinessObjects Enterprise (BOE)成熟穩定的版本是XI3.1,因此許多BO的老客都會將舊系統升級至XI3.1版,在升級後許多老客在大量處理帶有等待事件的排程時,部份排程會遭遇到一個失敗的狀況:無法在指定的時間間隔內將物件排程。但是個別處理這些排程時又不會遭遇到這個失敗,要了解這個狀況發生的原因,就要先認識一個在XI3.1新加入的時間屬性:到期

        首先來認識2種執行個體,一是建立排程時設定的遞迴,遞迴會根據設定的間隔時間產生排程執行個體,在排入工作伺服器處理後產生報表執行個體;另一種就是這些等待排入工作伺服器的排程執行個體。第一種遞迴的執行個體會有3個時間屬性:建立時間、到期和下次執行時間。建立時間是新增這個遞迴時按下開始排程的時間,到期指的是新增時設定的結束日期/時間,而下次執行時間這個屬性一開始會是新增遞迴時設定的開始日期/時間 + 遞迴類型的間隔時間

        舉例來說,我們新增一個遞迴,開始日期/時間設定為2012/9/24上午11:45,結束日期/時間為2022/9/24上午11:45,遞迴類型為每5分鐘執行一次,然後在2012/9/24上午11:46按下開始排程,結果就會如下圖:

當遞迴設定的等待事件被觸發時,此遞迴就會產生一個排程執行個體並排入等待的佇列,同時更新下次執行時間的值,此時更新的數值並不是事件觸發時間 + 間隔時間,而是原來的下次執行時間 + N*間隔時間、且大於事件觸發時間的最小值,簡單來說,就是以原本的下次執行時間一直加上間隔時間直到大於事件觸發時間為止的數值,以上圖舉的例子來說,若事件在2012/9/25下午2:01被觸發,此遞迴在產生一個排程執行個體後,更新後的下次執行時間不是2012/9/25下午2:01 + 5分鐘,而是2012/9/24上午11:50 + N*5分鐘、且大於2012/9/25下午2:01的最小值 = 2012/9/25下午2:05

計算方式

2012/9/24上午11:50 + 5分鐘 = 2012/9/24上午11:55 < 2012/9/25下午2:01

2012/9/24上午11:55 + 5分鐘 = 2012/9/24下午12:00 < 2012/9/25下午2:01

                                                                 :

2012/9/25下午 1:55 + 5分鐘 = 2012/9/25下午 2:00 < 2012/9/25下午2:01

2012/9/24下午 2:00 + 5分鐘 = 2012/9/25下午 2:05 > 2012/9/25下午2:01

接著我們來了解另一種執行個體,也就是事件觸發後遞迴產生的排程執行個體,這一種執行個體會有4個時間屬性:建立時間、到期、開始時間和結束時間。

建立時間就是事件被觸發時遞迴產生此排程的時間,而到期這個數值會帶入前面提到的、更新過後的遞迴下次執行時間,開始時間則是此排程被排入工作伺服器處理、狀態由暫止變為執行中的時間,最後的結束時間則有2種狀況:一是排程在到期時間前處理完畢時,處理完成的時間;另一種就是未能在到期時間前處理完畢時,排程失敗的時間。

排程工作太多,就需要排隊。

          在了解這些時間屬性之後,就可以進一步了解為什麼在大量處理帶有等待事件的排程時,會發生無法在指定的時間間隔內將物件排程的錯誤。現在我們有一個帶有等待事件的遞迴排程,遞迴類型為每5分鐘執行一次,目前的下次執行時間為2012/9/25下午2:43,如下圖:

          假設我們在2012/9/26上午10:24觸發了”12345”事件,此遞迴產生了一個排程執行個體並排入等待佇列,同時下次執行時間更新為2012/9/26上午10:28 (參考上述計算方式),此時產生的排程執行個體狀態為暫止,且有以下兩個時間屬性:

建立時間:    2012/9/26上午10:24

到期:            2012/9/26上午10:28

接著假如此排程執行個體在2012/9/26上午10:25時被排入工作伺服器處理,狀態變更為執行中,並花了2分鐘處理完畢後狀態變更為成功,在這個情況下,排程在到期之前就處理完畢所以不會發生錯誤。此時執行個體的時間屬性如下:

建立時間:    2012/9/26上午10:24

到期:            2012/9/26上午10:28

開始時間:    2012/9/26上午10:25

結束時間:    2012/9/26上午10:27

        現在假設有更大量的排程執行個體同時在佇列中等待工作伺服器處理,而剛剛的排程執行個體在2012/9/26上午10:30才被排入處理,此時排程會失敗,且失敗訊息就是無法在指定的時間間隔內將物件排程。執行個體的時間屬性如下:

建立時間:    2012/9/26上午10:24

到期:            2012/9/26上午10:28

開始時間:    2012/9/26上午10:30

結束時間:    2012/9/26上午10:30

        所以當同時在等待處理的排程越多、工作伺服器越忙碌時,這樣的排程錯誤就越容易發生。對此我們可以根據系統硬體性能增加工作伺服器的個數,或者增加工作伺服器屬性內的同時工作數目上限參數值,提升處理排程工作的能量來緩解大量排程等待的時間。

工作伺服器的屬性頁面

          在上面的例子裡,排程執行個體建立後在到期前,有4分鐘的時間可以等待排入工作伺服器處理並處理完成。如果事件是在2012/9/26上午10:27觸發,此時遞迴的下次執行時間根據計算方式仍然是2012/9/26上午10:28,因此產生的排程執行個體時間屬性會變成:

建立時間:    2012/9/26上午10:27

到期:            2012/9/26上午10:28

        在這個情況下排程執行個體建立後在到期前,只有1分鐘的時間可以等待排入工作伺服器處理並處理完成,在處理時間為2分鐘的前提下排程勢必會產生無法在指定的時間間隔內將物件排程的失敗。

        從這個例子我們可以發現,即使處理排程工作的能量足夠,在某些時間點觸發事件後,根據計算方式產生的到期時間,仍有可能會使排程可等待及處理的時間變得非常短,這個現象SAP原廠也已經注意到,並在FixPack 3.7FixPack 4.2之後進行了修正 (FixPack 4.1不包含),修正後的到期時間會在上述的計算方式結束後再加上一個遞迴類型的間隔時間 (以上面的例子就是再 + 5分鐘)。在這個邏輯下,只要在建立帶有等待事件的遞迴時設定較長的間隔時間,就能有效解決這樣的排程錯誤。

Labels in this area