実装ガイド › 実装 › ビジネス ロジック スクリプティング（ビジネス ロジック エキスパート） › ビジネス ロジックの内部 › イベント フロー

イベント フロー

前述のように、ビジネス ロジックに対する入力は、エンジン イベントと Raw データ イベントです。

ビジネス ロジックによって受信された Raw データ イベントは、登録関数によって決定されます。この関数内でコードは、イベント タイプおよびリソース識別子によって定義されている、Raw データ イベントの特別なセットを要求します。

ビジネス ロジックにおける登録では、イベントが受信されたときに Raw データ イベントを処理するために実行する、ユーザ定義サブルーチンも関連付けます。 （デフォルトでは OnXXXEvent という名前ですが、これはもっとわかりやすい名前に変更する必要があります）。

エンジン イベントは、関連する契約およびメトリックの定義に従って、エンジンによってトリガされます。 エンジン イベントがトリガされ、受信されると、エンジンは適切なイベント ハンドラを実行します。 それぞれのエンジン イベントには、暗黙的なイベント ハンドラが 1 つあります。 これらのイベント ハンドラは VBScript の先頭に定義されている関数とプロシージャです。 登録および「結果」関数を処理するイベント ハンドラは、コード内で実装するために両方とも必須です。 他のすべてのイベント ハンドラは任意です。 ただしビジネス ロジックは、イベント ハンドラが実装されないエンジン イベントは処理しません。 そのため、将来的に拡張できるように、（使用されなくても）それらのものを同じ場所に残しておくのは良い方法です。

注： ビジネス ロジック スクリプトを記述する場合には、すべてのエンジン イベントを実装して、考えられるすべての可能性を網羅できるようにすることが重要です。 たとえば、実装の最初の段階でタイムスロットの定義が必要でなかったとしても、将来的に必要になった場合には、すべての計算式を修正する必要があります。 このため、ビジネス ロジック エキスパートは、最初は必要でなくても後でこの動作が必要になった場合に、必要なシステム変更が少量で済むように、"in timeslot" と "out of timeslot" の期間の動作を詳細に定義しておくことをお勧めします。

以下に、さまざまなエンジン イベントとそのイベント ハンドラを示します。

• OnLoad (Time)：（任意）。契約がアクティブになると、計算の開始時に 1 回コールされます。 グローバル変数を初期化するために使用できます。
• OnRegistration (Dispatcher)：（必須）。対象の Raw データ イベントを要求し、これらの Raw データ イベントを、処理されるユーザ定義プロシージャに関連付けるためのプロシージャ。 ディスパッチャ オブジェクトのメソッドを使用することにより、イベントが要求され、プロシージャに関連付けられます。
  OnRegistration はメトリックの計算の最初に、計算エンジンによって 1 回コールされ、メトリックに登録されているリソースが有効になるたびに再計算されます。その後エンジンは、そのリソースに対して行われた変更セットを評価しますが、これは計算式に分類されるイベント セットに影響を与えることがあります。 エンジンにはイベント要求の定義があります。これは、イベント タイプおよびリソース識別子によって、リソース（または複数のリソースが含まれている変更セット）が、このセットに関連する何らかのものを変更した場合に定義されるものです。 これがいったん有効になると、OnRegistration イベント ハンドラがトリガされます。
• OnPeriodStart (Time)：（任意）。（時間単位に従って設定される）エージェント期間の最初にコールされます。 最初の OnPeriodStart がいったんトリガされると契約が有効になります。ここで、残りの期間は、1 時間すべての時間単位で開始されます。 このイベント ハンドラは通常、変数を定期的に初期化するために使用されます。この変数とは、計算期間中に保留になっているインシデントのうち、各期間の最初にゼロに初期化する必要があるインシデントの数を保持するカウンタなどがあります。
• OnPeriodEnd (Time,IsCompleteRecord)：（任意）。（時間単位に従って設定される）エージェント期間の最後にコールされます。 これは常に、概数化された時間単位の最後（24:00 など）にコールされます。 （アプリケーション サーバの実際の時間に従って）メトリックの期間が終了した場合、IsCompleteRecord は True になり、中間の計算を作成する場合は False になります。 このイベント ハンドラは通常、Result 関数によって提供される最終的な結果の根拠を用意するために、終了期間に対する最後の計算で使用されます。
• OnTimeslotEnter (Time)：（任意）。関連付けられているメトリックの定義に基づいて、TimeSlot 期間に入ったときにコールされます。 たとえば、メトリックが営業時間のタイムスロット定義に関連付けられており、毎朝午前 8 時がタイムスロットの開始である場合、毎朝午前 8 時にこのイベント ハンドラがトリガされます。
• OnTimeSlotExit (Time)：（任意）。関連付けられているメトリックの定義に基づいて、TimeSlot 期間を終了するときにコールされます。 たとえば、メトリックが営業時間のタイムスロット定義に関連付けられており、毎日午後 5 時に終了する場合、この時間にイベント ハンドラがトリガされます。
• Target()：（任意）。メトリックが動的ターゲットを持つよう指定されている場合にコールされます。 これにより、ビジネス ロジックの実行時に、メトリックのサービス レベル目標値を決定することができます。 このようなターゲットには、サービス コンポーネントの消費やインフラストラクチャの変更が含まれます。 これには Result 関数と同じように、各モードに対して 1 つずつ、合計 4 つの値があります。 この関数は、通常の実行時に Result 関数の後で実行されます。
• Forecast()：（任意）。計算エンジンが、予測モードで契約をいったん計算することによって、契約バージョンのコミットを実行するときに一度コールされます。 予測モードは、契約における完全な計算エンジン サイクル（契約バージョンの開始日から終了日まで）を実行しています。 このサイクルの目的は単に予測値を計算することです。 （T_RAW_DATA テーブルでは計算は行われません）。関数は、この実行モードのときに、Result 関数の代わりにコールされます。
• Result()：（必須）。特定の期間についての計算結果を取得するために、計算エンジンによってコールされます。 Result 関数は常に、OnPeriodEnd イベント ハンドラの後にコールされます。

単一のビジネス ロジック計算式を処理するための、計算メカニズム（PslWriter サービス）の後の手順は以下のとおりです。

• PslWriter は計算式をメモリにロードし、宣言セクションにあるすべてのステートメント実行します（宣言セクションは、関数またはサブルーチンの外部にあるすべてのコードです）。 割り当てられているすべてのモジュールおよびライブラリが含まれており、実行用のこのシングル コード モジュールにコンパイルされることに注意してください。
• PslWriter が OnLoad イベント ハンドラをコールします。
• PslWriter が OnRegistration をコールします。
• OnPeriodStart のコールによって、期間の計算が開始されます。
• 期間の範囲内にある OnRegistration で登録されたそれぞれの Raw データ イベントについて、PslWriter は、そのイベントに関連付けられているユーザ定義のイベント ハンドラをコールします。
• タイムスロットの開始または終了が対象期間の範囲内にある場合、OnTimeslotEnter または OnTimeSlotExit がコールされます。
• 対象期間の範囲内で関連するインフラストラクチャが変更された場合、OnRegistration がコールされます。
• OnPeriodEnd のコールによって、期間の計算が修了します。
• 動的ターゲットが指定されている場合は、この関数がコールされます。
• 期間計算の最終結果を取得するために、PslWriter が Result 関数をコールします。

  注： 契約バージョンが最初にコミットされ、予測が選択されると、Result 関数の代わりに Forecast 関数がコールされます。 ただし、これは各バージョンに対してこの 1 回だけ発生します。

エンジンはそれぞれの計算サイクルで、計算期間に基づいて、エンジン イベントおよび Raw データ イベントは何かを評価します。 この評価は最初、時間で並べ替えられ、次に、計算のために計算式へ送信されます。 Raw データ イベントの時間はそのイベントのタイムスタンプで、エンジン イベントの時間はそれがトリガされた時間です。 これらの 2 つのタイプのイベントは時系列に組み合わされ、計算用に送信されます。

イベントのタイミングは関連付けられているローカル メトリックによって決まりますが、イベント ハンドラの Time パラメータ（OnPeriodStart (Time) など）、および Raw データ イベントのタイムスタンプは UTC の値に従っています。 エンジンは、参照で一定のポイントを使用できるように、UTC におけるそれぞれの値に従って比較を行います。

例：

あるメトリックで、UTC とのタイム ゾーンの差が 2 時間（つまり GMT+2）の場合、インシデントの開始イベントのタイムスタンプが午前 10 時で、エンジンの中でイベント ハンドラが使用するタイムスタンプは適宜シフトされ、実際には 8：00am UTC に開始される、ということがあります。 アダプタがこれと同じタイム ゾーンを使用するよう設定されているとすると、Raw データ イベントも、データベース内で UTC に合わせて 2 時間前に戻されます。 イベントがビジネス ロジックに渡されるとき、午前 10 時に始まる期間についてイベントの計算を行う計算エージェントは、実際にはそのイベントに対して UTC 時間を使用します（これは午前 8 時です）。 ただし、タイムスタンプを印刷するためにコード内で out.log メッセージを使用している場合は、（メトリックに従って）指定された期間が 10am であっても、UTC にシフトしたタイムスタンプ、つまり 8:00 AM が表示されます。

以下の計算の要件では、使用する前にイベントのタイムスタンプを変換することが重要です。

メトリックが、開始と終了が同じ日付であるようなインシデントの数を計算する場合、それぞれのインシデントの開始時間と終了時間を比較する必要があります。 インシデントの開始時間と終了時間が同じ日（および定義されているタイムスロット内の範囲内）になる場合、このインシデントはカウントされます。

インシデントを、元のローカル時間から UTC にシフトしている途中で、日付が変わってしまう（つまりもう一度 GMT+2 を使用する）ことがあります。 午前 1 時に開始されたインシデントは、UTC では前日の午後 11 時にシフトされます。このようなインシデントは、（シフト前はカウントの対象であっても）カウントされません。 これは、最初に時間をローカル メトリックの時間に戻して変換し、その後で単純に比較しなければならない場合です。 このような場合には、GetLocaleTime(utcTime) メソッドを使用します。 このメソッドは、UTC タイム ゾーンで指定された時間を、ローカル メトリックのタイム ゾーンに変換します。

イベント ハンドラのコードは以下のとおりです。
Sub OnIncidentEvent(eventDetails)
   If dateDiff("d",Tools.GetLocaleTime(eventDetails.time),_
     Tools.GetLocaleTime(eventDetails("ClosedAt)))=0 then
          CountIncidents=CountIncidents+1
   End If
End Sub