実装ガイド › ケース スタディ例 › ビジネス ロジック スクリプティングの例 › ケース スタディ 13： 動的コンポーネント グループの処理

ケース スタディ 13： 動的コンポーネント グループの処理

グループのメンバが動的で計算期間中に変化する場合のあるリソースのグループの値を格納する必要がある場合がよくあります。 以下の要件の例の計算では、リソースごとに中間計算を行い、最終集計結果を出す必要があります。

以下にそのような例をいくつか挙げます。

• サイトでのインシデント - 解決に X 時間を超える時間がかかるインシデントのあるサイトの割合を計算するか、または解決時間の平均が X を超えるインシデントのあるサイトを数えます。

  これらの例では、サイトは関連するインシデントのあるリソースです。

• サーバの可用性 - ‥‥可用性の割合が X % を超えるサーバ数を数えます。

  サーバは可用性の割合が評価される必要のあるリソースです。

• トランザクション タイプ - X 回を超えて失敗したトランザクション タイプの割合を計算します。

  この場合、トランザクション タイプは、関連する障害イベントのあるリソースです。 各トランザクション タイプについては、障害カウンタは中間結果として格納され、X を超える障害のあるトランザクション タイプの数が数えられます。

  

例：

計算要件として、以下の内容があります。

サーバのクラスタで構成されるシステムの可用性の割合を計算します。 システムが利用可能だと考えられるのは、基本的なサーバがすべて利用可能なときのみです。

ソリューション設計は以下のように実装されます。

システム可用性はその根本的なクラスタ リソースの可用性で評価されます。 この場合、ポイントごとのシステム ステータスを遅れずに評価するために、クラスタ化されたリソースすべてのステータスを管理、格納する必要があります。

そうするためには、モニタされたリソースごとのエントリのあるマップ（下のサンプル コード中の (ServerAvailabilityIndicators マップ）を保持するための式が必要です。 マップ オブジェクトはすべて、関連する値を参照するためにキー フィールドが必要なので、このマップはキー（リソース ID）としてリソース インジケータを持ちます。 コンポーネントのステータスが変更されるときはいつでも、このマップの関連するエントリが変更される必要があります。 各可用性イベントについては、式は、マップ内の関連リソースのステータスを更新し、それに応じてシステム ステータスを再評価します。

モニタされるリソースが変わる場合がある（計算期間中に削除される場合もあれば、追加される場合もあるでしょう）ため、これはその式内部で管理される必要があります。ここで、その管理は、変化を識別する関数を追加し、新規コンポーネントに新しいエントリを追加したり、コンポーネントが削除されている場合は、新規コンポーネントに新規エントリを追加したり、エントリを削除したりすることにより、モニタされているコンポーネント マップを更新する関数を追加することにより管理されます。

OnRegistration は Registration イベントを管理するイベント ハンドラです。ここで、Registration イベントは、モニタされているリソース中に変化が生じたときに発生します。 そのような変化は、リソースをコミット（または変更セット）した結果として生じる場合があります。これは、計算式の登録方法によっては計算に含まれるリソースに変更を生じる場合があります。

各登録中に、必要な変更についてのリソース状態を保持するマップを更新する必要があります。 これは、リソース状態を保持するために使用されるマップを、登録が実行されるときにリソースを保持しているマップと（登録方法を基準として）比較することを意味します。そして、追加されたリソースをすべて含むか、または移動されたリソースを削除します。

そのため、OnRegistration プロシージャは、モニタされたリソースをそれに応じて構造化するために、モニタされたリソースを新規に割り当てられたリソースと比較する関数を実行する必要があります。

コンテキスト オブジェクトには、登録方法に匹敵する一連の方法があります。 これらは、登録方法に応じたリソースの一部であるリソースすべてを備えたマップを返します。

次の例では、式の登録は ByContractParty で、したがって同じメソッドが Context.ResourcesOfContractParty によって使用されます。 これは、登録時にこのセットの一部であるリソースすべてを備えたマップを返します。

2 つのマップを比較するには、マップを並行に反復する必要があります。 マップの反復は "For Each" ステートメントを使用して行われます。 このステートメントにより、マップの値に沿って反復することが可能になります。したがって、ステータス値ではなくリソースに沿って反復するために、ステータス マップのミラーとして他のマップが必要です。 このステートメントは、マップのキーではなく値を繰り返します。 そのため、キーおよび値の両方として ID を保持する追加のマップが必要です。 さらに、ミラー マップを維持して継続的にステータス マップをミラーし、常に同じリソース セットを保持するようにします。 これは、ステータス マップが更新されたときは常にミラー マップも更新される必要があるということです。

以下の図は、マップのミラーリングの概念を示しています。

例：

Dim ServerAvailabilityIndicators
Dim MonitoredServers
Set ServerAvailabilityIndicators=CreateObject("SlalomMap.Map")
Set MonitoredServers=CreateObject("SlalomMap.Map")

Sub OnRegistration(dispatcher)
   dispatcher.RegisterByContractParty "OnAvailabilityEvent",_
      "Availability Event", "SAP Production Server"
   Dim AllocatedServers
   Set AllocatedServers = Context.ResourcesOfContractParty("SAP Production Server")
   UpdateMonitoredServers AllocatedServers
End Sub

Sub UpdateMonitoredServers(allocatedServers)
   Dim Server
   For Each Server In allocatedServers
      If Not MonitoredServers.Exist(Server) Then
         MonitoredServers(Server) = Server
         ServerAvailabilityIndicators(Server)=True
      End If
   次へ

   For Each Server In MonitoredServers
      If Not allocatedServers.Exist(Server) Then
         MonitoredServers.Erase Server
         ServerAvailabilityIndicators.Erase Server
      End If
   Next
End Sub

例：

以下の関数は、ミラー マップを使用してステータス マップを反復する方法を示しています。これが必要になるのは、モニタされているリソースごとのステータスを基準とするシステム全体のステータスを評価する必要がある場合です。

この例では、リソースすべてが利用可能な場合にシステムは利用可能だと見なされます。 1 つのコンポーネントが停止すれば、システムが停止したと見なすのに十分です。

Function SystemAvailability
   Dim Server
   For Each Server In MonitoredServers
      If ServerAvailabilityIndicators(Server) = DOWN then
         SystemAvailability=DOWN
         Exit Function
      End if
   Next
End Function

動的なリソース処理を備えたフル ビジネス ロジックの例を以下のデザイン パターン例で説明します。