Firmenwert
Wertauflöser - Kurzfassung
Zweck: Gibt die Daten eines statisch ausgewählten Firmenkontos zurück.
Siehe auch: Rolle
Der Firmenwert-Wertauflöser ruft die Daten des durch statische Auswahl für den optionalen Parameter Firmenwert spezifizierten Firmenkontos vom Server ab.
Ohne Auswahl für den Parameter Firmenwert lautet der Rückgabewert "kein Wert" (null).
Eine neu hinzugefügte Instanz des Firmenwert-Wertauflösers enthält keine Auswahl und erscheint wie oben dargestellt mit einem "leeren Label".
Wird eine bestehende Auswahl (bzw. das "leere Label") per Klick auf das "X" im Label entfernt, erscheint die Combobox leer. Das Speichern einer Konfiguration mit einem Firmenwert-Wertauflöser in diesem Zustand lässt das "leere Label" wieder erscheinen.
►WICHTIG◄ Anstelle des Firmenwert-Wertauflösers, könnte man auch einen Eingabeobjekt (Typsicher)-Wertauflöser für den Typ "Firmenkonto" verwenden, dem als Eingabewert per Verkettung die ID (id) einer Firma (z. B. als statischer Long-Wert) zugeführt wird. Auch wenn es keine Unterschiede im Laufzeitverhalten der beiden Methoden gibt, besteht allerdings ein wichtiger Unterschied, wenn im Kontext einer Implementierung Lobster Data Platform / Orchestration-Konfigurationen per Meta Exchange zwischen Systemen ausgetauscht werden sollen. Wird der Firmenwert-Wertauflöser verwendet, um auf eine bestimmte Firma zuzugreifen, werden beim Meta Exchange ggf. relevante Verknüpfungen zwischen Firmenkonten (z. B. zwischen Test- und Produktivsystem) berücksichtigt, um die "korrespondierende" Firma unabhängig von der in der jeweiligen Umgebung gültigen ID (id) automatisch zuzuordnen. Wird ein Firmenkonto dagegen per Long-Wert mit dem Eingabeobjekt (Typsicher)-Wertauflöser adressiert, dann greift dieser Service nicht, was sich auf das Laufzeitverhalten von zwischen zwei Systemen übertragenen Konfigurationen fatal auswirken kann.
ACHTUNG
Der Firmenwert-Wertauflöser ist in einem Client Workflow nicht verfügbar! Der Bezug zu einem statisch bestimmten Firmenkonto kann in einem Client Workflow zwar ersatzweise durch eine Suche hergestellt werden. Mit Blick auf den Meta Exchange ist aber systematisch nicht ohne Weiteres gewährleistet, dass die verwendeten Suchkriterien systemübergreifend das jeweils korrespondierende Firmenkonto (entsprechend der Meta Exchange-Verknüpfungen) "finden".
Konfiguration
|
Der optionale Parameter Firmenwert listet in einem Auswahlfeld/Combobox-Element alle Firmen/Mandanten für eine statische Einfachauswahl auf, für die in der Sitzung Lesezugriff besteht, in der der Wertauflöser konfiguriert wird. Zur Laufzeit gibt der Wertauflöser die Daten des in der Konfiguration ausgewählten Firmenkontos ohne Berücksichtigung von Zugriffsbeschränkungen im anwendbaren Anmeldekontext zurück. Der Eingabewert wird ignoriert. |
|
Beispiele
Beispiel: Zuordnungskriterium zum Erkennen von "Testobjekten"
Ein Zuordnungskriterium soll prüfen, ob der Besitzer einer Entität einer statisch definierten Liste von "Testfirmen" angehört.
Konfiguration:
|
Ein Zuordnungskriterium mit dem Namen "IS_TEST_ENTITY" wird wie rechts abgebildet konfiguriert:
►ANMERKUNG◄ Das Verfahren, zuerst eine Liste von kompletten Firmenkonten aufzubauen, um diese anschließend in eine Liste von Long-Werten zu reduziert mag umständlich erscheinen. Allerdings ist es die einzige Methode, die dem Konfigurator in einer Systemlandschaft mit unterschiedlichen Umgebungen "Überraschungen" (bzw. ständige Kontrollen und Anpassungen von je Umgebung statisch definierten Firmen-IDs) erspart, wenn per Meta Exchange Konfigurationen zwischen Umgebungen ausgetauscht werden sollen. |
|
Beispiel: Automatische Anpassung des Besitzers beim Erstellen von bestimmten Entitätstypen
Im Zuge der Implementierung von Konfigurationen in einer Lobster Data Platform / Orchestration-Umgebung ist für gründliche Tests auch ein Schnellwechsel zu empfehlen, z. B. um zu verifizieren, wie sich die aktuelle Konfiguration auf unterschiedliche Anmeldekontexte (v. a. Firma und Rolle) auswirkt. Gelegentlich wird es bei dieser Arbeitsweise vorkommen, dass eine neue Konfiguration, z. B. ein Zuordnungskriterium oder eine Ereignisbehandlung, versehentlich im Kontext einer "falschen" Firma erstellt wird. Da das System einer erstellen Entität automatisch die Firma der Session als Besitzer zuweist, kann das bewirken, dass z. B. ein technisch korrekt erstelltes Zuordnungskriterium nur in Teilen der Firmenhierarchie wirksam wird, was weitreichende und vielfältige indirekte "Fehlfunktionen" auslösen kann.
Im vorliegenden Beispiel soll das Risiko "im Eifer des Gefechts" eine Konfiguration der falschen Firma zuzuordnen durch eine Automatik minimiert werden, die wie folgt funktioniert:
Üblicherweise sollen Konfigurationen wie Zuordnungskriterien und Ereignisbehandlungen von der Hauptfirma "Xflow AG" erstellt werden und in deren Besitz bleiben.
Beim Erstellen einer Entität einer dieser Typen wird geprüft, ob es sich bei der Firma der Session um eine der "Xflow AG" direkt oder indirekt untergeordnete "Subfirma" handelt.
Ist dies der Fall, dann soll als "Besitzer" (ownerId) automatisch die "Xflow AG" zugeordnet werden.
Konfiguration:
|
Eine Ereignisbehandlung, die auf das Auslösende Ereignis "Erstellen" (s. Allgemein (Ereignisse)) reagiert, wird wie rechts abgebildet konfiguriert:
|
|
|
Die Aktion bei bestandener Regel ist verhältnismäßig simpel:
|
|
►ANMERKUNG◄ Abhängig von den im Anmeldekontext anwendbaren Zugriffsrechten und Firmenfreigaben kann der Besitzerwechsel für die Entität bewirkten, dass auf diese nach dem Speichen nicht mehr (oder nicht mehr schreibend) zugegriffen werden kann. Spätestens dann sollte der vorher versäumte Schnellwechsel zur "Xflow AG" vorgenommen werden, um die Konfiguration in deren Kontext fortzusetzen.