Utilisation des workflows pour les actions d'alerte

Il est possible d'exécuter des workflows en tant qu'alertes. Pour permettre à un workflow de faire office d'action d'alerte, son action alert doit être définie sur true.

Lorsqu'ils sont exécutés en tant qu'actions d'alerte, les workflows prennent l'identité de l'utilisateur qui les a créés. C'est pourquoi le paramètresetid de tout workflow devant pouvoir être utilisé comme action d'alerte doit être défini sur true. Les actions d'alerte ont un paramètre d'objet unique possédant les membres suivants :

Table 132  Membres obligatoires du contexte d'exécution des alertes

Membre obligatoire Type Description class String Classe de l'alerte. code String Code de l'alerte. items Objet Objet décrivant l'alerte. timestamp Date Heure de l'alerte.

Le membre items de l'objet de paramètre possède les membres suivants :

Table 133  Membres obligatoires du membre items

Membre obligatoire Type Description url String URL de la page Web décrivant l'alerte action String Action devant être entreprise par l'utilisateur en réponse à l'alerte. impact String Impact de l'événement qui a déclenché l'alerte. description String Chaîne lisible à l'oeil décrivant l'alerte. severity String Gravité de l'événement qui a déclenché l'alerte.

Les workflows exécutant les actions d'alerte peuvent utiliser la fonction audit pour générer des entrées de journal. Il est recommandé d'utiliser la fonction audit pour ajouter toute information de débogage pertinente au journal d'audit. Le workflow suivant par exemple exécute un basculement lorsqu'il est en état clustérisé, mais audite tout échec de réinitialisation :

Exemple 27  Audit d'un échec de réinitialisation par un workflow

Le workflow suivant par exemple exécute un basculement lorsqu'il est en état clustérisé, mais audite tout échec de réinitialisation :

var workflow = {
       name: 'Failover',
       description: 'Fail the node over to its clustered peer',
       alert: true,
       setid: true,
       execute: function (params) {
               /*
                * To failover, we first confirm that clustering is configured
                * and that we are in the clustered state.  We then reboot,
                * which will force our peer to takeover.  Note that we're
                * being very conservative by only rebooting if in the
                * AKCS_CLUSTERED state:  there are other states in which it
                * may well be valid to failback (e.g., we are in AKCS_OWNER,
                * and our peer is AKCS_STRIPPED), but those states may also
                * indicate aberrent operation, and we therefore refuse to
                * failback.  (Even in an active/passive clustered config, a
                * FAILBACK should always be performed to transition the
                * cluster peers from OWNER/STRIPPED to CLUSTERED/CLUSTERED.)
                */
               var uuid = params.uuid;
               var clustered = 'AKCS_CLUSTERED';

               audit('attempting failover in response to alert ' + uuid);

               try {
                       run('configuration cluster');
               } catch (err) {
                       audit('could not get clustered state; aborting');
                       return;
               }

               if ((state = get('state')) != clustered) {
                       audit('state is ' + state + '; aborting');
                       return;
               }

               if ((state = get('peer_state')) != clustered) {
                       audit('peer state is ' + state + '; aborting');
                       return;
               }

               run('cd /');
               run('confirm maintenance system reboot');
       }
};