Übersicht über die Registrierungsregeln

Vertiefung: Übersicht über die Registrierungsregeln und deren Erstellung

Was sind Registrierungsregeln?

Registrierungsregeln sind ein wichtiger Aspekt jeder Learning Suite-Konfiguration, um benutzerbezogene Prozesse zu automatisieren und so die Effizienz zu steigern. Die Regeln basieren auf Nutzerattributen und werden jedes Mal ausgeführt, wenn ein neues Benutzerkonto erstellt oder ein bestehender Nutzer aktualisiert wird. Jede Regel kann eine oder mehrere Bedingungen mit einzelnen/und-/oder-Überlegungen enthalten, die Befehle auslösen, wenn sie erfüllt sind. Diese Regeln können recht fortschrittlich sein und werden normalerweise von den Scheer IMC Consultants, die das Implementierungsprojekt durchführen, oder Learning Consultants verwaltet, können aber auch von Systemadministratoren des Kunden aktualisiert werden.

Gängige Anwendungsfälle der Registrierungsregel

Es gibt viele Anwendungsfälle für Registrierungsregeln, wobei die gängigsten Regeln folgende sind:

• Zuordnung eines Nutzers zu einer Gruppe

• Zuordnung eines Nutzers zu einem Mandanten

• Zuordnung eines Stellenprofils zu einem Nutzer

• Zuordnung einer Zertifizierung zu einem Nutzer

• Erteilung von Gruppenfreigaben für einen Nutzer

• Festlegen von Werten und Einstellungen für Nutzerattribute

Dieser Artikel soll einen detaillierten Überblick über die Regelformate und die verfügbaren Regeltypen geben, häufig verwendete Grundregeln erläutern und einige erweiterte Regeloptionen vorstellen.

Überprüfung der Registrierungsregeln

Die Regeln werden im XML-Format geschrieben und mit einer entsprechenden XML-Datei in die Learning Suite hochgeladen. Systemadministratoren können die XML-Datei herunterladen, um bei Bedarf Änderungen vorzunehmen und sie erneut hochzuladen. Wenn Sie Änderungen vornehmen, empfiehlt es sich, ein Tool wie Notepad++ zu verwenden, um die Regeldatei anzuzeigen, da etwaige Formatierungsfehler damit leicht zu erkennen sind.

Es gibt zwei Orte, an denen die Regeldateien herunter- bzw. hochgeladen werden können, da die Regeln global (systemweit) oder mandantenspezifisch sein können.

Globale Regeln

Die Datei mit den globalen Registrierungsregeln kann über das Menü Import in der Funktion Konfiguration herunter- und hochgeladen werden. Globale Regeln werden verarbeitet, wenn keine mandantenspezifischen Regeln verfügbar sind oder wenn ein globaler Nutzerimportauftrag nicht mit einem bestimmten Mandanten verknüpft ist.

Mandantenspezifische Regeln

Mandantenspezifische Registrierungsregeln können im Abschnitt Import des Tabs Einstellungen der Mandantenfunktion über das Feld Regeldatei-Upload hoch- oder heruntergeladen werden. Diese Regeln werden für mandantenspezifische Nutzerimport- oder Bereitstellungsschnittstellen (z. B. CSV, SAML, SCIM, OIDC) und bei der Erstellung/Aktualisierung von Nutzern über das GUI in einem bestimmten Mandantenkontext verarbeitet.

Validierung von Regeln

Für Regeldateien können beliebige Namen verwendet werden. Um eine Regeldatei hochladen zu können, muss der Dateityp XML sein. Nach dem Hochladen führt die Learning Suite eine detaillierte Dateivalidierung anhand einer Reihe von XSDs durch. Die Prüfung stellt sicher, dass die XML-Struktur gültig ist und dass die richtigen Werte verwendet wurden. Bei Fehlern wird die Datei nicht gespeichert, die Fehler werden auf dem Bildschirm angezeigt, wobei die Fehlerzeilen hervorgehoben werden, und die bisherigen Regeln bleiben erhalten. Beim Hochladen einer Regeldatei in der Funktion Mandanten werden nach dem Speichern etwaige Fehler oben im Tab angezeigt, so dass nach oben gescrollt werden muss, um sie einzusehen.

Schreiben von Registrierungsregeln

Es gibt drei Hauptbausteine für grundlegende Registrierungsregeln, nämlich die Regel (Rule), die Bedingungen (Conditions) und die Befehle (Commands). Fortgeschrittenere Regeln enthalten für gewöhnlich auch Hash-Tabellen. Jeder dieser Bausteine wird im Folgenden ausführlich behandelt. Die Struktur einer typischen Regeldatei sieht wie folgt aus, wobei die Datei immer mit <co:rules> beginnt und mit </co:rules> endet.

<co:rules>
  <!-- Hash-Tabellen definieren (optional) -->
  <!-- IDENTIFIER wird durch den command -->
  <co:hashTable identifier="IDENTIFIER" defaultValue="" comment="COMMENT">
    <!-- Anweisung interagiert mit der Systemdatenbank, um die richtigen Werte abzurufen. Auswahllisten werden normalerweise genommen -->
    <co:hashTableSelectStatement isIntAttribute="true">
      <!-- Definieren Sie die hashtable-Anweisung, um einen Wert für eine bestimmte Eingabe abzurufen -->
    </co:hashTableSelectStatement>
  </co:hashTable>
  <!-- Definieren Sie die Regeln -->
  <co:rule>
    <co:ruleConditions>
      <!-- Definieren Sie die Bedingungen für diese spezielle Regel: AND, OR oder NOT -->
    </co:ruleConditions>
    <!-- Definieren Sie den Befehl für diese spezifische Regel: ASSIGN, SET oder GRANTAND, OR oder NOT -->
  </co:rule>
  <!-- Definieren Sie weitere Regeln mit Bedingungen und Befehlen -->
</co:rules>

Die Reihenfolge, in der die Regeln geschrieben werden, ist wichtig, da dies auch die Reihenfolge ist, in der die Regeln verarbeitet werden. Kommentare, die nicht verarbeitet werden, können innerhalb der Regeln als Informationen eingegeben werden, wenn sie wie folgt eingeschlossen werden <!-- Kommentare (optional) - - >.

Regel

Mehrere Regeln können mit einzelnen Regeln (XML-Notation: co:rule) definiert werden, die innerhalb eines XML-Tags festgelegt werden: <co:rules>. Das bedeutet, dass die XML-Datei mit dem Tag <co:rules> beginnt und mit dem Tag </co:rules> endet, wobei alle einzelnen Regeln zwischen Anfangs- und End-Tag definiert werden. Jede einzelne Regel muss mit dem Tag <co:rule> beginnen und mit dem Tag </co:rule> enden. In den folgenden Abschnitten werden die verschiedenen Optionen erläutert, die für Bedingungen, Befehle und Hash-Tabellen zur Verfügung stehen.

Bedingungen

Jede Regel kann eine einzelne oder mehrere Bedingungen (AND / OR) enthalten, die erfüllt sein müssen, damit die Regel ausgeführt wird. Die Bedingungen basieren auf Nutzerattributen und dienen als Filter, um die Anzahl der auszuführenden Befehle zu minimieren. Diese Bedingungen sind der komplexeste Aspekt der Regel angesichts der Anzahl der verfügbaren Attribute und Vergleichsoperatoren, die einbezogen werden können. Nur wenn die Bedingung auf TRUE aufgelöst wird, wird der nachfolgende Befehl ausgeführt.

Nicht alle Regeln erfordern Bedingungen. So werden z. B. pauschale Regeln häufig verwendet, um alle Nutzer einer bestimmten Gruppe zuzuordnen oder allen Nutzern die Freigabe für bestimmte Gruppen zu erteilen. Regeln, die sich auf Hash-Tabellen beziehen, können auch nur Befehle enthalten.

Bedingungsattribute

Die Bedingungen können die folgenden Attribute enthalten:

Vergleichsoperatoren

Es gibt viele Vergleichsoperatoren oder Expression-Typen für Bedingungen, die nach der Expression im Attribut matching definiert sind. Diese definieren die Art des Vergleichs zwischen den Attributen expression und value.

<co:ruleCondition expression="ATTRIBUTE_NAME" matching="EQUAL" value="3"/>

<co:ruleCondition expression="ATTRIBUTE_NAME" matching="UNEQUAL" value="3"/>

<co:ruleCondition expression="ATTRIBUTE_NAME" matching="GREATER" value="3"/>

<co:ruleCondition expression="ATTRIBUTE_NAME" matching="SMALLER" value="3"/>

<co:ruleCondition expression="ATTRIBUTE_NAME" matching="ISEMPTY"/>

<co:ruleCondition expression="ATTRIBUTE_NAME" matching="ISNOTEMPTY"/>

<co:ruleCondition expression="ATTRIBUTE_NAME" matching="EXISTS"/>

<co:ruleCondition expression="ATTRIBUTE_NAME" matching="NOTEXISTS"/>

<co:ruleCondition expression="ATTRIBUTE_NAME" matching="HASELEMENT" value="EL2" listseperator=";"/>

<co:ruleCondition expression="ATTRIBUTE_NAME" matching="INLIST" value="EL1;EL2;EL3" listseperator=";"/>

<co:ruleCondition expression="ATTRIBUTE_NAME" matching="HASSUBSTRING" value="RIN"/>

<co:ruleCondition expression="ATTRIBUTE_NAME" matching="STARTSWITH" value="STR"/>

<co:ruleCondition expression="ATTRIBUTE_NAME" matching="ENDSWITH" value="ING"/>

Einzelne Condition

Regeln mit einzelnen Conditions (Bedingungen) haben nur die Tags <co:ruleConditions> und </co:ruleConditions> mit einem <co:ruleCondition expression=" " matching „ “/> dazwischen.

<!-- Registrierungsregel: einzelne Condition -->
<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="ATTTRIBUTE_NAME" matching="EQUAL" value=" "/>
  </co:ruleConditions>
  <!-- Definieren Sie den Befehl: ASSIGN, SET oder GRANT -->
</co:rule>

andCondition

Die andCondition ermöglicht mehrere Conditions und erfordert, dass jede einzelne davon TRUE sein muss. Regeln mit andConditions haben den Tag <co:ruleConditions>, gefolgt von <co:andCondition>, dann mehrere Tags für jede <co:ruleCondition expression=" " matching=„ “ />, dann ein schließendes </co:andCondition> und ein schließendes </co:ruleConditions>.

In dem folgenden Beispiel muss der Nutzer

• in einem bestimmten LAND (z. B. Deutschland mit der ID 82) sein; UND

• eine bestimmte POSITION innerhalb des Unternehmens (z. B. Verkaufsleiter in einer benutzerdefinierten Auswahlliste) haben.

Nur wenn alle Bedingungen erfüllt sind, wird der Befehl bzw. werden die Befehle ausgeführt.

<!-- Registrierungsregel: andCondition-->
<co:rule>
  <co:ruleConditions>
  <!-- ALLE Konditionen müssen auf TRUE aufgelöst werden -->
    <co:andCondition>
      <co:ruleCondition expression="COUNTRY" matching="EQUAL" value="82"/>
      <co:ruleCondition expression="POSITION" matching="EQUAL" value="3"/>
    </co:andCondition>
  </co:ruleConditions>
  <!-- Definieren Sie den Befehl: ASSIGN, SET oder GRANT -->
</co:rule>

orConditions

Die orCondition ermöglicht mehrere Conditions und erfordert, dass mindestens eine davon TRUE ist. Regeln mit orConditions haben den Tag <co:ruleConditions>, gefolgt von <co:orCondition>, dann mehrere Tags für jede <co:ruleCondition expression=" " matching=„ “/>, dann ein schließendes </co:orCondition> und ein schließendes </co:ruleConditions>.

Im folgenden Beispiel muss der Nutzer eine der drei Phrasen in seinem JOB_TITLE haben, damit die orCondition TRUE ist. Wenn eine der Bedingungen erfüllt ist, wird der Befehl bzw. werden die Befehle ausgeführt.

<!-- Registrierungsregel: orCondition-->
<co:rule>
  <co:ruleConditions>
    <!-- EINE Bedingung muss TRUE sein -->
    <co:orCondition>
      <co:ruleCondition expression="JOB_TITLE" matching="HASSUBSTRING" value="Manager"/>
      <co:ruleCondition expression="JOB_TITLE" matching="HASSUBSTRING" value="Supervisor"/>
      <co:ruleCondition expression="JOB_TITLE" matching="HASSUBSTRING" value="Head of"/>
	</co:orCondition>
  </co:ruleConditions>
  <!-- Definieren Sie den Befehl: ASSIGN, SET oder GRANT -->
</co:rule>

Befehle

Jede Regel enthält ein oder mehrere Befehl-Tags, um die definierte Aktion auszuführen, wenn die Bedingungen erfüllt sind. Die Befehl-Tags beginnen mit dem Typ (assign, set, grant), enthalten dann einen Kontext (Mandant, Gruppe, Zertifizierung, Jobprofil), gefolgt von einem Ziel und dann gegebenenfalls einigen optionalen Attributen.

assignCommand-Tags

Die assignCommand-Tags werden verwendet, um entweder den Nutzer einer Gruppe zuzuweisen, den Nutzer einem Mandanten zuzuweisen, dem Nutzer ein Jobprofil zuzuweisen oder dem Nutzer eine Zertifizierung zuzuweisen. Diese Befehle beginnen immer mit <co:assignCommand und legen dann den gewünschten Kontext fest. Der ausgewählte Kontext bestimmt dann, welche der folgenden Attribute einbezogen werden sollen:

Zuordnung eines Nutzers zu einer Gruppe

Der assignCommand hat den Kontext GROUP und das Ziel ist die Objekt-ID der Gruppe.

<!-- Eintragungsregel: assignCommand Group -->
<co:rule>
  <co:ruleConditions>
	<co:ruleCondition expression="EMPLOYEE_ID" matching="ISEMPTY" mode="VALUE"/>
  </co:ruleConditions>
  <co:assignCommand context="GROUP" target="239225" execute="ALWAYS"/>
</co:rule>

Zuordnung eines Jobprofils zu einem Nutzer

Der assignCommand hat den Kontext JOBPROFILE und das Ziel ist die Objekt-ID des Jobprofils.

<!-- Registrierungsregel: assignCommand Job-Profil -->
<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="IS_IMC_PARTNER" matching="EQUAL" value="1"/>
  </co:ruleConditions>
  <co:assignCommand context="JOBPROFILE" target="231913" execute="ALWAYS"/>
</co:rule>

Zuordnung einer Zertifizierung zu einem Nutzer

Der Befehl assignCommand hat den Kontext CERTIFICATION und das Ziel ist die Objekt-ID der Zertifizierung.

<!-- Registrierungsregel: assignCommand Zertifizierung -->
<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="DEPARTMENT" matching="EQUAL" value="Accounts"/>
  </co:ruleConditions>
  <co:assignCommand context="CERTIFCATION" target="235657" execute="ONCE"/>
</co:rule>

GRANT-Befehle

GRANT-Befehle werden verwendet, um einer Gruppe oder einem Mandanten Freigaben für einen Nutzer zu erteilen. Die Freigabestufe kann Voll, Ansicht (Ausführen) oder eine binäre Kombination spezifischer Authentifizierungen sein. Diese Befehle beginnen immer mit <co:grantCommand, gefolgt von dem gewünschten Kontext (Gruppe oder Mandant) und dem Ziel, das die Objekt-ID enthält. Das value-Attribut bestimmt den Grad der Freigabe, der _full oder _view sein kann.

Erteilung der Freigabe für eine Gruppe

Um einem Nutzer die Freigabe für eine Gruppe zu erteilen, muss der Kontext gleich GROUP sein, wobei das Ziel die Objekt-ID der Gruppe ist.

<!-- Registrierungsregel: grantCommand Group -->
<co:rule>
  <co:ruleConditions>
	<co:ruleCondition expression="EMPLOYEE_ID" matching="ISEMPTY" mode="VALUE"/>
  </co:ruleConditions>
  <co:grantCommand context="GROUP" target="239227" value="_full" execute="ALWAYS"/>
</co:rule>

setCommand-Tags

setCommand-Tags werden verwendet, um ein Nutzerattribut basierend auf dem Wert eines anderen Nutzerattributs zu füllen. Zum Beispiel würden die meisten Regeln die CLIENT_ID des Nutzers setzen, um deren Master-Mandanten zu definieren. Diese Befehle beginnen immer mit <co:setCommand und setzen dann das gewünschte Ziel, d.h. den Namen einer Nutzerattribute-Datenbank. Die folgenden Attribute sind mit setCommands möglich:

Nachfolgend sehen Sie einen einfachen setCommand, der auf einer einzelnen ISEMPTY-Bedingung basiert, um einen Nutzerattributwert zu setzen.

<!-- MAIN CLIENT setzen, wenn client_id des Benutzers leer ist -->
<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="CLIENT_ID" matching="ISEMPTY"/>
  </co:ruleConditions>
  <co:setCommand target="CLIENT_ID" value="1"/>
</co:rule>  

Hash-Tabellen

Hash-Tabellen (hashTables) werden in erweiterten Regeln verwendet, um Eingabe- auf Ausgabewerte abzubilden, und müssen vor der Aufnahme in Regeln definiert werden. Eine Hash-Tabelle muss einen eindeutigen Identifikator, einen Standardwert und entweder HashTable-Zeilen (hashTableRows) mit Eingabe-Ausgabe-Beziehungen oder ein einzelnes SQL-Statement enthalten.

Einige Beispiele für die Verwendung von Hash-Tabellen sind:

• Abfrage der Zeitzone für bestimmte Länder

• Abrufen von OE-Gruppen auf Grundlage des Attributs Abteilung oder Geschäftsbereich

• Umrechnung von Eingabewerten (z. B. männlich / weiblich → 1 / 2)

<co:rules>
  <co:hashTable identifier="GROUPBYCOUNTRY" defaultValue="0" comment="Get group based on country">
    <co:hashTableRow index="VA" value="1" comment="Status aktiv fuer Wert VA"/>
    <co:hashTableRow index="VI" value="2" comment="Status passiv fuer Wert VI"/>
    <co:hashTableRow index="VBO" value="2" comment="Status passiv fuer Wert VBO"/>
  </co:hashTable>
  <co:rule>
    <!-- Bedingungen und Kommandos -->
  </co:rule>
</co:Rules>

Element: hashTable

Die folgenden Attribute sind für eine Hash-Tabellen (hashTable) verfügbar:

Element: hashTableRow

HashTableRows werden verwendet, um das Input-Output-Mapping zu erstellen. Jede Zeile steht für einen Tupel (Eingabewert, Ausgabewert). Diese Zeilen dienen in der Regel dazu, Feldeingaben aus einem externen System in ein entsprechendes Nutzerattribut in der Lernsuite umzuwandeln, z. B. die Umwandlung einer Textzeichenfolge in die entsprechende Auswahllisten-ID in der Lernsuite.

Element: hashTableSelectStatement

Es kann eine beliebige SQL-Abfrage verwendet werden, die einen einzigen Wert zurückgibt. Der Eingabewert wird durch den Index geliefert, der sich auf die HashTable bezieht. In dem SQL-Statement ist der Index durch ein Fragezeichen „?“ gekennzeichnet. Es ist nur ein Fragezeichen in dem SQL-Statement erlaubt.

Aufruf einer Hash-Tabelle aus einem Befehl

Eine Hash-Tabelle (hashTable) kann von jedem Befehl aus aufgerufen werden, da sie lediglich einen Wert liefert.

• Das Ziel gibt an, dass der Wert durch eine hashTable abgerufen wird.

• Der Index stellt den Eingabewert für die hashTable dar.

• Die Hashident muss dem Identifikator der HashTable entsprechen und stellt die Tabelle dar, in der der Ausgabewert abgebildet wird.

Im folgenden Beispiel hat der assignCommand das Ziel „_hashval“, um eine Hash-Tabelle aufzurufen, und die hashident „GROUPBYCOUNTRY“ identifiziert die spezifische Hash-Tabelle, die aufgerufen werden soll. In einer Regeldatei können die Hash-Tabelle und die Regel oft getrennt sein.

<co:rules>
  <co:hashTable identifier="GROUPBYCOUNTRY" defaultValue="0" comment="Gruppe auf Basis von COUNTRY erhalten">
     <co:hashTableRow index="VA" value="1" comment="Status aktiv fuer Wert VA"/>
        <co:hashTableRow index="VI" value="2" comment="Status passiv fuer Wert VI"/>
        <co:hashTableRow index="VBO" value="2" comment="Status passiv fuer Wert VBO"/>
  </co:hashTable>
  <co:rule>
    <co:assignCommand context="GROUP" target="_hashval" index="COUNTRY_ID" hashident="GROUPBYCOUNTRY"/>
  </co:rule>
</co:Rules>

Beispiele für Regeln

In diesem Abschnitt werden einige häufig verwendete Beispiele für grundlegende und fortgeschrittene Regeln vorgestellt. Diese Beispiele werden die obige Theorie in praktische Beispiele umsetzen, die als Grundlage für ähnliche Anforderungen angepasst werden können.

Beispiele für Grundregeln

Standardregeln

Ein Standard-Learning-Suite-System vor der Konfiguration würde die im folgenden Beispiel gezeigten Regeln enthalten. Über jeder Regel wurden ein Kommentar eingefügt, der ihren Zweck beschreibt.

<co:rules>
  <!-- In einem Einzelmandantensystem wird dadurch das Nutzerattribut CLIENT_ID gesetzt  -->
  <co:rule>
    <co:setCommand target="CLIENT_ID" value="1"/>
  </co:rule>

  <!-- In einem Mehrmandantensystem wird dadurch das Nutzerattribut CLIENT_ID auf 1 gesetzt, wenn keine CLIENT_ID gesetzt ist. -->
  <co:rule>
    <co:ruleConditions>
		<co:ruleCondition expression="CLIENT_ID" matching="SMALLER" value="1"/>
    </co:ruleConditions>
    <co:setCommand target="CLIENT_ID" value="1"/>
  </co:rule>

  <!-- In einem Einmandantensystem werden alle Nutzer dem Mandanten mit der ID 1 zugewiesen. -->
  <co:rule>
    <co:assignCommand context="CLIENT" target="CLIENT_ID" mode="REFERENCE"/>
  </co:rule>

  <!-- Generische Regel, die das Benutzerattribut USER_ID, falls leer, mit dem im Benutzerattribut PERSON_ID generierten Wert auffüllt -->
  <co:rule>
    <co:ruleConditions>
		<co:ruleCondition expression="USER_ID" matching="ISEMPTY" mode="VALUE"/>
    </co:ruleConditions>
    <co:setCommand target="USER_ID" value="PERSON_ID" mode="REFERENCE"/>
  </co:rule>

  <!-- Freigabe von Benutzern für den Ersteller und die Gruppe Systemadministrator mit der Objekt-ID 1 -->
  <co:rule>
    <co:grantCommand context="OWNER" target="_creator" execute="ALWAYS"/>
    <co:grantCommand context="GROUP" target="1" value="_full" execute="ALWAYS"/>
  </co:rule>

  <!-- Weist alle Benutzer der Gruppe „Student“ mit der Objekt-ID 3 zu. -->
  <co:rule>
    <co:assignCommand context="GROUP" target="3" execute="ALWAYS"/>
  </co:rule>
</co:rules>

Gruppenzuordnungen

Gruppenzuordnung über EQUAL-Bedingung

Die Zuordnung von Nutzern zu einer bestimmten Gruppe erfolgt in der Regel über den EQUAL-Operator mit einem Nutzerattribut. Der Wert kann eine Zeichenkette (String) oder eine ID eines Auswahllisteneintrags oder einer Checkbox sein.

<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="COUNTRY_ID" matching="EQUAL" value="82"/>
  </co:ruleConditions>
  <co:assignCommand context="GROUP" target="231656" execute="ALWAYS"/><!--German lerner-->
</co:rule>

Gruppenzuordnung über ISEMPTY-Bedingung

Die Zuordnung von Nutzern zu einer externen Lerngruppe erfolgt üblicherweise über den ISEMPTY-Operator mit einem Benutzerattribut, das nur für interne Lernende ausgefüllt wird.

<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="EMPLOYEE_ID" matching="ISEMPTY" mode="VALUE"/>
  </co:ruleConditions>
  <co:assignCommand context="GROUP" target="239225" execute="ALWAYS"/><!--External Gruppe-->
</co:rule>

Gruppenzuordnung über orCondition

Die folgende Regel ordnet den Nutzer der Gruppe Supervisor (ID 9) zu, wenn das Nutzerattribut POSITION_TITLE entweder die Wörter Manager oder Supervisor enthält.

<co:rule>
  <co:ruleConditions>
    <co:orCondition>
      <co:ruleCondition expression="POSITION_TITLE" matching="HASSUBSTRING" value="Manager"/>
      <co:ruleCondition expression="POSITION_TITLE" matching="HASSUBSTRING" value="Supervisor"/>
    </co:orCondition>
  </co:ruleConditions>
  <co:assignCommand context="GROUP" target="9" execute="ALWAYS"/>
</co:rule>

Gruppenzuordnung über assignCommand (Checkbox)

Eine gängige assignCommand-Regel ist die Erstellung von Checkbox-Nutzerattributen im Backend-Benutzerprofil, um Nutzer zu Gruppen zuzuordnen. In diesem Beispiel gäbe es eine Checkbox mit einem kundenspezifischen Nutzerattribut, die, wenn sie angekreuzt ist (Wert = 1), den Nutzer der Gruppe mit der ID 1, dem Kunden mit der ID 1 und dem Kunden mit der ID 2 zuordnet.

<co:rule>
  <co:ruleConditions>
	<co:ruleCondition expression="IS_SYSTEMADMIN" matching="EQUAL" value="1"/>
  </co:ruleConditions>
  <co:assignCommand context="GROUP" target="1" execute="ALWAYS"/>
  <co:assignCommand context="CLIENT" target="1" execute="ALWAYS"/>
  <co:assignCommand context="CLIENT" target="2" execute="ALWAYS"/>
</co:rule>

grantCommand für bestimmte Nutzer

Die nachstehende Regel wird üblicherweise für Systeme verwendet, die externe Lernende beinhalten. Die Regel ordnet den Nutzer einer Gruppe Externe Lernende zu und erteilt die Freigabe für eine Gruppe Externer Administrator (ID 239227), wenn das Attribut EMPLOYEE_ID leer ist. In diesem Beispiel erhält auch die Gruppe Content Admin (ID 11) die Freigabe zur Ansicht. Das benutzerdefinierte Nutzerattribut EMPLOYEE_ID wird häufig durch den Standard EXT_ID_CSV oder einen alternativen eindeutigen Standardidentifikator ersetzt, der über einen automatisierten Nutzerimport eingegeben wird.

<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="EMPLOYEE_ID" matching="ISEMPTY" mode="VALUE"/>
  </co:ruleConditions>
  <co:assignCommand context="GROUP" target="239225" execute="ALWAYS"/><!--External-->
  <co:grantCommand context="GROUP" target="239227" value="_full" execute="ALWAYS"/><!--External Admin-->
  <co:grantCommand context="GROUP" target="11" value="_view" execute="ALWAYS"/><!--Content Admin-->
</co:rule>

Andere Beispiele für solche Regeln können sein, dass eine Gruppe, die eine Unternehmensabteilung, ein Team oder einen Standort repräsentiert, eine Freigabe für Nutzer innerhalb ihrer Gruppe erhält. Diese Regeln werden oft geschrieben, wenn Proxy-Anmeldungen aktiviert sind.

<co:rule>
	<co:ruleConditions>
		<co:ruleCondition expression="DEPARTMENT" matching="EQUAL" value="Operations"/>
	</co:ruleConditions>
	<co:assignCommand context="GROUP" target="242815" execute="ALWAYS"/><!--Operations-->
	<co:grantCommand context="GROUP" target="242815" value="_view" execute="ALWAYS"/><!--Operations-->
</co:rule>

setCommand zum Auffüllen der Nutzerattribute

Die Verwendung von setCommands wird häufig zum Ausfüllen von Nutzerattributen verwendet, die funktionale Einstellungen haben. Dies kann vorkommen, wenn ein externes Quellsystem über eine entsprechende Einstellung mit anderen Werten verfügt. Das externe System könnte zum Beispiel ein STATUS-Feld mit den Werten Aktiv/Beendet haben, was der AUTHENTIFICATIONSTATUS_ID der Learning Suite entspricht, die die Werte 1 (Aktiv) oder 2 (Passiv) annehmen kann. In diesem Fall könnte ein kundenspezifisches STATUS-Benutzerattribut zusammen mit Grundregeln erstellt werden, um die AUTHENTIFICATIONSTATUS_ID auf der Grundlage des STATUS festzulegen.

<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="STATUS" matching="EQUAL" value="Aktiv"/>
  </co:ruleConditions>
  <co:setCommand target="AUTHENTIFICATIONSTATUS_ID" value="1"/>
</co:rule>

<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="STATUS" matching="EQUAL" value="Beendet"/>
  </co:ruleConditions>
  <co:setCommand target="AUTHENTIFICATIONSTATUS_ID" value="2"/>
</co:rule>

Referenzregeln

Referenzregeln werden üblicherweise verwendet, um leere Nutzerattribute mit dem Wert eines anderen Nutzerattributs zu füllen. In der nachfolgenden Beispielregel würde bei einem Nutzer, der keine EXT_ID_CSV hat und bei dem IS_CONTRACTOR markiert ist, die EXT_ID_CSV mit dem Wert aus seinem LOGIN ausgefüllt.

<co:rule>
  <co:ruleConditions>
    <andCondition>
      <co:ruleCondition expression="EXT_ID_CSV" matching="ISEMPTY"/>
      <co:ruleCondition expression="IS_CONTRACTOR" matching="EQUAL" value="1"/>
    </andCondition>
  </co:ruleConditions>
  <co:setCommand target="EXT_ID_CSV" value="LOGIN" mode="REFERENCE"/>
</co:rule>

Im folgenden Beispiel kann eine Checkbox POSTAL_SAME_AS_RES in einem Frontend-Nutzerprofil oder einem Kurseinschreibungsformular nach einigen Nutzerattributen mit Wohnanschrift verwendet werden. Wenn der Nutzer diese Checkbox markiert, würde die Regel die Nutzerattribute Postanschrift mit den Werten der entsprechenden Nutzerattribute Wohnanschrift auffüllen.

<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="POSTAL_SAME_AS_RES" matching="EQUAL" value="1"/>
  </co:ruleConditions>
  <co:setCommand target="POSTAL_STREET_NUMBER" value="RES_STREET_NUMBER" mode="REFERENCE"/>
  <co:setCommand target="POSTAL_STREET" value="RES_STREET" mode="REFERENCE"/>
  <co:setCommand target="POSTAL_SUBURB" value="RES_SUBURB" mode="REFERENCE"/>
  <co:setCommand target="POSTAL_POSTCODE" value="RES_POSTCODE" mode="REFERENCE"/>
</co:rule>

Beispiele für erweiterte Regeln

Viele Kunden haben erweiterte Regeln, die Hash-Tabellen verwenden, um Aufgaben wie Look-ups und Konvertierungen durchzuführen.

Wert-IDs der Auswahlliste nachschlagen

Look-ups verwenden Hash-Tabellen, um einen Eingabewert einem anderen Ausgabewert zuzuordnen. Diese werden üblicherweise für Nutzerimporte verwendet, die Werte in Nutzerattribute von Auswahllisten importieren, und das Quellsystem enthält keine Auswahllistenwert-IDs. Im folgenden Beispiel werden hashTableRow-Zuordnungen definiert, bei denen der Index der Wert ist, der vom Quellsystem gesendet wird, und der Wert die Wert-ID der Learning Suite-Auswahlliste ist. Die unterste Zeile ist nicht Teil der Regeldatei und dient nur dazu, die Importzuordnung zu zeigen, die auf die hashTable mit der hashident verweist.

<!-- Zuordnung der Auswahlliste „“key„“ zu „value“ -->
<co:hashTable identifier="Title" defaultValue="0">
  <co:hashTableRow index="Mr" value="1"/>
  <co:hashTableRow index="Mrs" value="2"/>
  <co:hashTableRow index="Miss" value="3"/>
  <co:hashTableRow index="Ms" value="4"/>
  <co:hashTableRow index="Dr" value="5"/>
</co:hashTable>

<!-- Mapping-Zeile aus CSV-Import -->
<mapping sourceField="Title" clixField="TITLE" hashident="Title"/>

Das nächste Beispiel ist eine dynamischere Auswahllistensuche, da keine tatsächliche hashTableRow-Zuordnung erforderlich ist. Stattdessen wird ein SQL-Statement in der hashTable verwendet, das die Wert-ID der LMS-Auswahlliste auswählt, wenn eine Übereinstimmung mit der external_id (Schlüssel) in der Auswahltabelle gefunden wird, die in den Auswahllistenattributen verwendet wird. Bei der Erstellung einer Auswahlliste kann die external_id (Schlüsssel) importiert oder manuell gesetzt werden und stimmt normalerweise mit dem vom Quellsystem gesendeten Wert überein. Dieses Beispiel zeigt die Suche nach einem Wert der Auswahlliste LOCATION anhand der external_id (Schlüssel). Die untere Zeile ist eigentlich nicht Teil der Regeldatei und dient nur dazu, die Importzuordnung zu zeigen, die auf die hashTable mit der hashident verweist.

<co:hashTable identifier="MapLocationKeyWithId" defaultValue="0" comment="Ordnet Key der Learning Suite ID zu">
  <co:hashTableSelectStatement isIntAttribute="false">select max(id) from CUST_P_CURRENTLOCATION where external_id = ?</co:hashTableSelectStatement>
</co:hashTable>

<!-- Mapping-Zeile aus CSV-Import -->		
<mapping sourceField="CURRENT_LOCATION" clixField="LOCATION" hashident="MapLocationKeyWithId"  ignoreEmptyField="false"/>

OE-Gruppen-ID nachschlagen, um Nutzer zuzuordnen

Die folgenden Beispiele für hashTable- und AssignCommand-Regeln können verwendet werden, um Nutzer dynamisch OE-Gruppen zuzuweisen. Die assignCommand-Tags für Gruppen basieren auf der LMS-Objekt-ID, und dieses hashTable-Statement findet die Objekt-ID im Wesentlichen durch Nachschlagen der externen ID. In den assignCommand-Regeln ist der index das Nutzerattribut, das beim Import Werte enthält, die mit der externen ID der OE-Gruppen übereinstimmen. Solche Regeln werden üblicherweise für Kunden verwendet, die OE-Gruppenstrukturen in CSV-Dateien importieren können oder Strukturen über eine XML-Datei importieren können, aber nicht in der Lage sind, Nutzer direkt zu zuzuweisen.

<co:hashTable identifier="ORG_MAPPING" defaultValue="0" comment="maps section ids">
  <co:hashTableSelectStatement isIntAttribute="false">SELECT GROUP_ID FROM PLATFORMGROUP WHERE EXTERNAL_OBJECT_ID =?</co:hashTableSelectStatement>
</co:hashTable>
			
<co:rule>
  <co:assignCommand context="GROUP" target="_hashval" hashident="ORG_MAPPING" index="DIVISION" execute="ALWAYS" /> 
</co:rule>
<co:rule>
  <co:assignCommand context="GROUP" target="_hashval" hashident="ORG_MAPPING" index="UNIT" execute="ALWAYS" /> 
</co:rule>
<co:rule>
  <co:assignCommand context="GROUP" target="_hashval" hashident="ORG_MAPPING" index="TEAM" execute="ALWAYS" /> 
</co:rule>

Nutzer als Vorgesetzter einer OE-Gruppe zuordnen

Mit Regeln ist es auch möglich, Nutzer zu OE-Gruppen mit einer Vorgesetzten- oder Stellvertreterrolle zuzuordnen. Das folgende Beispiel verwendet eine HashTable, um die GROUP_ID der OE-Gruppe auf Grundlage des EXTERNAL_OBJECT_ID-Werts zu ermitteln. Anschließend identifiziert die Regel, ob der Nutzer einen bestimmten POSITION_TITLE hat, um einen assignCommand auszuführen, der auf der HashTable basiert, die den Wert des Nutzerattributs TEAM indiziert.

<co:hashTable identifier="ORG_MAPPING" defaultValue="0" comment="ordnet die externe ID der Objekt-ID zu">
  <co:hashTableSelectStatement isIntAttribute="false">SELECT GROUP_ID FROM PLATFORMGROUP WHERE EXTERNAL_OBJECT_ID =?</co:hashTableSelectStatement>
</co:hashTable>

<co:rule>
  <co:ruleConditions>
    <co:orCondition>
      <co:ruleCondition expression="POSITION_TITLE" matching="HASSUBSTRING" value="Manager"/>
      <co:ruleCondition expression="POSITION_TITLE" matching="HASSUBSTRING" value="Supervisor"/>
    </co:orCondition>
  </co:ruleConditions>
  <assignCommand context="GROUP" target="_hashval" hashident="ORGUNIT" index="TEAM" type="SUPERVISOR" execute="ALWAYS" />
</co:rule>

<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="POSITION_TITLE" matching="HASSUBSTRING" value="2IC"/>
  </co:ruleConditions>
  <assignCommand context="GROUP" target="_hashval" hashident="ORGUNIT" index="TEAM" type="DEPUTY1" execute="ALWAYS" />
</co:rule>

Jobprofil-ID nachschlagen, um Nutzer zuzuordnen

Die nachfolgenden Beispiele für hashTable- und assignCommand-Regel können verwendet werden, um Nutzern auf Grundlage einer Übereinstimmung dynamisch Jobprofile zuzuordnen. Die assignCommands für Jobprofile basieren auf der LMS-Objekt-ID, und dieses hashTable-Statement findet das Jobprofil mit dem Namen, der dem Wert eines Nutzerattributs entspricht. In der assignCommand-Regel ist der index das Nutzerattribut, das Werte enthält, die mit den Namen der Jobprofile übereinstimmen. Solche Regeln werden in der Regel von Kunden mit dem Zusatzmodul Skills & competencies verwendet, um automatisch bestimmte Jobprofile zuzuordnen, die die für den Nutzer erforderlichen Fähigkeiten enthalten.

<co:hashTable identifier="MapJP" defaultValue="0" comment="Ordnet den Namen des Auftragsprofils der Objekt-ID zu">
	<co:hashTableSelectStatement isIntAttribute="false">SELECT max(role_id) FROM role_description WHERE name = ? AND language_id = 27</co:hashTableSelectStatement>
</co:hashTable>

<co:rule>
  <co:assignCommand context="JOBPROFILE" target="_hashval" index="POSITION_TITILE" hashident="MapJP" execute="ALWAYS"/>
</co:rule>

Vorgesetzten nachschlagen

Um eine Eins-zu-Eins-Beziehungen zu Vorgesetzten herzustellen, verwendet die Learning Suite das Nutzerattribut SUPERVISOR_EMAIL. Die Logik identifiziert den Nutzer, dessen EMAIL mit dem in SUPERVISOR_EMAIL des Nutzers eingegebenen Wert übereinstimmt und erstellt einen Link. Da viele Quellsysteme, die zur Erstellung von Nutzerkonten verwendet werden, jedoch nicht über ein solches Feld für die E-Mail des Vorgesetzten verfügen, sind oft alternative Regeln erforderlich. Im folgenden Beispiel enthalten die mandantenspezifischen Nutzerattribute EMPLOYEE_ID und MANAGER_ID die entsprechende Beziehung. Die Hash-Tabelle verwendet den Wert des mandantenspezifischen Nutzerattributs, um Details über den Vorgesetzten im System zu finden. Die setCommand-Regeln füllen dann die Standard-Nutzerattribute des Vorgesetzten basierend auf der Hash-Tabelle auf, die den Nutzer mit dem zum mandantenspezifischen Nutzerattribut passenden Wert identifiziert.

<!-- People Leader Assignments: -->
<!-- SUPERIROR_EMAIL -->
<co:hashTable identifier="SUP_EMAIL" defaultValue="" comment="Ruft die E-Mail-Adresse des Vorgesetzten aus der Eingabe MANAGER_ID ab, die mit der EMPLOYEE_NUMBER des Vorgesetzten abgeglichen wird.">
	<co:hashTableSelectStatement isIntAttribute="false">select P.EMAIL FROM PERSON P, PERSON_CUSTOM PC WHERE P.EXTERNAL_ID = ?</co:hashTableSelectStatement>
</co:hashTable>

<!-- SUPERIROR_FIRSTNAME -->
<co:hashTable identifier="SUP_FIRST" defaultValue="" comment="Ruft den Vornamen des Vorgesetzten aus der Eingabe MANAGER_ID ab, die mit der EMPLOYEE_NUMBER des Vorgesetzten abgeglichen wird.">
	<co:hashTableSelectStatement isIntAttribute="false">select P.FIRSTNAME FROM PERSON P, PERSON_CUSTOM PC WHERE P.EXTERNAL_ID = ?</co:hashTableSelectStatement>
</co:hashTable>

<!-- SUPERIROR_LASTNAME -->
<co:hashTable identifier="SUP_LAST" defaultValue="" comment="<co:hashTable identifier="SUP_LAST" defaultValue="" comment="Ermittelt den Nachnamen des Vorgesetzten aus der Eingabe MANAGER_ID, die mit der EMPLOYEE_NUMBER des Vorgesetzten abgeglichen wird">">
	<co:hashTableSelectStatement isIntAttribute="false">select P.LASTNAME FROM PERSON P, PERSON_CUSTOM PC WHERE P.EXTERNAL_ID = ?</co:hashTableSelectStatement>
</co:hashTable>
			
<co:rule>
	<co:ruleConditions>
		<co:ruleCondition expression="MANAGER_ID" matching="ISNOTEMPTY"/>
	</co:ruleConditions>
	<co:setCommand target="SUPERIOR_EMAIL" value="_hashval" hashident="SUP_EMAIL" index="MANAGER_ID" />
	<co:setCommand target="SUPERIOR_FIRSTNAME" value="_hashval" hashident="SUP_FIRST" index="MANAGER_ID" />
	<co:setCommand target="SUPERIOR_LASTNAME" value="_hashval" hashident="SUP_LAST" index="MANAGER_ID" />
</co:rule>
<!-- End People Leader Assignments -->

Länder-, Sprach- und Zeitzonenzuordnungen

Wie die Scheer IMC sind auch viele ihrer Kunden multinational und haben Niederlassungen in mehreren Ländern. Das bedeutet, dass die Learning Suite wahrscheinlich mit mehreren Sprachen und nutzerspezifischen Zeitzonen konfiguriert wird. Durch Regeln können effizient Nutzerattribut-Werte für das Land, die bevorzugte Sprache und die Zeitzone des Nutzers festgelegt werden. Regeln sind meist erforderlich, da verschiedene Nutzerdaten-Quellsysteme unterschiedliche Werte enthalten.

Ländercode-Mapping

Nachfolgend ist ein Beispiel für eine Hash-Tabelle dargestellt, die iso-Ländercodes aus einem Quellsystem den entsprechenden Länder-IDs im Nutzerattribut COUNTRY_ID der Learning Suite-Auswahlliste zuordnet.

<co:hashTable identifier="COUNTRY_MAP" defaultValue="0" comment="Zuordnung von ISO-Code zu Länderkennung">
  <co:hashTableRow index="DE" value="82" comment="Germany"/>
  <co:hashTableRow index="Germany" value="82" comment="Germany"/>
  <co:hashTableRow index="GERMANY" value="82" comment="Germany"/>
  <co:hashTableRow index="DEUTSCHLAND" value="82" comment="Germany"/>
  <co:hashTableRow index="Deutschland" value="82" comment="Germany"/>
  <co:hashTableRow index="CH" value="209" comment="Switzerland"/>
  <co:hashTableRow index="Switzerland" value="209" comment="Switzerland"/>
  <co:hashTableRow index="RO" value="180" comment="Romania"/>
  <co:hashTableRow index="RU" value="180" comment="Romania"/>
  <co:hashTableRow index="Romania" value="180" comment="Romania"/>
  <co:hashTableRow index="SG" value="193" comment="Singapore"/>
  <co:hashTableRow index="SGP" value="193" comment="Singapore"/>
  <co:hashTableRow index="Singapore" value="193" comment="Singapore"/>
  <co:hashTableRow index="AT" value="14" comment="Austria"/>
  <co:hashTableRow index="Austria" value="14" comment="Austria"/>
  <co:hashTableRow index="Österreich" value="14" comment="Austria"/>
  <co:hashTableRow index="NZ" value="157" comment="New Zealand"/>
  <co:hashTableRow index="New Zealand" value="157" comment="New Zealand"/>
  <co:hashTableRow index="AU" value="13" comment="Australia"/>
  <co:hashTableRow index="AUS" value="13" comment="Australia"/>
  <co:hashTableRow index="Australia" value="13" comment="Australia"/>
  <co:hashTableRow index="Australien" value="13" comment="Australia"/>
  <co:hashTableRow index="AUSTRALIA" value="13" comment="Australia"/>
  <co:hashTableRow index="Croatia" value="54" comment="Croatia"/>
  <co:hashTableRow index="HR" value="54" comment="Croatia"/>
  <co:hashTableRow index="GB" value="227" comment="United Kingdom"/>
  <co:hashTableRow index="UK" value="227" comment="United Kingdom"/>
  <co:hashTableRow index="United Kingdom" value="227" comment="United Kingdom"/>
  <co:hashTableRow index="United States" value="228" comment="United States"/>
  <co:hashTableRow index="US" value="228" comment="United States"/>
  <co:hashTableRow index="USA" value="228" comment="United States"/>
  <co:hashTableRow index="Netherlands" value="154" comment="Netherlands"/>
  <co:hashTableRow index="NL" value="154" comment="Netherlands"/>
  <co:hashTableRow index="BA" value="27" comment="Netherlands"/>
  <co:hashTableRow index="Bosnia-Herz." value="27" comment="Netherlands"/>
</co:hashTable>
	
<!-- COUNTRY -->
<co:rule>
  <co:setCommand target="COUNTRY_ID" value="_hashval" hashident="COUNTRY_MAP" index="COUNTRY"/>
</co:rule>

Sprachen-Mapping

Mit Sprachattributen können diese der COUNTRY_ID zugeordnet werden, um die dem Nutzer angezeigten System- und Inhaltssprachen vorzudefinieren. Die nachstehende Regel stammt aus einem System, das die Sprachen Englisch (GB) und Deutsch anbietet. In diesem System ist die Standardsprache in den Nutzerattributen als Englisch (GB) definiert, so dass die Regel eine Hash-Tabelle verwendet, um die deutschsprachigen Länder-IDs der deutschen Sprach-ID zuzuordnen. Dann identifiziert die Bedingung der Regel nur Nutzer, die sich noch anmelden müssen, und setzt zwei Nutzerattribute für die Sprache auf Grundlage der Hash-Tabellen-Zuordnung. Durch die Verwendung von COUNTOFLOGINS wird sichergestellt, dass die Regeln die Sprachen nicht erneut ändern, wenn der Nutzer sich entscheidet, seine bevorzugte Sprache zu wechseln.

<co:hashTable identifier="SET_LANGUAGE" defaultValue="27">
  <co:hashTableRow index="14" value="23" comment="AT"/>
  <co:hashTableRow index="82" value="23" comment="DE"/>
  <co:hashTableRow index="209" value="23" comment="CH"/>
</co:hashTable>

<!-- SET INITIAL VALUES -->
<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="COUNTOFLOGINS" matching="EQUAL" value="0"/>
  </co:ruleConditions>
  <co:setCommand target="LANGUAGE_ID" value="_hashval" hashident="SET_LANGUAGE" index="COUNTRY_ID" />
  <co:setCommand target="PREFERRED_LANGUAGE_ID" value="_hashval" hashident="SET_LANGUAGE" index="COUNTRY_ID" />
</co:rule>

Zeitzonen-Mappings

Das Nutzerattribut TIMEZONE_ID ist eine wichtige Einstellung, die von den Nutzern aktualisiert werden muss, da die ausgewählte Zeitzone die angezeigten Kursdaten/-zeiten verändern kann. Dieses Attribut kann auch automatisch aktualisiert werden, indem Regeln für die Werte anderer Nutzerattribute wie COUNTRY oder eine benutzerdefinierte LOCATION verwendet werden. Diese Regeln können für jede erforderliche Zeitzone einzeln oder als Hash-Tabelle geschrieben werden. Für die Regeln werden die IDs für jede Zeitzone benötigt, die Sie unter Zeitzonen einsehen können.

Eine Überlegung bei Zeitzonen ist, dass es Länder wie Australien, Kanada und die Vereinigten Staaten von Amerika gibt, die sich über mehrere Zeitzonen erstrecken; in diesem Fall ist ein kundenspezifisches Nutzerattribut für bestimmte Orte (z. B. Bundesstaat, Büro, Stadt) genauer.

<!-- Zeitzonen einstellen -->
<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="OFFICE_LOCATION" matching="Berlin" mode="VALUE"/>
  </co:ruleConditions>
  <co:setCommand target="TIMEZONE_ID" value="121" execute="ONCE"/>
</co:rule>
<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="OFFICE_LOCATION" matching="London" mode="VALUE"/>
  </co:ruleConditions>
  <co:setCommand target="TIMEZONE_ID" value="96" execute="ONCE"/>
</co:rule>
<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="OFFICE_LOCATION" matching="Sydney" mode="VALUE"/>
  </co:ruleConditions>
  <co:setCommand target="TIMEZONE_ID" value="103" execute="ONCE"/>
</co:rule>

Die verwendete Hash-Tabelle enthält mehrere Zeilen, in denen der Index auf einen Wert abgebildet wird, der der Objekt-ID jedes Wertes im Nutzerattribut TIMEZONE_ID der Auswahlliste entspricht.

<co:hashTable identifier="TIMEZONE_MAP" defaultValue="0" comment="Zuordnung von iso-Land zu Zeitzonen-ID">
  <co:hashTableRow index="DE" value="121" comment="Germany"/>
  <co:hashTableRow index="Germany" value="121" comment="Germany"/>
  <co:hashTableRow index="GERMANY" value="121" comment="Germany"/>
  <co:hashTableRow index="DEUTSCHLAND" value="121" comment="Germany"/>
  <co:hashTableRow index="Deutschland" value="121" comment="Germany"/>
  <co:hashTableRow index="CH" value="121" comment="Switzerland"/>
  <co:hashTableRow index="Switzerland" value="121" comment="Switzerland"/>
  <co:hashTableRow index="RO" value="122" comment="Romania"/>
  <co:hashTableRow index="RU" value="122" comment="Romania"/>
  <co:hashTableRow index="Romania" value="122" comment="Romania"/>
  <co:hashTableRow index="SG" value="80" comment="Singapore"/>
  <co:hashTableRow index="SGP" value="80" comment="Singapore"/>
  <co:hashTableRow index="Singapore" value="80" comment="Singapore"/>
  <co:hashTableRow index="AT" value="121" comment="Austria"/>
  <co:hashTableRow index="Austria" value="121" comment="Austria"/>
  <co:hashTableRow index="Österreich" value="121" comment="Austria"/>
  <co:hashTableRow index="NZ" value="71" comment="New Zealand"/>
  <co:hashTableRow index="New Zealand" value="71" comment="New Zealand"/>
  <co:hashTableRow index="AU" value="103" comment="Australia"/>
  <co:hashTableRow index="AUS" value="103" comment="Australia"/>
  <co:hashTableRow index="Australia" value="103" comment="Australia"/>
  <co:hashTableRow index="Australien" value="103" comment="Australia"/>
  <co:hashTableRow index="AUSTRALIA" value="103" comment="Australia"/>
  <co:hashTableRow index="Croatia" value="122" comment="Croatia"/>
  <co:hashTableRow index="HR" value="122" comment="Croatia"/>
  <co:hashTableRow index="GB" value="96" comment="United Kingdom"/>
  <co:hashTableRow index="UK" value="96" comment="United Kingdom"/>
  <co:hashTableRow index="United Kingdom" value="96" comment="United Kingdom"/>
  <co:hashTableRow index="United States" value="94" comment="United States Pacific time"/>
  <co:hashTableRow index="US" value="94" comment=94"United States Pacific time"/>
  <co:hashTableRow index="USA" value="94" comment="United States Pacific time"/>
  <co:hashTableRow index="Netherlands" value="121" comment="Netherlands"/>
  <co:hashTableRow index="NL" value="121" comment="Netherlands"/>
  <co:hashTableRow index="BA" value="121" comment="Netherlands"/>
  <co:hashTableRow index="Bosnia-Herz." value="122" comment="Bosnia"/>
</co:hashTable>
	
<!-- COUNTRY -->
<co:rule>
  <co:setCommand target="TIMEZONE_ID" value="_hashval" hashident="TIMEZONE_MAP" index="COUNTRY"/>
</co:rule>

Erweiterte Berechnungen und Verarbeitung

Regeln sind in der Lage, Berechnungen oder Prozesse mit Hilfe einzelner SQL-Statements durchzuführen. Solche Regeln erfordern SQL-Kenntnisse und ein Verständnis der Learning Suite-Datenbank. Nachfolgend finden Sie einige Beispiele von Kunden, die SQL verwenden, um einen Wert in einem setCommand zu generieren.

Die folgende Regel berechnet das Alter des Lernenden in ganzen Jahren auf Grundlage der Differenz zwischen dem aktuellen Datum und seinem Geburtsdatum. Dies wurde von einem Kunden benötigt, der ein Mindestalter für die Einschreibung in einige Schulungskurse festgelegt hat.

<!-- Berechnung der Jahre seit DOB START -->
<co:hashTable identifier="YEARS_SINCE_DOB" defaultValue="0" comment="Mapping of Years since DOB">
  <co:hashTableSelectStatement isIntAttribute="false">SELECT datediff(hh,?,getdate())/8766</co:hashTableSelectStatement>
</co:hashTable>
			
<!--<co:hashTableSelectStatement isIntAttribute="false">SELECT datediff(yy,?, current_timestamp)</co:hashTableSelectStatement>-->
<co:rule> 
  <co:setCommand value="_hashval" target="AGE" hashident="YEARS_SINCE_DOB" index="DATE_OF_BIRTH"/>
</co:rule>
<!-- Berechnung der Jahre seit DOB END -->

Die folgende Regel berechnet die Anzahl der Beschäftigungstage auf Grundlage der Differenz zwischen dem aktuellen Datum und dem Datum des Beschäftigungsbeginns. Diese Berechnung wurde von einem Kunden verwendet, der bestimmte Zeitfenster für die Teilnahme an Compliance-Kursen auf Grundlage der Tage seit der Einstellung hatte.

<co:hashTable identifier="DAYS_SINCE_EMPL" defaultValue="0" comment="Berechnung der Tage seit der Beschäftigung">
  <co:hashTableSelectStatement isIntAttribute="false">SELECT datediff(d,?, current_timestamp)</co:hashTableSelectStatement>
</co:hashTable>

<co:rule> 
  <co:setCommand value="_hashval" target="DAYS_SINCE_EMPLOYMENT" hashident="DAYS_SINCE_EMPL" index="EMPLOYMENT_START_DATE"/>
</co:rule>

Die folgende Regel verknüpft zwei Werte, um einen bestimmten Wert zu erhalten. In diesem Fall benötigte der Kunde eine E-Mail-Adresse, die die Handynummer des Nutzers enthält, um grundlegende Nachrichten als SMS zu versenden. Diese Regel kann auch mit Opt-in-Regeln erweitert werden.

<co:hashTable identifier="addDomain" defaultValue="unknown" >
  <co:hashTableSelectStatement isIntAttribute="false">SELECT ? + '@email.smsglobal.com' </co:hashTableSelectStatement>
</co:hashTable>			

<!-- Email to SMS Address Building -->
<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="WORK_MOBILE" matching="ISNOTEMPTY"/>
  </co:ruleConditions>	
  <co:setCommand target="SMS_EMAIL" value="_hashval" hashident="addDomain" index="WORK_MOBILE"/>
</co:rule>	

Datumsumwandlungen

Beim Import von Nutzerattributen ist das spezifische Datum / Uhrzeit Format der Leraning Suite JJJJ-MM-TT hh:mm:ss.s erforderlich. Dieses Format kann von den Quellsystemen der Nutzerdaten nicht immer exportiert werden und muss möglicherweise mit Hilfe von Registrierungsregeln umgewandelt werden. Dies kann durch eine Hash-Tabelle mit einer spezifischen Statement erreicht werden, die das eingegebene Datumsformat berücksichtigt. In Anbetracht der unterschiedlichen Datumsformate und Statements sollten solche Anforderungen bei Bedarf mit imc besprochen werden. Nachstehend finden Sie einige Beispielumwandlungen.

<co:hashTable identifier="DATUM" defaultValue="" comment="Date from YYYYMMDD to YYYY-MM-DD hh:mm:ss">
  <co:hashTableSelectStatement isIntAttribute="false">SELECT CONVERT(Datetime,LEFT(?,23),126)
  </co:hashTableSelectStatement>
</co:hashTable>

<co:hashTable identifier="ENGLISH_DATE" defaultValue="" comment="Date from English format">
  <co:hashTableSelectStatement isIntAttribute="false">SELECT CONVERT(datetime, ?,103);</co:hashTableSelectStatement>
</co:hashTable>

<co:hashTable identifier="DATE_CONVERSION" defaultValue="" comment="">
  <co:hashTableSelectStatement isIntAttribute="false">select convert(varchar, ?, 121) + ' 00:00:00.0'</co:hashTableSelectStatement>
</co:hashTable>
			
<co:rule>
  <co:ruleConditions>
    <co:ruleCondition expression="HIRE_DATE" matching="ISNOTEMPTY" />
  </co:ruleConditions>
  <co:setCommand target="EMP_START_DATE" value="_hashval" hashident="DATE_CONVERSION" index="HIRE_DATE" />
</co:rule>

Zusammenfassung

Dieser Artikel enthält Informationen über den Zweck, die Möglichkeiten, die Vorteile, die Formate und verschiedene Beispiele von Registrierungsregeln. Wie man sieht, kann die Verwendung von Registrierungsregeln viele Effizienzgewinne bringen und ist eine sehr wichtige Konfiguration. Obwohl Registrierungsregeln für Systemadministratoren zugänglich sind, wird dringend empfohlen, Anforderungen oder Ideen mit Scheer imc Consultants zu besprechen, die in diesem Bereich erfahren sind.

📋 Verwandte Artikel

Nutzer-Attribute