Prüfung vorhanden

Eine Prüfung vorhanden Regel führt eine Suche für Entitäten einer bestimmten Klasse in der Lobster Data Platform / Orchestration-Datenbank aus und prüft, ob diese mindestens einen Treffer liefert.

►WICHTIG◄ Analog zum Abfragekonfigurator bezieht sich die Suche dabei nur Entitäten der Klasse, für die im Kontext der aktuellen Sitzung Lesezugriff besteht.

►WARNUNG◄ Die Verwendung dieses Regeltyps ist innerhalb von Zuordnungskriterien mit Blick auf die Systemperformance grundsätzlich nicht zu empfehlen, da sonst die enthaltenen Datenbank-Suchen unter Umständen sehr häufig ausgeführt werden. Eine Ausnahme bilden Zuordnungskriterien als Logikbausteine), die wie die Regeln in Ereignisbehandlungen nur gezielt angesprochen und deshalb typischerweise eher selten ausgeführt werden.

Die Definition der Suche erfolgt über die folgenden Elemente (s. auch Such API):

• Die Auswahl einer Klasse bestimmt den Entitätstyp, nach dem gesucht werden soll.

• Entitäten anderer Typen können ausgehend von der Klasse bei Bedarf über Joins einbezogen werden.

• Die Bedingung definiert Einschränkungen für die Suche, die sich auf Merkmale aller beteiligten Entitäten beziehen können.

►HINWEIS◄ Zur Definition der Restriktion innerhalb der Bedingung konfigurierte Projektionen beziehen sich auf die gesuchte Klasse und nicht auf das im Kontext von Prüfung vorhanden gerade gültige Bezugsobjekt. Sofern die Restriktion Daten des Bezugsobjekts einbeziehen soll, kann auf dieses über die Variable entity zugegriffen werden. Natürlich können bei Bedarf auch andere Variablen in die Restriktion einbezogen werden, auch um einen "weiter entfernten" Kontext (außerhalb einer Für jeden Eintrag wiederholen (Schleife) oder einer Ausführen mit-Ereignisaktion) einbeziehen zu können.

Anwendungsbeispiel:

Die Prüfende Regel für eine Ereignisbehandlung soll dafür sorgen, dass die "Aktionen bei wahr" genau dann ausgeführt werden, wenn es im Besitz der Firma der Session inaktive Benutzer gibt.

• Hier wird eine Suche für die Klasse "Benutzer" definiert, die ohne Joins auskommt.

• Als Restriktion wurde eine UND-Verknüpfung zweier Kriterien konfiguriert:

  • Die erste Feld Einschränkung schränkt dabei auf Benutzer ein, deren "Besitzer" (ownerID) mit der ID (id) der Firma der Session übereinstimmt.

  • Die zweite Feld Einschränkung schränkt auf Benutzer ein, für die das Kennzeichen "Aktiv" (active) nicht gesetzt (false) ist.

Die Regel gilt als bestanden, wenn die die Schnittmenge aus den beiden Einschränkungen nicht leer ist. Dann könnte z. B. eine Fehlermeldung angezeigt oder eine bestimmte View geöffnet werden, in der die inaktiven Benutzerkonten erscheinen.