Utilisation du cadre de travail du producteur pour les notifications sortantes

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 3 minutes de lecture
  • Le cadre de travail du producteur sélectionne l’événement dans l’instance ServiceNow et envoie la notification sortante au système externe. Vous pouvez consommer les détails de la notification à partir du service de messagerie installé dans votre système externe.

    Propriétés système

    Vous devez configurer les propriétés système pour utiliser le cadre de travail du producteur pour les notifications sortantes. Le tableau suivant explique la liste des propriétés système définies pour les tâches planifiées.

    Tableau 1. Propriétés système du cadre de travail du producteur
    Propriété Description Type
    sn_api_notif_mgmt.event.log
    Niveau de journalisation à écrire dans les journaux de débogage. Vous pouvez sélectionner les niveaux de journalisation suivants :
    • emerg : Échec total.
    • alerte : corruption du système d’une base de données, par exemple.
    • crit : généralement utilisé pour les erreurs matérielles, par exemple.
    • err : il y a des erreurs.
    • warning : tous avertissements
    • avis : Action possible requise mais pas essentielle.
    • Informations : aucune action n’est requise.
    • debug : généralement non utilisé, sauf pour capturer tout ce qui est utilisé pour le diagnostic de pannes.

    Valeur par défaut : err

    Chaîne
    sn_api_notif_mgmt.publisher_message_bus_configuration Définit si les messages sont publiés à l’aide du service de messagerie Hermes, du bus de messages ouvert ou des deux bus de messages. Vous pouvez utiliser les valeurs suivantes :
    • openMessageBus (en anglais seulement)
    • Hermes
    • les deux

    Valeur par défaut : openMessageBus

    Chaîne
    sn_api_notif_mgmt.inboundqueue.maxrecords Nombre maximal d’enregistrements que le planificateur extrait de la file d’attente entrante pour une exécution du planificateur. Cette valeur est utilisée conjointement avec le sn_api_notif_mgmt.inboundqueue.batch.limit paramètre.
    • Valeur par défaut : 200
    • Autres valeurs possibles : selon les besoins

    Par exemple, si la limite de lots est définie sur 50 et que maxrecords est défini sur 200, et si le nombre d’enregistrements dans la file d’attente entrante est de 130, le planificateur extrait trois lots d’enregistrements différents en une seule exécution ; deux avec 50 enregistrements et un avec 30 enregistrements. Si le nombre d’enregistrements dans la file d’attente entrante est de 220, le planificateur extrait quatre lots de 50 enregistrements et les 20 enregistrements restants ne sont pas traités avant la prochaine exécution du planificateur.

    Lors de la définition de cette valeur, vous devez également tenir compte du temps nécessaire au planificateur pour traiter plusieurs lots et définir la valeur sn_api_notif_mgmt.schedule.max.runtime en conséquence.

    Entier
    sn_api_notif_mgmt.inboundqueue.batch.limit Nombre d’enregistrements que le planificateur extrait et traite de la file d’attente entrante en un seul lot.
    • Valeur par défaut : 200
    • Autres valeurs possibles : selon les besoins
    Entier
    sn_api_notif_mgmt.glide.mutex.script.maxspins Nombre maximal de tentatives d’acquisition d’un verrou mutex dans les enregistrements de file d’attente entrante.
    • Type : nombre entier
    • Valeur par défaut : 100
    • Autres valeurs possibles : selon les besoins
    Entier
    sn_api_notif_mgmt.schedule.max.exécution Durée maximale, en millisecondes, pendant laquelle la tâche planifiée peut s’exécuter avant qu’elle n’échoue et ne signale une erreur.
    • Type : nombre entier
    • Valeur par défaut : 90 000
    • Autres valeurs possibles : selon les besoins
    Entier
    sn_api_notif_mgmt.glide.mutex.script.spinwait Temps d’attente maximal, en millisecondes, entre les tentatives d’acquisition d’un verrou mutex sur les enregistrements de la file d’attente entrante.
    • Type : nombre entier
    • Valeur par défaut : 100
    • Autres valeurs possibles : selon les besoins
    Entier

    Workflow du cadre de travail du producteur

    Lorsque le système envoie un événement à la table intermédiaire, les étapes suivantes ont lieu dans le cadre du mécanisme de cadre de travail du producteur :
    1. Le planificateur sélectionne un certain nombre d’enregistrements à un intervalle préconfiguré, puis envoie des instantanés Glide au processeur d’événements.
    2. Le système convertit l’instantané Glide en charge utile d’événement de réclamation TMF 688 en fonction du type d’événement.

      Pour en savoir plus sur les méthodes utilisées pour définir et générer les charges utiles conformes à TMF pour les événements de ticket d’incident, reportez-vous à TopicAPIUtilsOOB - Scoped.

    3. Le système vérifie si la configuration de notification est destinée à Hermes Kafka ou au bus de messages ouvert.

      Pour en savoir plus sur la configuration du cadre de travail de notification d’événements du producteur, reportez-vous à Producer Event Notification Framework developer guide.