Un sujet qui revient fréquemment lorsque notre plateforme K2 grossit, c’est une façon simple de monitorer son environnement sans avoir à se connecter sur le workspace et vérifier si des instances sont en erreur ou si tout va bien (oui oui, ça arrive !)

Pour mettre en place ce genre de mécanisme, il faut utiliser le

qui permet de lister les erreurs sur la plateforme K2, et de faire un retry sur ces erreurs détectées.

Pour monitorer les erreurs, 2 solutions s’offrent à nous :

• Monitoring via un écran
• Monitoring via un processus

Monitoring via un écran

Ce type de monitoring consiste à bénéficier d’un formulaire qui liste les erreurs.
Avantage : plus rapide d’accès que le workspace
Inconvénient : Nécessite d’aller le consulter régulièrement

Dans un premier temps, on va générer un SmartObject qui utilise les 2 méthodes suivantes :

 

La méthode Get errors prends en paramètre le nom de la page d’erreur a afficher. Par défaut, passer “All” qui liste toutes les erreurs présente sur le serveur K2. D’autres pages d’erreur peuvent être ajoutées dans le workspace, section Error profiles .La seconde méthode retry error permet de lancer un retry sur l’erreur pour lequel on a passé l’ID en paramètre.

Une fois le SmartObject généré, il faut générer une vue de type liste qui utilise la méthode

.

On ajoutera a cette vue un toolbar button

qui va exécuter la méthode

en passant l’id de l’erreur sélectionnée ainsi que le nom de la personne connectée:

 

Voici le résultat final :

Monitoring via un processus

Cette solution consiste à modéliser un processus K2, qui va être lancé de façon périodique (voir article sur le déclenchement périodique de processus), qui va aller consulter les erreurs de l’environnement courrant, générer un tableau HTML avec les erreurs récupérées et envoyer ce tableau par mail aux utilisateurs paramétrés en tant que destinataires.

Le SmartObject utilisé sera le même que pour la première solution. On passera ensuite par un processus composé qui va vérifier si il y a des erreurs présentes sur le serveur, si il n’y a pas d’erreur, le processus ne fait rien, si des erreurs sont présente, on va générer le tableau HTML (activité generate table qui boucle sur la liste des erreurs) et envoyer ce tableau HTML dans un mail.

On va aussi générer un lien qui sera inséré dans le mail qui nous amènera vers un formulaire pour faire un retry automatiquement depuis le mail.

On peut voir dans le processus qu’une boucle est en place autour de l’activité generateTable, et que 2 sorties sont conditionnées :

• Si curIndex < nbErrors :  il reste des erreurs à traiter
• Si curIndex = nbErrors : on a traité toutes les erreurs, on peux envoyer le mail

 

	On va initialiser le datafield nbErrors avec la fonction count sur la méthode Get errors de notre SmartObject ainsi que le datafield curIndex à 0 .
	Dans le 2ème événement, on va initialiser le datafield htmlTable (de type texte) avec l’entête du tableau HTML.
	Dans l’activité generateTable , le premier événement consiste à générer un lien vers un formulaire, qui prend en paramètre l’ID de l’erreur et qui tente un retry lors de la règle Initialize du formulaire. (la méthode est la même que celle développée pour le toolbar button de la solution 1).
	L’événement ConcatValues va concaténer les données de la ligne courante avec les valeurs du datafield htmlTable. Exemple de récupération de données (Folio) :
	Dernier événement de l’activité generateTable , l’incrémentation de la variable curIndex
	Pour terminer, on envoie le tableau généré dans le datafield htmlTable dans un mail event, pour lequel on aura le choix des destinataires du mail.

 

A vous de jouer  😉