Trackingstatus-hinzugefügt-Regel
Regeltypen - Kurzfassung
Zweck: Gilt als "bestanden", wenn sich der in der Variable trackingStatusEntry enthaltene Trackingstatus-Eintrag auf einen der Trackingstatus-Codes bezieht, die die Konfiguration der Regel durch eine statische Mehrfachauswahl spezifiziert.
Die Trackingstatus-hinzugefügt-Regel gilt als "bestanden", wenn sich der in der Variable trackingStatusEntry enthaltene Trackingstatus-Eintrag auf einen der Trackingstatus-Codes bezieht, die die Konfiguration der Regel durch eine statische Mehrfachauswahl spezifiziert.
Die Regel wird typischerweise in Zusammenhang mit einem der Ereignisse eingesetzt, die bei beim Hinzufügen eines Trackingstatus für ein Geschäftsobjekt (Trackingstatus (Ereignisse)) ausgelöst werden. In deren Kontext verweist die Variable trackingStatusEntry automatisch auf den hinzugefügten bzw. hinzuzufügenden Trackingstatus-Eintrag.
Falls die Variable trackingStatusEntry leer ist oder nicht auf eine Entität des Typs "Trackingstatus-Eintrag" verweist, gilt die Regel als "nicht bestanden".
►HINWEIS◄ Die Regel wertet die Variable trackingStatusEntry unabhängig davon aus, ob der enthaltene Trackingstatus automatisch zugewiesen wurde, weil er gerade hinzugefügt wird. Man kann sie also verwenden, um den Trackingstatus-Code eines beliebigen Trackingstatus-Eintrags gegen die Positivliste zu prüfen, wenn man diesen vorher dieser Variablen zuweist.
Konfiguration
|
Die Konfiguration der Trackingstatus-hinzugefügt-Regel sieht eine statische Mehrfachauswahl über eine Multi-Combobox mit Suchfunktion vor, die alle Trackingstatus-Codes zur Auswahl anbietet, für die im Kontext der Konfiguration mindestens Lesezugriff besteht. Wenn keine Trackingstatus ausgewählt sind, gilt die Regel immer als "nicht bestanden". ►HINWEIS◄ Fehlt der Lesezugriff für einen bereits ausgewählten Trackingstatus-Code, dann erscheint Dieser trotzdem in der Auswahl. Solange ein derartiger Eintrag nicht gezielt entfernt wird, bleibt er in der Liste auch dann bestehen, wenn andere Einträge hinzugefügt oder entfernt werden. Durch "Umkehren" einer bestehenden Auswahl abgewählte Einträge, für die kein Zugriff besteht, erscheinen durch erneutes "Umkehren" nicht wieder in der Auswahl. |
|
Beispiel
Immer wenn einem beliebigen Bezugsobjekt erfolgreich ein bestimmter Trackingstatus ("NATIV") hinzugefügt wurde, soll geprüft werden, ob der aktuelle Trackingstatus-Eintrag dieses Objekts auf denselben Trackingstatus-Code verweist. Weicht der "aktuelle Trackingstatus" vom gerade zugewiesenen dem Code nach ab, soll dem Benutzer dieser Umstand gemeldet werden.
►ANMERKUNG◄ Die beschriebene Anforderung mag auf den ersten Blick ausgefallen oder umständlich erscheinen. Allerdings kann es beim Hinzufügen von Trackingstatus im Unterschied zu Arbeitsstatus durchaus vorkommen, dass der zuletzt hinzugefügte Eintrag vom als "aktuell" betrachteten abweicht. Einerseits wird beim Hinzufügen von Trackingstatus-Einträgen die "Externe Erstellungszeit" berücksichtigt, so dass auch "rückdatierte" Einträge chronologisch einsortiert werden. Andererseits kann es abhängig von den ggf. anwendbaren Trackingstatus-Workflows vorkommen, dass der hinzugefügte Eintrag einen anderen Trackingstatustyp als "Aktuell" (CURRENT) betrifft. Dann verweist der Wert des Trackingstatus-Attributs für den Typ "Aktuell" unverändert auf einen anderen als den gerade hinzugefügten Trackingstatus-Eintrag. Der Trackingstatus-Code dieser Einträge kann sich also unterscheiden oder auch nicht. Im Anwendungsfall soll die Regel als "bestanden" gelten, sofern die Codes sich unterscheiden. Unterschiedliche Einträge, die auf denselben Code verweisen, sollen nicht "gemeldet" werden.
Konfiguration:
|
Eine Ereignisbehandlung, die auf das Auslösende Ereignis Trackingstatus wurde hinzugefügt reagiert, wird wie rechts abgebildet konfiguriert. ►WICHTIG◄ Das auslösende Ereignis verweist per Variable trackingStatusEntry auf den gerade hinzugefügten Trackingstatus-Eintrag. Das Bezugsobjekt spielt für die Prüfung durch die Trackingstatus-hinzugefügt-Regel keine unmittelbare Rolle.
|
|
