Ersteller-Framework für ausgehende Benachrichtigungen verwenden

  • Freigeben Version: Xanadu
  • Aktualisiert 1. August 2024
  • 2 Minuten Lesedauer

    • Das Ersteller-Framework wählt das Ereignis aus der Instanz ServiceNow aus und sendet die ausgehende Benachrichtigung an das externe System. Sie können die Benachrichtigungsdetails aus dem Messaging-Service abrufen, der in Ihrem externen System installiert ist.

    Systemeigenschaften

    Sie müssen die Systemeigenschaften so konfigurieren, dass das Ersteller-Framework für ausgehende Benachrichtigungen verwendet wird. Die folgende Tabelle erläutert die Liste der Systemeigenschaften, die für die geplanten Aufgabenfestgelegt sind.

    Tabelle : 1. Systemeigenschaften des Ersteller-Frameworks
    Eigenschaft Beschreibung Typ
    sn_api_notif_mgmt.event.log
    Protokollierungsebene, die in die Debug-Protokolle geschrieben werden soll. Sie können die folgenden Protokollierungsebenen auswählen:
    • emerg: Totaler Fehler.
    • Warnung: Beispiel: Systembeschädigung einer Datenbank.
    • kritischer Wert: Wird normalerweise für Hardwarefehler verwendet, z. B..
    • err: Beliebige Fehler.
    • Warnung: Beliebige Warnungen
    • Hinweis: Mögliche Aktion erforderlich, aber nicht unbedingt.
    • Info: Keine Aktion erforderlich.
    • debug: Wird im Allgemeinen nicht verwendet, außer um alle Daten für die Fehlersuche zu erfassen.

    Standardwert: err

    		 Zeichenfolge
    sn_api_notif_mgmt.publisher_message_bus_configuration Definiert, ob Nachrichten mit dem Hermes Messaging Service, dem Open Message Bus oder beiden Nachrichtenbussen veröffentlicht werden. Sie können die folgenden Werte verwenden:
    • openMessageBus
    • Hermes
    • both

    Standardwert: openMessageBus

    		 Zeichenfolge
    sn_api_notif_mgmt.inboundqueue.maxrecords Maximale Anzahl von Datensätzen, die der Planer für eine Ausführung des Planers aus der eingehenden Warteschlange abruft. Dieser Wert wird in Verbindung mit dem Parameter sn_api_notif_mgmt.inboundqueue.batch.limit verwendet.
    • Standardwert: 200
    • Andere mögliche Werte: nach Bedarf

    Wenn beispielsweise das Batch-Limit auf 50 und die Max-Datensätze auf 200 festgelegt sind und die Anzahl der Datensätze in der eingehenden Warteschlange 130 beträgt, ruft der Scheduler drei verschiedene Batches von Datensätzen in einem einzigen Durchlauf ab. zwei mit 50 Datensätzen und einer mit 30 Datensätzen. Wenn die Anzahl der Datensätze in der eingehenden Warteschlange 220 beträgt, ruft der Planer vier Batches mit je 50 Datensätzen ab, und die verbleibenden 20 Datensätze werden erst bei der nächsten Ausführung des Planers verarbeitet.

    Wenn Sie diesen Wert festlegen, müssen Sie auch die Zeit berücksichtigen, die der Planer benötigt, um mehrere Batches zu verarbeiten, und den Wert sn_api_notif_mgmt.schedule.max.runtime entsprechend festlegen.

    		 Ganzzahl
    sn_api_notif_mgmt.inboundqueue.batch.limit Anzahl der Datensätze, die der Planer in einem Batch aus der eingehenden Warteschlange abruft und verarbeitet.
    • Standardwert: 200
    • Andere mögliche Werte: nach Bedarf
    		 Ganzzahl
    sn_api_notif_mgmt.glide.mutex.script.maxspins Maximale Anzahl der Versuche, eine Mutex-Sperre in eingehenden Warteschlangendatensätzen abzurufen.
    • Typ: Ganzzahl
    • Standardwert: 100
    • Andere mögliche Werte: nach Bedarf
    		 Ganzzahl
    sn_api_notif_mgmt.zeitplan.max.laufzeit Die maximale Zeit in Millisekunden, die die geplante Aufgabe ausgeführt werden kann, bevor sie fehlschlägt und einen Fehler meldet.
    • Typ: Ganzzahl
    • Standardwert: 90.000
    • Andere mögliche Werte: nach Bedarf
    		 Ganzzahl
    sn_api_notif_mgmt.glide.mutex.script.spinwait Maximale Wartezeit in Millisekunden zwischen Versuchen, eine Mutex-Sperre für die Datensätze in der eingehenden Warteschlange abzurufen.
    • Typ: Ganzzahl
    • Standardwert: 100
    • Andere mögliche Werte: nach Bedarf
    		 Ganzzahl

    Ersteller-Framework-Workflow

    Wenn das System ein Ereignis in die Bereitstellungstabelle verschiebt, werden die folgenden Schritte als als Teil des Ersteller-Framework-Mechanismus ausgeführt:
    1. Der Scheduler wählt in einem vorkonfigurierten Intervall eine Reihe von Datensätzen aus und sendet dann Glide-Snapshots an den Ereignisprozessor.
    2. Das System konvertiert den Glide-Snapshot basierend auf dem Ereignistyp in eine TMF 688-Beschwerdeereignisnutzlast.

      Weitere Informationen zu den Methoden zum Definieren und Generieren der TMF-konformen Nutzlasten für Problemticket-Ereignisse finden Sie unter TopicAPIUtilsOOB - Scoped.

    3. Das System prüft, ob die Benachrichtigungskonfiguration für Hermes Kafka oder den offenen Nachrichtenbus vorgesehen ist.

      Weitere Informationen zum Konfigurieren des Frameworks für Benachrichtigungen über Ersteller-Ereignisse finden Sie unter Producer Event Notification Framework developer guide.