Manuel d'implémentation › Exemples d'étude de cas › Exemples d'écriture de scripts de logique applicative › Etude de cas 13 : Traitement du groupe de composant dynamique

Etude de cas 13 : Traitement du groupe de composant dynamique

Il est souvent obligatoire de stocker des valeurs pour un groupe de ressources dans lequel les membres peuvent être dynamiques et changer durant la période de calcul. Dans l'exemple de condition de calcul suivant, il est nécessaire de réaliser un calcul intermédiaire pour chacune des ressources afin d'atteindre le résultat total final.

Quelques autres exemples de ce type :

• Incidents sur site : calcule le pourcentage d'emplacements comportant des incidents résolus en plus de X heures, ou dénombre les emplacements ayant une moyenne de résolution des incidents supérieure à X heures.

  Dans ces exemples, les sites sont des ressources ayant des incidents associés.

• Disponibilité du serveur : recense le nombre de serveurs dont le temps de disponibilité était plus grand que X%.

  Un serveur est une ressource pour laquelle le pourcentage de disponibilité doit être évalué.

• Types de transactions : calcule le pourcentage de type de transactions qui échoue plus de X fois.

  Dans ce cas, un type de transaction est une ressource ayant des événements de défaillance associée. Pour chaque type de transaction, un compteur de défaillance est stocké comme un résultat intermédiaire tandis que le nombre de types de transaction différents possédant plus de X défaillances sont dénombrés.

  

Exemple :

Pour la condition de calcul suivante :

Calculer le pourcentage de disponibilité pour un système composé d'un groupement de serveurs. Le système est considéré disponible uniquement lorsque tous les serveurs sous-jacents sont disponibles.

La solution sera implémentée comme suit :

La disponibilité de système est évaluée par la disponibilité de ses ressources groupées sous-jacentes. Dans ce cas, il est nécessaire de gérer et stocker le statut de toutes les ressources groupées pour évaluer le statut du système à chaque point dans le temps.

Pour ce faire, la formule doit contenir un plan (le plan ServerAvailabilityIndicators dans l'exemple de code ci-dessus) ayant une entrée pour chacune des ressources surveillées. Vu que tous les objets du plan requièrent un champ clé pour référencer la valeur associée, ce plan aura l'indicateur de ressource comme clé (ID de ressource) et la valeur sera le statut du composant. Quand le statut d'un composant change, l'entrée appropriée dans ce plan doit également être modifiée. La formule mettra à jour le statut de la ressource appropriée dans le plan pour chaque événement de disponibilité, et réévaluera le statut du système en conséquence.

Puisque les ressources surveillées peuvent changer (certaines peuvent être ajoutées ou supprimées durant la période de calcul), l'ajout d'une fonction dans la formule doit le gérer. Celle-ci aura pour but d'identifier le changement et de mettre à jour le plan de composant surveillé par l'ajout d'une nouvelle entrée par nouveau composant, ou par la suppression d'une entrée si le composant a été supprimé.

OnRegistration est le gestionnaire d'événements qui gère un événement d'enregistrement déclenché lors d'un changement dans les ressources surveillées. Un tel changement peut se produire lors de la validation d'une ressource (ou d'un ensemble de modifications) pouvant produire des changements dans les ressources incluses dans le calcul, d'après la méthode d'enregistrement de la formule.

Il est nécessaire de mettre à jour le plan contenant les statuts de ressource durant chaque enregistrement et pour tout changement requis. Cela signifie comparer le plan utilisé auparavant pour contenir les statuts de ressources et celui utilisé pour contenir les ressources au moment de l'enregistrement (d'après la méthode d'enregistrement), puis inclure toutes les ressources ajoutées ou effacer les ressources supprimées.

La procédure OnRegistration doit alors exécuter une fonction comparant les ressources surveillées aux nouvelles ressources allouées, ceci afin de structurer les ressources surveillées en conséquence.

L'objet Contexte dispose d'un ensemble de méthodes mettant en parallèle les méthodes d'enregistrement. Cela renvoie un plan comportant toute ressource faisant partie des ressources d'après la méthode d'enregistrement.

Dans l'exemple suivant, l'enregistrement de la formule est ByContractParty, et la même méthode est par conséquent utilisée par Context.ResourcesOfContractParty. Cela renvoie un plan comportant toute ressource faisant partie de cet ensemble au moment de l'enregistrement.

Il est nécessaire d'itérer en parallèle à travers les plans pour comparer les deux plans. Le plans sont itérés en utilisant l'instruction "For Each". Cette instruction permet l'itération à travers les valeurs d'un plan, par conséquent, un second plan miroir du premier est nécessaire pour pouvoir itérer à travers les ressources et non leurs valeurs de statut. Cette instruction répète les valeurs d'un plan et non ses clés. Par conséquent, un plan supplémentaire comportant les ID en tant que clé et valeur est nécessaire. Maintenez également le plan miroir pour refléter continuellement le plan de statuts afin que les deux contiennent en permanence le même ensemble de ressources. Cela signifie que lorsque le plan de statuts est mis à jour, le plan miroir doit l'être également.

L'illustration suivante affiche le concept des plans miroirs.

Exemple :

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
   Next

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

Exemple :

La fonction suivante démontre la manière dont le plan miroir est utilisé à travers le plan de statuts lorsque l'évaluation du statut du système entier est requise, évaluation basée sur le statut de chaque ressource surveillée.

Dans cet exemple, le système est considéré disponible si toutes les ressources sont disponibles. Avoir un seul composant éteint est assez pour considérer le système éteint :

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

Un exemple de logique applicative complet avec traitement de ressource dynamique est décrit dans l'exemple de modèle de conception suivant.