エンジンに再計算を強制するシステムのイベントのリストを以下に示します。
Raw データおよび中間データが発生した実際の時点より後に、これらのデータが追加される場合があります。 例として、あるイベント ソースが非アクティブで、データを受信しなかった場合があります。 新しいデータが追加されると、エンジンは追加されたイベントのタイムスタンプから再計算します。 たとえば、ドルの値が月の最後に入力されたとします。 その月の計算全体はその時点のドルの値に基づいていました。 エンジンはその月の最初に戻ると、新しい値を使用して再計算します。
データはすでに計算された後でも修正できます。 修正すると Raw データが置き換わります
注： この状況は中間データの場合ではありません。中間データの場合は修正を追加できません。
修正が追加されると、エンジンは変更が発生する前の状態を検索する必要があります。 その後エンジンは、その時点からの計算に含まれている新しい修正されたデータでメトリックの再計算を始めます。
たとえば、あるユーザが先週 Raw データとして誤って数字 5 を入力したとします。 このユーザが 5 を 3 に置換します。 エンジンは 5 が入力された日付から再計算する必要があります。 数字 3 が 5 の代わりに使用されます。
注： 修正は、正しくないデータの削除のみで、新しいデータへの置き換えが行われない場合があります。
以下への登録が行われると、イベントを受け取ります。
リソースが変更されると、エンジンはリソースが変更された時点から再計算します。 この再計算の例として、リソース グループからのリソースを割り当てまたは削除する場合、あるいはリソースのカスタム属性の値を変更する場合があります。
サーバのリストでそれらが継続中であることを示すステータスが表示されている場合に、サーバ 3 がメンテナンスのために外されたとします。 サーバ 3 はシステム通知なしで削除されました。 ユーザは、サーバ 3 がメンテナンス期間中に存在しなかったことをシステムに通知します。 エンジンはサーバ 3 が削除された日付に戻り、そこから再計算します。
リソースのカスタム属性が変更されると、エンジンはそのリソースに関連付けられているメトリックをすべて再計算します。 メトリックは、カスタム属性が変更された日付から再計算されます。
たとえば、サーバがニューヨーク、シカゴ、およびロサンジェルスに配置されているシナリオを考えてみます。 ユーザは、シカゴのサーバはニューヨークのグループに含まれると判断しています。 その後、管理者がシカゴのサーバは実際にはロサンジェルス グループの一部であると判断し、シカゴのサーバのステータスを変更しました。 この場合、エンジンは再計算を行う必要があります。
例外は定義された期間に対して作成できます。 たとえば、通常の勤務時間内として定義された期間があるとします。しかし、それには停電による例外があります。 この例外により、通常の勤務時間から指定された間隔が削除されます。 イベントはこの時点でタイムスロット外と見なされますが、引き続き処理されます。 一度この時間が通常のルーチンと区別されると、ビジネス ロジック スクリプトにタイムスロット外の動作を定義できます。 ただし、ユーザは、例外の期間内のエンジンの動作を定義することができません。 この動作は、標準のタイムスロット外の動作から変更できません。 例外は実際の期間の前または後に定義できます。 エンジンによってすでに計算されている時間枠に例外が追加されると、例外を考慮して再計算されます。
たとえば、1 週間前に停電が通知された場合があります。 システムは、停電を考慮に入れずに、現在の時間までの計算を行いました。 この場合再計算を必要とします。
ユーザによって定義されたビジネス ロジックは、個々のメトリックに作成できます。 また、ロジックが主要なもので再利用する必要がある場合、ビジネス ロジック モジュールに配置できます。 このように配置することで、ユーザが一度作成したロジックを、複数のメトリックで使用できます。 ただし、ロジックの誤りを修正するようモジュールが変更されると、変更されたモジュールにリンクしているすべてのメトリックが変更されます。 これらのメトリックは、この修正を反映するために再計算する必要があります。
たとえば、複数のクライアントがあり、それらのすべてがヘルプデスク メトリックを必要とすることがあります。 この場合、ヘルプデスク ロジックをビジネス ロジック モジュールに配置できます。
イベント再利用機能を使用すると、ほかのメトリックの計算結果を入力として使用するメトリックを作成できます。 このタイプのデータは中間データと呼ばれます。 このデータは、構造が Raw データと類似するイベントをメトリックに送信させることによって作成します。 その後、受信したメトリックは、この送信したメトリックに登録され、メトリックが Raw データ イベントを受信する場合と同じ方法で送信されたイベントを受信します。 送信したメトリックを再計算する場合、前に送信したイベントを削除し、再計算が必要な時間枠を再計算する必要があります。 つまり、前に送信した中間データが最新ではなくなったことを意味します。 このデータを受信するよう登録するメトリックも、新しいデータを反映するために再計算する必要があります。
契約バージョンを作成すると、そこに含まれるメトリックの一部またはすべてが契約バージョンの最初から再計算されます。 この再計算は、前のバージョンから変更があったメトリックでのみ実行されます。 契約バージョンを作成し、次に直接コミットすれば、再計算を受信しません。 メトリックに変更が含まれるため、再計算は発生しません。
再計算が発生しないケースを以下に示します。
新規契約バージョンは、再計算ではなく計算と見なされるため、再計算履歴には表示されません。
たとえば、ABC 社と 3 年間の契約があるとします。 この契約を 1 年間延長します。 この変更により、新規契約バージョンが作成されることになります。 ACE1 は 2005 年 1 月 1 日からメトリックを再計算します。
100 のメトリックのある契約がある場合、バージョンを作成し、それらのメトリックのうちの 1 つのメトリックのパラメータを変更すれば、変更は発生しません。 他のメトリックでは再計算しません。
注： 変更がかなり前に行われている場合は、再計算が長時間化する原因となります。 この再計算には長時間を要しますが、それは影響を受けたメトリックが変更の時点から再計算する必要があるためです。
|
Copyright © 2013 CA.
All rights reserved.
|
|