ESM-Listener-Lebenszyklus

+ More

Überblick

Der Lebenszyklus eines Listeners besteht aus drei oder vier Phasen, je nachdem, ob es sich um einen Listener vor oder nach dem Speichern handelt:

Datenkartenspeicherung : Der Listener wird während der Speicherung einer Datenkarte ausgelöst.
Quellbedingungen prüfen : Quellbedingungen werden geprüft.
Zielbedingungen prüfen (nur Post-Save-Listener) : Die Gruppe der Zieldatenkarten wird basierend auf den Zielbedingungen definiert. Diese Phase findet nur statt, wenn der Listener ein Post-Save-Listener ist.
Aktionen ausführen : Eine oder mehrere Aktionen werden auf der Zieldatenkarte ausgeführt.
1. Im Fall des Pre-Save-Listeners ist die Zieldatenkarte die sogenannte „Quelldatenkarte“, die den Listener „hostet“.

Datenkarte speichern

Der Listener wird beim Speichern einer Datenkarte ausgelöst.

Auslösen von Listenern

Ausführungsreihenfolge von Handlern und Listenern

Listener, Handler und visuelle Workflow-Automatisierung

Workflow-Aktionen werden nicht als letzter Listener vor dem Speichern ausgeführt. Sie beginnen mit dem ersten Workflow-Knoten (oder dem zuletzt verarbeiteten Knoten) und verarbeiten in einer einzigen Ausführung mehrere Knoten, bis sie einen Knoten (z. B. einen Timer oder eine Genehmigung) erreichen, der eine Weiterführung nicht zulässt.
- Die __Initialisierung__ der visuellen Workflow-Automatisierung erfolgt am Ende des vor dem Speichern liegenden Teils des Speicherzyklus.
- Die visuelle Workflow-Automatisierung Pro erfolgt am Ende des Post-Save-Teils des Speicherzyklus.

Überprüfen der Quellbedingungen

Jeder Listener verfügt über Quellbedingungen, die beschreiben, wann der Listener auf das Ereignis reagieren soll. Die Bedingung könnte beispielsweise wie folgt lauten:

(attribute "state" old value!= attribute "state" new value) && (attribute "state" new value == "closed")

Bedingungen können mit „und“- und „oder“-Operatoren und sogar verschachtelten Operatoren viel komplizierter sein. Wenn die Quelldatenkarte den Bedingungen entspricht, wird die Ausführung fortgesetzt.

Vorab-Speichern-Listener

Post-Save-Listener

UND-Beispiel

ODER Beispiel

Kombinierter SC

Implementierte Quellbedingungen

Name	Beschreibung
Kombinierte Quellbedingung	Kombiniert Bedingungen (die auch CombinedSourceConditions sein können) mit UND- oder ODER-Operatoren. Im XML ist das äußerste source_conditions-Element selbst eine CombinedSourceCondition.
AlwaysTrueSourceCondition	Immer wahr, d. h. die Datenkarte wird immer mit dieser Bedingung abgeglichen.
EntitySourceCondition	Ist die Datenkarte vor dem Speichern oder nach dem Speichern ausgeblendet (aktueller_Wert): ja oder nein Wird die Datenkarte vor dem Speichern oder nach dem Speichern entfernt (im Papierkorb): ja oder nein
FolderSourceCondition	Befindet sich die Datenkarte in einem bestimmten Ordner oder in einem anderen (Operator !=).
GuiEditSourceCondition	„True“, wenn die Quelldatenkarte über die ESM-Benutzeroberfläche bearbeitet wird.
NewDataCardSourceCondition	Sollen wir eine neue Datenkarte speichern: ja oder nein
Pro	Vergleichen Sie vor oder nach dem Speichern ein Feld in der Datenkarte (Attribut) (aktueller Wert „true“ oder „false“) mit einem anderen Feldwert vor oder nach dem Speichern mithilfe eines Operators. Die unterstützten Operatoren hängen vom Datentyp ab.
Wertquellenbedingung	Vergleichen Sie vor oder nach dem Speichern ein Feld (Attribut) (aktueller Wert true oder false) mit einem konstanten Wert mithilfe eines Operators. Die unterstützten Operatoren hängen vom Datentyp ab. Sie können beispielsweise keine Referenz mit einer Konstanten (wie der ID oder dem Namen einer Datenkarte) vergleichen.
ReferenzPfadWertQuellenbedingung	Vergleichen Sie einen Wert, der in einem Referenzpfad ($code1:code2:code3$) vor oder nach dem Speichern (current_value true oder false) gefunden wurde, mit einem konstanten Wert mithilfe eines Operators. Unterstützte Operatoren hängen vom Datentyp ab.
ReferencePath Pro	Mit dieser Quellbedingung ist es möglich, die Werte zweier Attribute zu vergleichen, von denen eines oder beide referenziert sein können. Das erste kann ein Verweis auf ein lokales (nicht referenziertes) Attribut sein, das andere muss jedoch ein referenziertes Datenkartenattribut sein. Beide Attribute müssen denselben Datentyp haben. Mehrwertige Attribute und Übereinstimmung mit der Bedingung: Wenn alle Werte übereinstimmen müssen, bedeutet dies, dass alle Werte des ersten Attributs mit einigen Werten des zweiten Attributs übereinstimmen müssen. Wenn das erste oder zweite Attribut keinen Wert hat, stimmt die Bedingung nicht überein. Wenn nicht alle Werte übereinstimmen müssen, reicht es aus, dass einer der vielen Werte im ersten Attribut mit einigen der vielen Werte im zweiten Attribut übereinstimmt.

Weitere Beispiele für Quellbedingungen finden Sie in SourceConditionExamples.xml :

Zielbedingungen prüfen

Zielbedingungen ähneln den Suchbedingungen in der ESM-Benutzeroberfläche. Die Aktionen des Listeners werden auf den Datenkarten ausgeführt, die den Bedingungen entsprechen. Beachten Sie, dass die Quelldatenkarte unter diesen Bedingungen ausgeschlossen werden sollte.

Ein Beispiel für eine Zielbedingung könnte das Folgende sein:

 (template == "ticket") && (reference attribute  "caused by"  target == source data card) &&  (attribute "state" value ==  "open")

Notiz:

Wenn während der Ausführung eines Listeners eine mögliche Endlosschleife erkannt wird → wird die Listener-Ausführung beendet und ein Fehler angezeigt.

Wenn beispielsweise Listener A Datenkarte B ändert, löst dies Listener B aus und Listener B ändert Datenkarte A.

Implementierte Zielbedingungen

Name	Beschreibung
Kombinierte Zielbedingung	Kombiniert mehrere Bedingungen (die auch selbst CombinedTargetConditions sein können) mit den Operatoren AND oder OR zu einer einzigen.
WertZielbedingung Nach Wert Mit Quellenangabe Durch Verweis aus der Quelle	Vergleicht einen Attributwert aus der Datenkarte mit einer Konstanten mithilfe eines Operators. Die unterstützten Operatoren hängen vom Datentyp ab. Beispielsweise können Referenzen nicht mit dem Namen oder der ID der Datenkarte verglichen werden. Eine Ausnahme bildet ein Verweis auf die Quelle oder ein Verweis aus der Quelle (konfiguriert mit dem Attributcode).
Pro	Vergleicht den Attributwert einer Datenkarte mit dem Wert eines anderen Attributs mithilfe eines Operators. Die unterstützten Operatoren hängen von den verwendeten Datentypen ab.
Pro	Vergleicht den Attributwert der Zieldatenkarte mit dem Attributwert der Quelldatenkarte mithilfe eines Operators. Die unterstützten Operatoren hängen von den verwendeten Datentypen ab.
EntityTargetCondition	Kann verwendet werden, um zu prüfen, ob die Datenkarte entfernt wurde (im Papierkorb): true oder false Kann verwendet werden, um zu prüfen, ob die Datenkarte ausgeblendet ist: true oder false
Spezielle Zielbedingung	Mit dieser Bedingung können folgende Eigenschaften definiert/überprüft werden: Eine Vorlage, die die Quelldatenkarte darstellt (spezielle Bedingung in der Stammbedingung in XML erforderlich). Befindet sich die Datenkarte in einem bestimmten Ordner (Ordnercode) oder woanders? Ist die Datenkarte dieselbe oder eine andere als die Quelle (wenn sich die Zielbedingungen beispielsweise auf dieselbe Vorlage wie die Quelldatenkarte beziehen, kann die Quelldatenkarte von möglichen Zieldatenkarten ausgeschlossen werden). Verweist die Zieldatenkarte über einen angegebenen Referenzpfad (target_refers_to_source) auf die Quelle? Der Pfad wird mithilfe von Attributcodes wie folgt definiert: template_code1:attribute_code1$template_code2:attribute_code2... Der erste Vorlagencode ist der Code der Zielvorlage und der Attributcode ist ein Code eines solchen Attributs, der sich auf die Datenkarten beziehen kann, die als nächstes im Pfad folgen. Das letzte Paar aus Vorlage und Attributcode wird verwendet, um ein Attribut zu markieren, das sich direkt auf die Quelldatenkarte bezieht.

Beispiele für Zielbedingungen finden Sie in TargetConditionExamples.xml:

Ausführen von Aktionen

Eine oder mehrere Aktionen werden auf der Zieldatenkarte ausgeführt. Im Fall des Pre-Save-Listeners ist die Zieldatenkarte die sogenannte „Quelldatenkarte“, die den Listener „hostet“.

Umgesetzte Maßnahmen

Name	Vorab speichern	Beitrag speichern	Beschreibung
AlwaysFailDataCard (Aktion)	Ja	NEIN	Verhindert das Speichern der Datenkarte.
ChangeDataCardValues	Ja	Ja	Legt einen Wert für ein Feld fest.
Datenkartenwerte kopieren	Ja	Ja	Kopiert einen Wert von der Quelldatenkarte in den Wert eines anderen Attributs oder in den Wert eines Attributs der Zieldatenkarte. Kann auch Werte hinter Referenzen kopieren. Bei mehreren Werten werden vorhandene Werte ERSETZT. Mehrfachwerte funktionieren nur auf der Hostdatenkarte, nicht hinter Referenzen.
KopiereQuellenreferenz	Ja	NEIN	Erstellt einen Verweis von Zieldatenkarten auf Quelldatenkarten.
Datenkarte erstellen	NEIN	Ja	Erstellt eine neue Datenkarte basierend auf der konfigurierten Vorlage und im konfigurierten Ordner. Fügt optional Referenzen zwischen dem Ersteller und den erstellten Datenkarten hinzu und setzt beliebige Attributwerte in der erstellten Karte. In Sonderfällen kann der Zeitpunkt des Bearbeitungsbeginns in der Efecte-GUI hinzugefügt werden.
EntityDataCard	Ja	NEIN	Verschiebt eine Datenkarte in den Papierkorb, stellt sie aus dem Papierkorb wieder her, löscht sie dauerhaft, versteckt sie oder macht sie sichtbar.
Ausdruck (Aktion)	Ja	Ja	Führt ein definiertes Python-Skript auf Zieldatenkarten aus.
OrdnerDatenKarte	Ja	Ja	Verschiebt eine Datenkarte in einen bestimmten Ordner.
SaveDataCard	NEIN	Ja	Speichert die Datenkarte. Dies ermöglicht die Berechnung neuer Werte für Attribute, die einen Handler (ExpressionHandler o.ä.) enthalten.
SaveDataCardXmlToFile	NEIN	Ja	Speichert die Datenkarte im XML-Format in einer angegebenen Datei und einem angegebenen Ordner. Beachten Sie, dass diese Aktion nur für die gespeicherte Quelldatenkarte gilt. Eine vorhandene Datei wird überschrieben (vor dem Schreiben der neuen Datei wird die Datei gelöscht). Die Aktion versucht zunächst, das XML in eine temporäre Datei zu schreiben und benennt diese dann in die angegebene Datei um. Dadurch wird verhindert, dass jemand die Ergebnisdatei liest, bevor sie vollständig geschrieben ist.
SendDataCardXmlToWebService	NEIN	Ja	HINWEIS: Der Name enthält kein „Aktion“. Sendet die Datenkarte im XML-Format an den konfigurierten SOAP-Webdienst. Beachten Sie, dass diese Aktion nur auf der gespeicherten Quelldatenkarte ausgeführt wird.
SendMailAction	NEIN	Ja	Sendet E-Mails.
SendSourceChangedJMSMessage(Aktion)	Ja	Ja	Die Aktion sendet eine JMS-Nachricht an die Warteschlange, wenn die Datenkarte gespeichert wird. Der Inhalt der Nachricht ist die vollständige Datenkarte im Efecte-XML-Format.
Gezieltes SccmUpdate	NEIN	Ja	Löst ein gezieltes SCCM Update aus. Wird nur zusammen mit SccmIntegrationTask verwendet.
TransformDataCard	NEIN	Ja	Die Aktion transformiert die aktuell bearbeitete Datenkarte in eine andere Datenkarte. Verwendet Transformationsregeln und Zielordner, die in den Transformationen im Vorlageneditor definiert sind.
SendDataCardXmlToHttpAction	NEIN	Ja	Sendet die Datenkarte im XML-Format an einen ausgewählten Webdienst. Beachten Sie, dass diese Aktion nur für die gespeicherte Quelldatenkarte gilt.

Beispiele für Zielbedingungen finden Sie in TargetConditionExamples.xml:

ESM-Listener-Lebenszyklus

Serviceverwaltung

Identitätsverwaltung und -administration ( IGA )

Plattform

Versionshinweise für M42 Core & Pro , IGA , Conversational AI

Sonstiges Material

Leistungen

ESM-Listener-Lebenszyklus

Überblick