Manuel d'implémentation › Exemples d'étude de cas › Ecriture d'exemples de logique applicative efficaces

Ecriture d'exemples de logique applicative efficaces

Les meilleures recommandations sur la façon d'écrire efficacement des logiques applicatives sont données sur les sujets suivants :

• Métriques groupées
  • Lors de l'évaluation du volume du système, considérez une métrique groupée comme le nombre d'éléments dans la métrique et souvenez-vous que tout est multiplié.
  • Le nouveau calcul d'un élément groupé engendre le nouveau calcul du groupe entier. Par conséquent, souvenez-vous en lors de la planification du groupement, de la manière dont les adaptateurs sont configurés mais également lorsque vous changez la structure des ressources.
  • Les mêmes événements de données brutes se retrouvant dans plusieurs éléments groupés ont un coût de performance élevé (commutation de contexte).
• Variables globales
  • Insérez les paramètres et valeurs d'attribut dans chaque endroit dans le code où ils sont nécessaires. Evitez de les garder dans une variable globale et plus particulièrement dans des métriques groupées (à défaut d'augmenter la taille des "états")
  • Evitez la logique traitant les grands plans. A la place, traitez chaque événement dans la méthode OnXXEvent
  • Supprimez des éléments des plans dès que possible. Par exemple lorsqu'un ticket est clôturé et non à la fin de la période
• Modèles de conception

  Le package de contenu prédéfini contient plusieurs modèles de conception destinés à des scénarios communs. L'utilisation de ces modèles de conception peut améliorer les performances

• Fonctionnalité intégrée

  L'ACE dispose d'une fonctionnalité intégrée et d'outils utilisés à différents fins :

  • Fonctionnalité de période d'application
    • NetTime
    • IsWithinTimeslot
  • Temps des événements
    • TimeOfLastEvent
    • TimeOfLastEventHandler
  • Objet de contexte
    • Contient de nombreuses méthodes sensibles à l'environnement
    • Utilisez ces méthodes et évitez "Safe ODBC"
• Sorties de logique applicative

  Gardez la structure dans T_SLALOM_OUTPUTS. Cela signifie qu'il peut être très utile de placer des champs logiques similaires dans le même champ physique si vous possédez plusieurs tables logiques ayant une structure similaire dans T_SLALOM_OUTPUTS. Cela permet une indexation facile pour une performance de rapports accrue

• Réutilisabilité des événements

  A utiliser lorsque :

  • Plusieurs métriques effectuent le premier calcul de phase, nécessaire au contrat et envoient des événements à une métrique récapitulative qui calcule le résultat (par ex. calcul financier, KPI de haut niveau)
  • Une métrique seule effectue une agrégation préliminaire avec des données brutes et envoie les événements à plusieurs autres métriques. Raisonnable lorsque la métrique n'envoie que peu d'événements par rapport à ce qu'elle reçoit, où lorsque celle-ci effectue de nombreux calculs qui serait autrement répétés plusieurs fois.

  A éviter lorsque :

  • Vous augmentez significativement le nombre de métriques
  • Vous implémentez plus de trois niveaux
  • La complexité de l'implémentation augmente et la maintenance devient moins aisée
• Nouveaux calculs
  • Evitez les nouveaux calculs massifs comme partie de l'opération normale du système
  • Les raisons pour de nouveaux calculs sont les suivantes :
    • Données brutes avec un horodatage passé
    • Singularité d'événement au passé qui change les données brutes
    • Corrections
    • Exceptions
    • Changements dans les modules de logique applicative
    • Changements dans un contrat
    • Evénements de réutilisabilité d'événement avec un horodatage passé
    • Changements dans la structure de ressources
  • Considérez l'utilisation de la fonctionnalité de verrouillage des données calculées.
• Modules de logique applicative
  • Les modules de logique applicative doivent être écrits de sorte qu'une fois complètement vérifiés, ceux-ci n'aient pas besoin d'être changés
  • La directive est la suivante : un module égale une logique générique
  • Les modules de logique applicative très spécifiques ne peuvent pas servir beaucoup de métriques, et ne promeuvent pas la réutilisabilité de code et de logique
  • Les modules de logique applicative trop génériques sont difficiles à maintenir. De plus, si un module de logique applicative implémente de nombreuses logiques complexes, un correctif dans un flux (utilisé par une partie des métriques) cause un nouveau calcul de toutes les métriques
• Enregistrement
  • Exécutez toute la filtration des événements en utilisant l'enregistrement. Laisser le filtre au code influence fortement les performances
  • Allez au plus simple
  • Pour le code n'appartenant pas à l'enregistrement, servez-vous des méthodes dispatcher.IsRunTimeMode et d'OnResourceStructureChange, particulièrement lors de nombreux changements de ressources
  • Evitez d'utiliser la méthode RegisterByEventType
  • Dans les modules de logique applicative, utilisez un formulaire générique (par contractant, service ou type de ressource), des paramètres, ou laissez l'enregistrement se faire au moyen de l'interface utilisateur (option conseillée pour la réutilisabilité d'événement)