実装ガイド › 実装 › ビジネス ロジック スクリプティング（ビジネス ロジック エキスパート） › ビジネス ロジックの内部 › 出力 - ユーザ テーブル

出力 - ユーザ テーブル

標準のビジネス ロジック スクリプトは、外部の出力テーブルに対するアクセス権がありません。 出力先は以下の 2 つだけになります。

• PSL テーブル（T_PSL）。エンジンはこのテーブルに対してサービス レベルの結果を自動的に書き込みます。また、結果の関数で指定された結果は、このテーブルに書き込まれます。 このテーブルに書き込まれるサービス レベルの値は、数値タイプのみです。 T_PSL テーブルに書き込まれる結果は、レポート ウィザードがレポートする結果です。 これらの結果が書き込まれる構造またはメソッドについて制御することはできません。 これは、関連付けエンジンによって自動的に行われます。
• SLALOM 出力テーブル（T_SLALOM_OUTPUTS）。 このテーブルへの書き込みは、ビジネス ロジック計算式の Tools オブジェクトによって提供されるメソッドを使用して行われます。 このテーブルへ出力する場合、ユーザ テーブルとして参照される論理テーブル名が提供されます。 これらのテーブルを使用して、サービスレベル計算の際に情報を出力します。 後でこの情報を使用して、自由形式のレポートを生成することができます。 多くのユーザ テーブルが存在する場合があります。

定期的なサービス レベル結果のほかに追加の出力が必要な場合、別のメトリックを追加しても、これ以上の出力が得られない場合、または別のメトリックを追加すると、同じレコード セットを通過して異なる出力を提供するだけで、計算のパフォーマンスが低下する場合には、T_SLALOM_OUTPUTS 外部テーブルの使用が必要になります。

たとえば、1 日以内に解決されたチケットの割合を計算するようメトリックが設定されており、1 日以内に解決できなかったすべてのチケット リストを示したレポートを作成する必要がある場合について考えてみると、計算式で、外部テーブルに対する障害とみなされた各チケットを出力し、それを計算の統計に追加する必要があります。

前述の要件では、標準の出力サービス レベル テーブルはこの出力を提供できません。理由は以下のとおりです。

• サービス結果はすべて数値である
• 各期間に対しては、単一のサービス レベル結果しか使用できない

メトリックのトラッキング期間に実行されているエージェント、および例外と修正を計算しているエージェントに対してのみ、ユーザの出力テーブルにレコードが書き込まれます。 たとえば、月単位のトラッキング期間を持つようメトリックが定義されている場合、エンジンが他の粒度（HOUR、DAY、WEEK、QUARTER、YEAR など）について計算式を実行しても、出力ステートメント（Tools.SaveRecord and Tools.SaveFields）は実行されません。

このテーブルを外部で保持していることによる他のメリットは、複数のレポート要件で使用できることです。 他の典型的なレポート要件は、これらのテーブル、および契約要件から生成することができます。 たとえば、1 か月に「クローズしたチケット数」を計算するメトリックは、チケットの解決時間を計算することも、この情報をすべて出力テーブルに出力することも可能です。 これにより、期間中にクローズした個々のチケットについて、より詳細な分析が可能になり、別のレポート要件で必要とされる可能性のある、より詳細な情報が得られます。

これらのテーブルの情報も、エンジンの再計算メカニズムによって管理されます。 この再計算プロセス中に、レコードは非アクティブとしてマークされ、代わりに新しい行が書き込まれます。 すべての自由形式レポートの SQL ステートメントでは、T_SLALOM_OUTPUTS テーブルの IS_ACTIVE フィールドについてのチェック（is_active = 1）を含める必要があるため、これは重要なポイントです。これらのレコードのみが最新であるためです。

注： 計算式のデバッグ プロセス中にビジネス ロジック スコープを実行すると、メッセージは、T_SLALOM_OUTPUTS テーブルの代わりに、T_DEBUG_SLALOM_OUTPUTS テーブルに書き込まれます。

T_SLALOM_OUTPUTS を使用してデータを文書化する場合、挿入されるデータは常にテキストです（T_SLALOM_OUTPUTS のフィールドがすべて varchar2 であるため）。 したがって、オペレーティング システムのフォーマットを適用することにより、日付の値はテキストに変換されます。オペレーティング システムのフォーマットは、アプリケーションのライフサイクル中に変わることがあります。 これにより、T_SLALOM_OUTPUTS は日付のフォーマットの整合性が保持できないことがあります。 また、ビジネス ロジックは UTC の日付を処理しますが、あるユーザは T_SLALOM_OUTPUTS でローカル タイムスタンプが保持されることを期待しています。このため、このような状況に対応するために、変換関数 Tools.GetLocaleDate(date) の使用が必要になることがあります。

以下の関数は、日付をローカル時間に変換し、日付を dd/mm/yyyy hh24:mi:ss 形式にフォーマットすることによって、日付フォーマットの整合性を保持します。
Function FormatDate(time)
     Dim LocalTime
     LocalTime=Tools.GetLocaleTime(time)
     FormatDate=Day(LocalTime) & "/" & Month(LocalTime) & "/" &
  Year(LocalTime) & " " & _
     Hour(LocalTime) & ":" & Minute(LocalTime) & ":" & Second(LocalTime)
End Function

ビジネス ロジック計算式から外部テーブルへ書き込むには、以下の 2 つのメソッドを使用できます。

• Tools.SaveRecord <parameter list>
• Tools.SaveFields <parameter list>

Tools オブジェクトのこれらのメソッドについては、以下で詳しく説明します。

Tools.SaveRecord tableName, key,[val1],[val2],…

このメソッドは、T_SLALOM_OUTPUTS というテーブルにレコードを保存します。 tableName パラメータは、T_SLALOM_OUTPUTS 内の（仮想）テーブルを指定します。このテーブルに情報が書き込まれます。 ユーザ テーブルの各レコードには、情報の書き込み先であるレコードを指定する一意のキーがあります。 また、各レコードには、最大 20 文字の文字列タイプの値フィールドがあります。 SaveRecord メソッドは、ユーザ テーブル名とキーを受信します。 また、ユーザ テーブル内のすべての値フィールドを承認します （これらの値パラメータはオプションで、省略される場合があります）。同じキーを持つレコードがすでに存在している場合、そのレコードは更新されます （パラメータとして転送される値フィールドのみが更新されます）。このキーを持つレコードが存在しない場合は、レコードが作成されます。

Tools.SaveFields tableName, key, [fieldName1,fieldVal1], [fieldName2,fieldVal2]

このメソッドは SaveRecord に似ていますが、すべての値を列挙する代わりに、フィールド名と関連するフィールド値のペアを指定する点が異なります。 フィールド名の代わりにフィールド数を使用することができます。 フィールド名は、T_SO_FIELD_NAMES テーブルの中にあらかじめ手動で定義しておく必要があります。 このテーブルは、出力テーブルの構造を記録するために使用します。

T_SLALOM_OUTPUTS へ書き込む前に、ビジネス ロジック エキスパートで出力テーブルの構造を定義しておくことをお勧めします。これは、この時点で構造およびフィールドの意味を明確にして、クエリをより簡潔にするためです。

テーブルは次のようになります。

• table_name： 各論理テーブルには一意の名前があります。
• field_name： テーブル内の各フィールドは一意です。
• field_id： 各フィールドは、1 から始まるシリアル番号でナンバリングされています。

SaveFields メソッドは、挿入された値の構造および意味について文書を保持するため、このメソッドを使用することが推奨されます。

例：

メトリックの結果によって、しきい値以内の時間で解決されたチケットの割合を計算するだけでなく、解決時間が定義されたしきい値を超えてしまったすべてのインシデントのリストを生成する必要がる場合について考えてみます。 出力テーブルへの書き込みは、しきい値の検証の後で、OnXXXEvent イベント ハンドラ プロシージャで行われます。

これは、以下の例のように示されます。

Sub OnIncidentEvent(eventDetails)
                                     
    If eventDetails("RESOLUTION_TIME")<=SThreshold Then
     CountSuccessIncident s= CountSuccessIncidents+1
    Else
building the record unique key
     KeyString= eventDetails("IncidentID") &eventDetails.Time	

        Tools.SaveFields "IncidentsTable", KeyString, "CASE_ID",
    eventDetails("CASE_ID"),_
           "CUSTOMER_REF",eventDetails("CUSTOMER_REF"),_
           "TICKET_CREATOR",eventDetails("TICKET_CREATOR"),_
           "CREATION_TIME",eventDetails("CREATION_TIME"),_
           "SEVERITY",eventDetails("SEVERITY"),_
           " RESOLUTION_TIME ",eventDetails("RESOLUTION_TIME "),_
           "CLOSE_TIME",eventDetails("CLOSE_TIME")
    End If
End Sub

T_SLALOM_OUTPUTS テーブルの使用に関して、いくつかの提案を示します。

• 出力テーブルには、必要なデータのみを書き込むことをお勧めします（それ以上のものは書き込みません）。
• 必要なメトリックの粒度についてのみ出力テーブルへ書き込みます。
• 値フィールドのデフォルト サイズは 50 文字です（ただし列 VAL_1 は例外で 512 文字です）。フィールドで 50 文字を超える値は、このデータ サイズに合わせて切り捨てする必要があります。このようにしないと、ビジネス ロジックで実行時エラーが表示されます。
• データに利用可能な列は 20 個の列（VAL_1… VAL_20）のみです。

注： テーブルへの書き込みではメモリ内での計算に比べて計算量が非常に多いため、出力テーブルへの書き込みがエンジンのパフォーマンスに影響を与える可能性があります。 このため、この機能の使用が必要かどうかと、この使用がどの部分で必要かを入念に検討して、このテーブルがアクセスされる回数を最小限に抑えます。

ユーザ定義テーブルからの情報に関するレポート

標準の CA Business Service Insight のレポート ウィザードは、出力テーブルに書き込まれた情報についてレポートを作成するためには使用できません。 この情報に関するレポートを取得するには、自由形式レポートを作成する必要があります。 これは、実質的にはこのテーブル上に SQL クエリを作成することを意味しています。 このテーブルには各種計算式によって書き込まれる多数の論理テーブルが含まれているため、SQL に精通している担当者 （データ ソース エキスパート）が T_SLALOM_OUTPUTS に対するビューを作成して、このテーブル内に含まれる各論理テーブルを区別したり、情報が計画どおりに取得されることを確認したりすることを容易にすることをお勧めします。

ビュー定義には、関連の情報タイプに対する文字列フィールド タイプのキャスト機能がすでにすべてあり、また必要なフィルタリング（論理テーブル、アクティブ レコード、関連するメトリックなど）も保持されています。

ビューの作成例を以下に示します。

create or replace view kpi_view as
select
     to_date(t...) as fieldName,
     to_number(t..), …
from t_slalom_outputs t,
     t_rules r,
     t_sla_versions sv,
     t_slas s,
where table_name = 'TableName'
     and is_active = 1
     and t.rule_id = r.psl_rule_id
     and r.sla_version_id = sv.sla_version_id
     and sv.sla_id = s.sla_id
     and sv.status = 'EFFECTIVE'