Umgang mit Batch-Jobs beim Deaktivieren oder Löschen eines Benutzers in D365FO

Ich hatte jemanden, der sich mit mir in Verbindung setzte, um zu erfahren, wie Batch-Jobs beim Deaktivieren oder Löschen eines Benutzers aus D365FO „richtig“ behandelt werden. Schauen wir uns die Optionen an, die Sie haben, um Probleme zu vermeiden.

Warum dies ein Problem ist

Batch-Jobs in D365FO ermöglichen die Ausführung einer Reihe von Anweisungen, die so geplant werden können, dass sie regelmäßig ausgeführt werden. Diese werden häufig verwendet, um Geschäftsberechnungen durchzuführen, und da sie so eingestellt werden können, dass sie zu einer bestimmten Zeit ausgeführt werden, können sie außerhalb der normalen Geschäftszeiten ausgeführt werden, um die Auswirkungen auf das System zu minimieren.

Jeder Batch-Job wird im Kontext eines Benutzers innerhalb des Systems ausgeführt. Wenn dieser Benutzer deaktiviert ist, können die mit diesem Benutzer verknüpften Batch-Jobs nicht ausgeführt werden und schlagen fehl. Wenn ein Benutzer gelöscht wird, werden außerdem alle Batch-Jobs, die mit diesem Benutzer verknüpft sind, ebenfalls gelöscht!

Diese Probleme sind bekannt, da es zu diesem Thema mehrere Beiträge gibt:

Funktioniert Batch-Job nicht mehr, wenn Sie das Benutzerkonto deaktivieren, das ihn eingerichtet hat?

Das Leben ist ein Batch… (von Microsoft MVP Andre Arnaud de Calavon)

Die beiden oben genannten Szenarien können offensichtlich zu unbeabsichtigten Konsequenzen innerhalb des Systems führen. Wie gehen wir also damit um?

Mögliche Lösungen

Ich habe zwei verschiedene Methoden, die ich mit Kunden verwendet habe, um dieses Problem anzugehen:

– Verwenden Sie Tabellenereignisse, um zu erfassen, wenn eine Änderung an der UserInfo-Tabelle auftritt (entweder Deaktivierung eines Benutzers oder Löschung eines Benutzers), und weisen Sie alle Batch-Jobs für diesen Benutzer einem Benutzer vom Typ „Admin“ zu

– Erstellen Sie ein benutzerdefiniertes Formular, mit dem Sie Batch-Jobs jedem gewünschten Benutzer neu zuweisen können. Mit diesem können Sie Batch-Jobs proaktiv neu zuweisen, bevor Sie einen Benutzer tatsächlich deaktivieren oder löschen

Das erste Szenario ist statischer, da Sie die Batch-Jobs immer einem einzelnen Benutzer zuweisen, aber es ist einfacher zu erstellen. Die zweite Lösung ist flexibler, fügt der Lösung jedoch eine Menge Komplexität hinzu.

Die benutzerdefinierte Formularoption wird wahrscheinlich vom Kunden abhängen, also schauen wir uns an, wie wir die erste Option verwenden könnten, um eine Lösung zu finden.

Tabellenereignislösung

Mithilfe von Tabellenereignissen können wir auf Ereignisse lauschen, die die UserInfo-Tabelle aktualisieren oder löschen, die die Tabelle ist, in der Stammdateninformationen über Benutzer gespeichert sind. Insbesondere müssen wir zwei verschiedene Szenarien handhaben, in denen der betroffene Benutzer mit Batch-Jobs verbunden ist:

  • Eine Aktualisierung für einen Benutzer, die den Benutzer von „aktiviert“ in „deaktiviert“ ändert
  • Eine Löschung für einen Benutzer

Um festzustellen, ob sich eine Benutzeränderung auf einen Batch-Job auswirkt, müssen wir zuerst nachsehen, wo Batch-Jobs mit einem Benutzer verknüpft sind. In der BatchJob-Tabelle können wir sehen, dass es ein ExecutingBy-Feld gibt. Dies ist der Benutzer, als der der Batch-Job ausgeführt wird, und das Feld, das wir basierend auf den oben genannten Ereignissen ändern müssen.

Dieses Feld ist mit dem Feld „Ausführen von“ im Batch-Jobs-Formular verknüpft (das unter Systemverwaltung -> Anfragen -> Batch-Job zu finden ist):

Die Idee wäre also, auf Änderungen eines Benutzers zu lauschen, die eines der oben genannten Kriterien erfüllen, und wenn es eine solche Änderungsprüfung gibt, um zu sehen, ob dieser Benutzer so eingestellt ist, dass er irgendwelche Batch-Jobs ausführt, und wenn ja, um die ‘Run by’ zu ändern ‘ an einen anderen Benutzer.

Dazu habe ich unserer Testumgebung folgenden Code hinzugefügt:

Um den Code etwas aufzuschlüsseln:

– Der erste Abschnitt lauscht auf Aktualisierungsereignisse in der UserInfo-Tabelle und sucht explizit nach Änderungen im Feld „enable“. Wenn die alten und neuen Werte für das Feld „enable“ unterschiedlich sind und der neue Wert auf „false“ gesetzt ist, suchen Sie nach Batch-Jobs, bei denen der Benutzer „ExecutingBy“ dieser Benutzer ist, und aktualisieren Sie auf einen Administratorbenutzer.

– Der zweite Abschnitt lauscht auf Löschereignisse in der Tabelle UserInfo und führt die gleiche Prüfung für Batch-Jobs durch, bei denen der Benutzer „ExecutingBy“ auf den zu löschenden Benutzer festgelegt ist, und aktualisiert den Datensatz auf einen Admin-Benutzer. Eine Sache, die hier zu beachten ist, ist, dass beide Ereignisse auf das Ereignis „Aktualisieren/Löschen“ hören, dies bedeutet, sich in das Ereignis einzuklinken, bevor es abgeschlossen ist, was es uns im Falle einer Löschung ermöglicht, den Batch-Job-Datensatz zu ändern, bevor er gelöscht wird, weil der Benutzer wird gelöscht.

Eine Textversion des obigen Codes finden Sie hier.

Testlösung

Lassen Sie uns zuerst hineingehen und testen, wie Sie einen Benutzer mit an ihn gebundenen Batch-Jobs deaktivieren. Wir werden diesen CHARLIE-Benutzer als unseren Test verwenden, er hat ein paar Batch-Jobs, bei denen er der ‘Run by’-Benutzer ist:

Wenn wir den Benutzer deaktivieren, erhalten wir diese Warnung:

Wenn Sie sich den Code ansehen, liegt dies daran, dass innerhalb einer validateWrite() -Methode der UserInfo-Tabelle des Benutzers jeder Batch-Job, der vom Benutzer erstellt oder ausgeführt wird, diese Warnung generiert:

In unserem Fall ist der Benutzer „Run by“ jedoch bereits auf unseren Admin-Benutzer aktualisiert:

Nachdem wir also das Aktualisieren eines Benutzers getestet haben, können wir jetzt zum Testen des Löschens eines Benutzers wechseln. Um dies zu testen, verwenden wir den CHRIS-Benutzer, dem der folgende Batch-Job mit seinem Benutzer zugeordnet ist:

Wenn wir also jetzt fortfahren und diesen Benutzer löschen:

Wir können sehen, dass dieser Batch-Job immer noch existiert (!) und von unserem Admin-Benutzer „ausgeführt“ wurde:

Fazit

Wenn Sie noch einen Schritt weiter gehen möchten, können Sie den obigen Code verwenden und ihn bei der Erstellung eines benutzerdefinierten Formulars verwenden, wenn Sie möchten. Eine Sache, die ich sagen möchte, ist, dass bis zu dem Punkt, auf den Andre in seinem Blogbeitrag hingewiesen hat, all dies vermieden werden kann, wenn der Batch-Job so eingerichtet ist, dass er ein Dienstkonto verwendet, was auch meine Empfehlung wäre, aber falls dies nicht möglich ist Die obige Lösung trägt dazu bei, dass Ihre Batch-Jobs weiterhin reibungslos ausgeführt werden.

Der Beitrag Umgang mit Batch-Jobs beim Deaktivieren oder Löschen eines Benutzers in D365FO erschien zuerst auf Alex Meyer.

.

Author: admin

Leave a Reply

Your email address will not be published.