Bienvenue dans le prochain chapitre de ma série CI/CD, où nous discutons des approches possibles vers le développement de logiciels avec les technologies InterSystems et GitLab.
Aujourd'hui, nous reprenons la discussion sur l'interopérabilité, et plus particulièrement sur le suivi de vos déploiements d'interopérabilité. Si vous ne l'avez pas encore fait, configurez Alerte pour toutes vos productions d'interopérabilité afin de recevoir des alertes sur les erreurs et l'état de la production dans son ensemble.

Le paramètre de délais d'inactivité Inactivity Timeout est commun pour tous les hôtes métier d'interopérabilité (Interoperability Business Hosts). Un hôte métier possède le statut Inactif lorsqu'il n'a reçu aucun message pendant le nombre de secondes spécifié dans le champ de délai d'inactivité " Inactivity Timeout ". La fonction de surveillance de la production " Monitor Service " examine périodiquement l'état des services et des opérations métier au sein de la production et marque les éléments comme étant inactifs s'ils n'ont rien fait pendant le délai d'inactivité.
La valeur par défaut est 0 (zéro). Si ce paramètre est 0, l'hôte métier ne sera jamais marqué comme Inactif, quelle que soit la durée de son inactivité.

Ce paramètre est extrêmement utile, car il génère des alertes qui, associées aux alertes configurées, permettent de signaler les problèmes de production en temps réel. Le fait que l'élément "Business Host" soit inactif signifie qu'il peut y avoir des problèmes de production, d'intégration ou de connectivité réseau qui nécessitent d'être examinés.
Cependant, le Business Host ne peut avoir qu'un seul paramètre constant pour le délai d'inactivité, ce qui peut générer des alertes inutiles pendant les périodes connues de faible trafic : nuits, week-ends, vacances, etc.
Dans cet article, je décrirai plusieurs approches pour la mise en œuvre dynamique des délais d'inactivité (Inactivity Timeout). Bien que je fournisse un exemple fonctionnel (qui fonctionne actuellement en production pour l'un de nos clients), cet article est plutôt un guide pour votre propre mise en œuvre dynamique des délais d'inactivité, donc ne considérez pas la solution proposée comme la seule alternative.

Idée

Le moteur d'interopérabilité maintient une globale spéciale HostMonitor, qui contient chaque Business Host sous forme d'indice, et l'horodatage de la dernière activité sous forme de valeur. Au lieu d'utiliser le délai d'inactivité, nous allons surveiller nous-mêmes cette globale et générer des alertes en fonction de l'état de HostMonitor. HostMonitor est maintenue que soit la valeur du délai d'inactivité définie - elle est toujours activée.

Mise en œuvre

Pour commencer, voyons comment nous pouvons itérer la globale HostMonitor :

Set tHost=""
For {
Set tHost=$$$OrderHostMonitor(tHost)
Quit:""=tHost
Set lastActivity = $$$GetHostMonitor(tHost,$$$eMonitorLastActivity)
}

Pour créer notre Monitor Service, il nous faut effectuer les vérifications suivantes pour chaque Business Host :

1. Décidez si le Business Host est concerné par notre configuration dynamique des délais d'inactivité (par exemple, les interfaces hl7 à fort trafic peuvent fonctionner avec le délai d'inactivité habituel).
2. Si le Business Host se trouve dans le champ d'action, nous devons calculer le temps écoulé depuis la dernière activité.
3. En fonction du temps d'inactivité et d'un certain nombre de conditions (heure du jour/de la nuit, jour de la semaine), nous devons décider si nous voulons envoyer une alerte.
4. Si nous voulons envoyer un enregistrement d'alerte, nous devons enregistrer l'heure de la Dernière activité (Last Activity) afin de ne pas envoyer la même alerte deux fois.

Notre code se présente comme suit :

Set tHost=""
For { 
  Set tHost=$$$OrderHostMonitor(tHost) 
  Quit:""=tHost
  Continue:'..InScope(tHost)
  Set lastActivity = $$$GetHostMonitor(tHost,$$$eMonitorLastActivity)
  Set tDiff = $$$timeDiff($$$timeUTC, lastActivity)
  Set tTimeout = ..GetTimeout(tDayTimeout)
  If (tDiff > tTimeout) && ((lastActivityReported="") || ($system.SQL.DATEDIFF("s",lastActivityReported,lastActivity)>0)) {
    Set tText = $$$FormatText("InactivityTimeoutAlert: Inactivity timeout of '%1' seconds exceeded for host '%2'", +$fn(tDiff,,0), tHost)
    Do ..SendAlert(##class(Ens.AlertRequest).%New($LB(tHost, tText)))
    Set $$$EnsJobLocal("LastActivity", tHost) = lastActivity
  } 
}

Vous devez implémenter les méthodes InScope et GetTimeout contenant votre logique personnalisée, et vous êtes prêt à démarrer.
Dans mon exemple, il y a des délais de jour (Day Timeouts, qui peuvent être différents pour chaque Business Host, mais avec une valeur par défaut) et des délais de nuit (Night Timeouts, qui sont les mêmes pour tous les Business Hosts enregistrés), de sorte que l'utilisateur doit fournir les paramètres suivants :

• Champs d'application : Liste des noms (ou parties de noms) de Business Host associés à leur valeur DayTimeout personnalisée, une par ligne. Seuls les Business Hosts qui se trouve dans le champ d'action (qui remplissent la condition $find(host, scope) pour au moins un champ d'action) seront suivis. Laisser ce champ vide pour surveiller tous les Business Hosts. Exemple: OperationA=120
• DayStart : Nombre de secondes depuis 00:00:00, point de départ d'une journée. Il doit être inférieur à DayEnd. Par exemple, 06:00:00 AM est 6*3600 = 21600
• DayEnd: Nombre de secondes depuis 00:00:00, point de fin d'une journée. Il doit être supérieur à DayStart. Par exemple 08:00:00 du soir est (12+8)*3600 = 72000
• DayTimeout : Valeur du délai d'attente par défaut en secondes pour le déclenchement d'alertes pendant la journée.
• NightTimeout : Valeur du délai d'attente par défaut en secondes pour le déclenchement d'alertes pendant la nuit.
• WeekendDays: Jours de la semaine considérés comme week-end. Séparés par des virgules. Pour le week-end, NightTimeout s'applique 24 heures par jour. Exemple : 1,7 Vérifiez la valeur DayOfWeek de la date en exécutant : $SYSTEM.SQL.Functions.DAYOFWEEK(date-expression). Par défaut, les valeurs renvoyées représentent les jours suivants : 1 - dimanche, 2 - lundi, 3 - mardi, 4 - mercredi, 5 - jeudi, 6 - vendredi, 7 - samedi.

Voici le code complet, mais je ne pense pas qu'il y ait quelque chose d'intéressant là-dedans. Il implémente simplement les méthodes InScope et GetTimeout. Vous pouvez utiliser d'autres critères et adapter les méthodes InScope et GetTimeout si nécessaire.

Problèmes

Il y a deux problèmes à aborder:

• Pas d'icône jaune pour les Business Hosts inactifs (puisque la valeur du paramètre InactivityTimeout de l'hôte est nulle).
• Paramètres hors hôte - les développeurs doivent se rappeler de mettre à jour ce service de surveillance personnalisé chaque fois qu'ils ajoutent un nouvel Business Host et qu'ils souhaitent utiliser une implémentation dynamique de délais d'inactivité.

Alternatives

J'ai exploré toutes ces approches avant de mettre en œuvre la solution ci-dessus :

1. Créer le Business Service qui modifie les paramètres InactivityTimeout lorsque le jour ou la nuit commence. Au départ, j'ai essayé de suivre cette voie mais j'ai rencontré un certain nombre de problèmes, principalement l'obligation de redémarrer tous les Business Hosts concernés à chaque fois que nous modifions le paramètre InactivityTimeout.
2. Ajouter de règles dans le processeur d'alertes personnalisé (Custom Alert Processor) qui, au lieu d'envoyer l'alerte, la suppriment si c'est le délai nocturne InactivityTimeout. Mais une alerte d'inactivité provenant de Ens.MonitorServoce met à jour la valeur LastActivity, donc je ne vois pas de moyen, à partir d'un Custom Alert Processor, d'obtenir un "vrai" horodatage de dernière activité (à part interroger Ens.MessageHeader, je suppose ?). Et si c'est " nuit " - retourner l'état de l'hôte à OK, si ce n'est pas encore " InactivityTimeout " nocturne, et supprimer l'alerte.
3. L'extension de Ens.MonitorService ne semble pas possible sauf pour le callback OnMonitor, mais cela sert un autre but.

Conclusion

Toujours configurer [alerte] https://docs.intersystems.com/iris20233/csp/docbook/Doc.View.cls?KEY=ECO...) pour toutes vos productions d'interopérabilité afin de recevoir des alertes sur les erreurs et l'état de la production dans son ensemble. Si une configuration statique de délai d'inactivité n'est pas suffisante, vous pouvez facilement créer une implémentation dynamique.

Liens

• Inactivity Timeout
• Alerting
• Sample code