Zum Konfigurieren zeitplanbasierter Bereitstellungsaufgaben benötigen Sie Zugriff auf die Registerkarte „Administration/Konnektoren“.

1. Öffnen Sie den Administrationsbereich (ein Zahnradsymbol).

2. Öffnen Sie die Connectors- Ansicht.

3. Wählen Sie Connector für geplante Aufgaben und wählen Sie Neue Aufgabe
   Hinweis! Wenn kein Connector erstellt wird, müssen Sie zuerst „Neuer Connector“ und danach „ Neue Aufgabe“ auswählen.

4. Fahren Sie mit den Connector-spezifischen Anweisungen fort: Native Connectors

Geplante Aufgaben können entweder inkrementell oder vollständig sein.

Einstellungen für geplante Aufgaben:

Der inkrementelle Typ wird nur für Microsoft Active Directory , LDAP- und Microsoft Graph API Konnektoren (früher bekannt als Entra ID ) unterstützt.

Inkrementeller Typ bedeutet, dass Native Connectors (EPE) Daten vom Quellsystem abruft und dabei geänderte Zeitstempelinformationen verwendet. Es werden also nur Daten abgerufen, die nach der vorherigen Ausführung der inkrementellen Aufgabe geändert oder hinzugefügt wurden.

Beim ersten Ausführen einer inkrementellen Aufgabe wird ein vollständiger Abruf durchgeführt (und der aktuelle Zeitstempel in der EPE-Datenbank markiert). Anschließend verwendet die Aufgabe diesen Zeitstempel, um die Datenquelle nach Daten zu fragen, die sich seit diesem Zeitstempel geändert haben (und EPE aktualisiert den Zeitstempel in der EPE-Datenbank für den nächsten Aufgabenlauf). Das Leeren des Aufgabencaches hat keinen Einfluss auf diesen Zeitstempel, daher ist die inkrementelle Aufgabe nach dem ersten Ausführen immer inkrementell.

Der vollständige Typ wird für alle Konnektoren unterstützt.

Der vollständige Typimport ruft bei jedem Durchlauf immer alle Daten (für deren Abruf er konfiguriert ist) vom Quellsystem ab.

Sowohl vollständige als auch inkrementelle Aufgaben verwenden auch den Aufgabencache in EPE, wodurch bestimmte Importe für M42 System schneller und einfacher werden.

Standardmäßig wird der Task-Cache um Mitternacht (UTC) geleert. Nach dem Leeren des Caches wird der nächste Import ohne Zwischenspeicherung ausgeführt, um zu entscheiden, ob die abgerufenen Daten an ESM gesendet werden sollen. Alle abgerufenen Daten werden an ESM gesendet. Danach wird der nächste Task ausgeführt, bis der Cache erneut geleert wird. Dabei wird der EPE-Cache verwendet, um zu bestimmen, ob die abgerufenen Daten an ESM gesendet werden sollen oder nicht.

Sie können konfigurieren, zu welcher Tageszeit der Task-Cache geleert wird, indem Sie die globalen Einstellungen in der EPE-Datapump-Konfiguration ändern:

/opt/epe/datapump-itsm/config/ benutzerdefinierte .properties

Dies ist standardmäßig auf clearCacheHours24HourFormat=0 eingestellt.

Sie können den Cache auch mehrmals täglich leeren, aber das muss sorgfältig überlegt werden, da es Auswirkungen auf die Gesamtleistung hat, da EPE Änderungen an ESM weitergibt, die wahrscheinlich bereits vorhanden sind, Beispiel (fügen Sie dem Attributwert keine Leerzeichen hinzu): clearCacheHours24HourFormat=6,12

Starten Sie den EPE-Datapump-Container nach der Änderung dieses Werts neu, um die Änderung zu übernehmen.

Empfehlungen:

Standardmäßig ist immer der vollständige Typ der geplanten Aufgabe verfügbar.

Wenn Sie Änderungen an Daten, die bereits durch die vollständige Aufgabe abgerufen wurden, häufiger abrufen möchten, als Sie die vollständige Aufgabe ausführen können, fügen Sie auch eine inkrementelle Aufgabe hinzu. Normalerweise ist eine inkrementelle Aufgabe nicht erforderlich.

Die empfohlene Planungssequenz hängt davon ab, wie viele Daten aus dem System/Verzeichnis des Kunden in die Matrix42 Core , Pro oder IGA Lösung gelesen werden und ob der Import inkrementell oder vollständig erfolgt.

Beispiele für die Terminplanung,

Bitte beachten Sie, dass bei gleichzeitiger Ausführung mehrerer Aufgaben möglicherweise mehr EPE-Worker benötigt werden. Die Aufgaben sollten zu unterschiedlichen Zeiten geplant und gemäß der obigen Tabelle abgeschlossen werden. Laufen jedoch mehr als sechs Aufgaben gleichzeitig, sollte die Anzahl der EPE-Worker erhöht werden. Es empfiehlt sich, Aufgaben möglichst nicht gleichzeitig auszuführen.

Empfehlungen zur Leistung
Wenn die Menge der zu importierenden Daten über 10.000 liegt, beachten Sie Folgendes:
Passen Sie die Protokollebene von ESM und DATAPUMP auf die ERROR-Ebene an, um den Protokollierungsumfang während der Taskausführung zu verringern
Sorgen Sie dafür, dass möglichst wenige Automatisierungen sofort für importierte Datenkarten (Listener, Handler, Workflows) gestartet werden, da diese dazu führen, dass ESM mehr Zeit für die Verarbeitung neuer Datenkarten benötigt.

Mit dieser Funktion können Sie den Status von Konten und Berechtigungen beispielsweise als „Gelöscht“ oder „Deaktiviert“ markieren, wenn das Konto oder die Berechtigung aus dem Quellsystem entfernt wird. Ab Version 2025.3 können Sie den Status auch für generische Objekte festlegen (nicht nur für Konten/Identitäten und Berechtigungen/Gruppen).

Für Version 2025.3 und neuer

In Version 2025.3 wurden diese Einstellungen aus den Eigenschaftendateien in die Task-Benutzeroberfläche verschoben. Außerdem können Sie diese Einstellungen jetzt für generische Objekte festlegen, was vor dieser Version nicht möglich war.

Für jede geplante Aufgabe und für alle Zuordnungstypen gibt es eine separate Konfiguration. Hier ist ein Beispiel für diese Konfiguration für die Aufgabe:

Für Version 2025.2 und älter

Diese Funktion ist für geplante Aufgaben des Typs „vollständig“ verfügbar.

Die Einstellungen befinden sich in der Konfigurationsdatei des Datapump-Dockers. Um diese Parameterwerte zu ändern, müssen Sie sie in der Datei /opt/epe/datapump-itsm/config/custom.properties festlegen.

Konfiguration

Um die Deaktivierungsfunktion zu aktivieren, müssen in der Datapump-Konfiguration die folgenden Parameter auf „true“ gesetzt sein:

disable.unknown. esm .users=true
disable.unknown. esm .groups=true

Diese beiden Parameter sind in den Versionen 2024.2 und 2025.1 standardmäßig „false“. In 2025.2 und neueren Versionen sind sie standardmäßig „true“.

Als nächstes folgen diese Parameter:

personTemplateStatusCodeAttributeKey=accountStatus
personTemplateStatusAttributeDisabledValueKey=Deleted
groupTemplateStatusCodeAttributeKey=status
groupTemplateStatusAttributeDisabledValueKey=5 - Removed

Die ersten beiden Attribute sollten auf das Attribut „DatacardHiddenState“ in der Benutzervorlage verweisen und angeben, welcher Wert dorthin gesendet werden soll, wenn der Benutzer gelöscht wird.

Standardmäßig sind es accountStatus und „Value 5 - Removed in IGA Account .

All dies muss mit der Attributkonfiguration übereinstimmen:

Öffnen Sie 1.PNG

Dasselbe gilt für die nächsten beiden Parameter, allerdings für Gruppen.‘

Wenn Sie diese Parameter in der Eigenschaftendatei ändern müssen, nehmen Sie die Änderungen im Datapump-Container in der Datei vor: /opt/ epe /datapump-itsm/config/ custom .properties. Diese Änderungen bleiben dann beim Neustart des Containers erhalten und werden beim Neustart nach /opt/ epe /datapump-itsm/config/application.properties kopiert.

Beschreibung

Aufgaben speichern ihre __taskid__ die als Task Id mapping in der Benutzeroberfläche angezeigt wird, zu den Datenkarten. Sie wird dann verwendet, um festzustellen, ob die Datenkarte von dieser Aufgabe hinzugefügt wurde. Falls es mehrere Aufgaben mit unterschiedlichen Benutzergruppen gibt.

Dieses Feld wurde zuvor als Datenquellen-ID verwendet, aber da wir zu dem Modell gewechselt sind, bei dem der Connector mehrere Aufgaben haben kann, kann seine Kennung nicht mehr verwendet werden. Deshalb wurde das Feld stattdessen als Task-ID umfunktioniert.

Nehmen wir Benutzer als Beispiel: Wenn eine Aufgabe ausgeführt wird, wird ESM nach der Liste der Benutzer gefragt, deren Task-ID im Feld Task Id mapping steht und die keinen personTemplateStatusAttributeDisabledValueKey -Wert im personTemplateStatusCodeAttributeKey haben.

Dieses Ergebnis wird dann mit dem verglichen, was die Aufgabe abgerufen hat, und bei den Datenkarten der Benutzer, die nicht abgerufen wurden, wird das Attribut personTemplateStatus auf den in der Konfiguration angegebenen Wert gesetzt – 5 - Removed .

Das folgende Beispielprotokoll zeigt den beschriebenen Vorgang und informiert darüber, dass ein Benutzer entfernt wurde.

Öffnen Sie 2.PNG

Dasselbe gilt für Gruppen, aber stattdessen werden groupTemplateStatus Attribute verwendet.

Hinweise

• Die Funktion funktioniert nur mit geplanten Aufgaben zum vollständigen Abrufen.
• Noch keine Unterstützung für generische Vorlagen, nur Identität und Zugriff
• Bei der Migration von früheren Versionen, in denen noch die Datenquellen-ID verwendet wurde, muss sie mindestens einmal ausgeführt werden, um zuerst die Task-IDs in den Datenkarten festzulegen.
• EPE identifiziert deaktivierte Benutzer oder Gruppen als diejenigen, die aus dem AD entfernt wurden. Derzeit unterstützen wir keine Statusangaben dazu, ob die Entität aktiv ist oder nicht.
• EPE aktiviert Benutzer nicht selbstständig.
• Wenn mehrere Tasks dieselben Benutzer oder Gruppen abrufen, kann die Task-ID in der Datenkarte überschrieben werden, je nachdem, welcher Task zuletzt ausgeführt wurde. Es wird vermutet, dass viele Tasks vom Typ „vollständig“ nicht denselben Benutzer oder dieselbe Gruppe abrufen.
• Nehmen Sie Änderungen an der Konfigurationsdatei immer an benutzerdefinierten Eigenschaften vor. Ändern Sie nicht nur die Anwendungseigenschaften, da diese Änderungen beim Neustart des Containers verloren gehen, wenn Sie nicht dieselben Änderungen an benutzerdefinierten Eigenschaften vorgenommen haben.