Eine der Stärken der Versionen 6.9 und höher von ConSol CM ist die große Flexibilität des Kundendatenmodells (FlexCDM) und GUI-Designs. Als Administrator können Sie alle benötigten Datenfelder definieren und an der gewünschten Stelle der Benutzeroberfläche platzieren. Das Grundprinzip ist jetzt das gleiche, das Sie bereits von den Benutzerdefinierten Feldern für Ticketdaten kennen: völlige Flexibilität.
Die Verwaltung des Ticketdatenmodells und das GUI-Design werden im Abschnitt Verwaltung von Benutzerdefinierten Feldern (Einrichten des Ticketdatenmodells) erklärt. Die Verwaltung von Objekten innerhalb des Kundendatenmodells wird im Abschnitt Einrichten des Kundendatenmodells detailliert erklärt. Bitte lesen Sie dort die entsprechenden Abschnitte. In diesem Kapitel gehen wir davon aus, dass Sie mit diesen Themen bereits vertraut sind.
Die Definition von Kundendatenfeldern ist Bestandteil der Definition des gesamten Kundendatenmodells, siehe Abschnitt Einrichten des Kundendatenmodells. Das Datenmodell wird im Admin Tool im Navigationselement Datenmodelle der Navigationsgruppe Kunden definiert.
Die Datenfelder für Datenobjekte innerhalb des Kundendatenmodells heißen Datenobjektgruppenfelder. Die Arbeit mit Datenobjektgruppenfeldern basiert auf den gleichen Prinzipien wie die Arbeit mit Ticketdatenfeldern (Benutzerdefinierten Feldern): Die Datenfelder werden in Gruppen verwaltet und sowohl die Gruppen als auch die einzelnen Felder können annotiert werden.
Abbildung 220: ConSol CM Admin Tool - Definition von Datenobjektgruppenfeldern
Wie die Benutzerdefinierten Felder, die Sie bereits aus früheren CM-Versionen kennen, werden auch die Datenobjektgruppenfelder in Gruppen angelegt, den Datenobjektgruppen. Jedes Datenobjekt eines Kundendatenmodells kann so viele Datenobjektgruppen haben, wie nötig sind. So kann zum Beispiel eine Firma im Händlerdatenmodell eine Datenobjektgruppe für allgemeine Daten haben, eine für Vertragsdaten und eine für die Personen, die für diesen Händler zuständig sind. Für die Kontakte innerhalb des Händlerdatenmodells wird eine Datenobjektgruppe mit allgemeinen Daten definiert.
Abbildung 221: ConSol CM Admin Tool - Kundendatenmodell mit mehreren Datenobjektgruppen
Die Organisation der Datenfelder in Gruppen hat mehrere Auswirkungen. Stellen Sie sicher, dass das Design des Datenmodells den Bedürfnissen der Benutzer entspricht.
Eine Datenobjektgruppe...
Abbildung 222: ConSol CM Web Client - Firmendaten in Tabs (basierend auf Datenobjektgruppen)
Die Definition von Datenobjektgruppenfeldern (d. h. Datenfeldern wie Name, Adresse oder Telefonnummer) basiert auf dem bewährten Prinzip, das seit der ersten CM6-Version bereits für die Benutzerdefinierten Felder verwendet wurde.
Ein Datenobjektgruppenfeld...
Im Gegensatz zu den Benutzerdefinierten Feldern und dem Layout von Tickets, wo für die Datenfelder nur drei Spalten zur Verfügung stehen, können Sie für die Definition von Datenobjektgruppenfeldern so viele Spalten verwenden, wie Sie möchten.
Beachten Sie bitte, dass bis einschließlich CM-Version 6.10.4 das Business Card Feature greift, d. h. um Kundendaten immer bündig anzuordnen, werden alle Felder einer Zeile immer linksbündig angeordnet (d. h. beginnend mit Spalte 0), auch wenn das erste Feld in der Zeile erst in Spalte 2 (oder einer anderen) positioniert ist (Annotation position).
In CM-Versionen vor 6.9.4 wurden die Labels von Datenobjektgruppenfeldern (z. B. Name, Adresse) im Web Client standardmäßig als Wasserzeichen angezeigt. Wenn ein anderes Label benötigt wird, muss ein eigenes Datenobjektgruppenfeld des Typs string mit der Annotation text-type = label verwendet werden, wie in den folgenden Abbildungen dargestellt ist.
Abbildung 223: ConSol CM Web Client - Standardanzeige der Labels von Datenobjektgruppenfeldern in Versionen vor 6.9.4
Abbildung 224: ConSol CM Web Client - Label als eigenständige Datenobjektgruppenfelder in Versionen vor 6.9.4
Ab CM-Version 6.9.4 können Sie als Administrator entscheiden, ob Wasserzeichen oder Labels (oder beides) verwendet werden sollen. Labels sind jetzt auf eine ähnliche Weise implementiert wie die Labels von Benutzerdefinierten Feldern (d. h. Datenfeldern für Ticketdaten). Außerdem können Tooltips hinzugefügt werden. Der Anzeigemodus der Labels von Datenobjektgruppenfeldern wird über Annotationen gesteuert. Annotationen können für Datenobjektgruppen oder einzelne Datenobjektgruppenfelder gesetzt werden. Die Feldannotationen überschreiben dabei die Gruppenannotationen. Auf diese Weise können Sie ein Verhalten für die Anzeige der Gruppe definieren und es für ein oder mehrere Einzelfelder ändern. Dies ist im folgenden Beispiel erklärt.
Annotationen für Datenobjektgruppen:
Annotationen für Datenobjektgruppenfelder:
Abbildung 225: ConSol CM Admin Tool - Konfiguration der Datenobjektgruppe Reseller, ein Feld mit eigener Konfiguration
Abbildung 226: ConSol CM Web Client - Ansicht der Datenobjektgruppe Reseller, ein Feld (company_name) mit eigener Annotation (Bearbeitungsmodus)
Abbildung 227: ConSol CM Web Client - Ansicht der Datenobjektgruppe Reseller, ein Feld (company_name) mit eigener Annotation (Beispiel: keine Auswirkungen auf Ansichtsmodus)
Die Labels werden automatisch eingefügt, sodass es am Ende bis zu sechs Spalten geben kann. Im folgenden Beispiel werden zwei Spalten verwendet.
Abbildung 228: Beispiel für die Position von Datenobjektgruppenfeldern im Raster
Das Layout des Kundenmodells wird beim Update beibehalten! Alle Annotationen werden entsprechend gesetzt und können später geändert werden.
Für alle vorhandenen Datenobjektgruppen wird die layout-Annotation: show-labels-in-edit = false (mit der die Standard-Labels im Bearbeitungsmodus ausgeblendet werden) beim Update gesetzt.
Alle neuen Datenobjektgruppen werden entsprechend der neuen Standardkonfiguration angezeigt. Das bedeutet:
Abbildung 229: ConSol CM Web Client - Standardanzeigemodus für Datenobjektgruppenfelder
In diesem Handbuch werden die Begriffe Kunde und Kundendefinition verwendet. Die entsprechenden Skripte verwenden allerdings den Begriff Datenobjekt und die Namen der entsprechenden Java-Klassen sind Unit und UnitDefinition. Alle anderen Java-Klassen, die Kundenobjekte verarbeiten, heißen ebenfalls noch Unit... Beachten Sie dies bei Ihrer Arbeit als ConSol CM-Administrator und -Programmierer. Details finden Sie in der ConSol CM Java API Doc.
Bis ConSol CM-Version 6.8 konnte eine Unit nur eine Benutzerdefinierte Feldgruppe haben. Der Ausdruck unit.get("name") war immer gültig, weil ein Benutzerdefiniertes Feld mit einem bestimmten Namen nur einmal vorkommen konnte, zum Beispiel group1.name.
Ab ConSol CM-Version 6.9 kann ein Datenobjekt (Unit) ein oder mehrere Datenobjektgruppenfelder mit dem gleichen Namen haben. So kann sich z. B. "name" auf "group1.name" oder "group2.name" beziehen. In solchen Fällen ist der Ausdruck Unit.get("name") nicht gültig und führt zu einer Exception.
Für die Rückwärtskompatibilität funktioniert der Code unit.get("name"), solange das Benutzerdefinierte Feld "name" eindeutig ist. Wenn ein weiteres Benutzerdefiniertes Feld mit dem gleichen Namen hinzugefügt wird, funktioniert der Code unit.get("name") nicht mehr!
Verwenden Sie folgende Notation, um Daten aus Unit-Feldern (Datenobjektgruppenfeldern) abzurufen:
unit.get("contactFields:companyReference.companyFields:name")
Code-Beispiel 14: Beispiel für den Abruf des Firmennamens eines Kontakts
Ab ConSol CM-Version 6.9 wurde die Custom Field Expression Language (CFEL) verbessert, um einfachen Zugriff auf viele Objekte zu ermöglichen. Dies betrifft Skripte für Tickets und andere Objekte sowie Objekte aus dem Kundendatenmodell, d. h. Units (Datenobjekte: Objekte auf Kontakt- oder Firmenstufe). Im Folgenden werden die Verbesserungen bezüglich Units (Datenobjekten) erklärt. Eine detaillierte Beschreibung über das Schreiben von Java- oder Groovy-Code, der Objekte aus dem Kundendatenmodell verwendet, finden Sie im ConSol CM Process Designer Handbuch.
Sie können aus unterschiedlichen Skripten auf Objekte des Kundendatenmodells zugreifen:
In ConSol CM-Version 6.9 wurden einige Methoden für veraltet (deprecated) erklärt und müssen durch neue Methoden ersetzt werden. Dies ist nur relevant, wenn Sie Skripte aus Version 6.8 oder älter haben. In diesem Fall müssen die Skripte unter Verwendung der neuen Methoden umgeschrieben werden.
Die Zugriffsmethoden für die einzelnen Typen von Benutzerdefinierten Feldern wurden entfernt.
|
Entfernte/geänderte Methode |
Ersatz |
|---|---|
|
|
|
|
|
|
Die Zugriffsmethoden über die reine FieldDefinition wurden entfernt; verwenden Sie stattdessen ActivityFormElement.
|
Entfernte/geänderte Methode |
Ersatz |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Der Größenparameter wurde für inputstream-Methoden hinzugefügt.
|
Entfernte/geänderte Methode |
Ersatz |
|---|---|
|
|
|
|
|
|
Die gleichen Änderungen wie für ContentFile.
|
Entfernte/geänderte Methode |
Ersatz |
|---|---|
|
|
|
|
|
|
Die Zugriffsmethoden auf Änderungen wurden entfernt.
|
Entfernte/geänderte Methode |
Ersatz |
|---|---|
|
|
|
|
|
|
Die umbenannten Zugriffsmethoden auf Benutzerdefinierte Felder wurden entfernt und weitere Änderungen.
|
Entfernte/geänderte Methode |
Ersatz |
|---|---|
|
|
Zuvor funktionierte das Vermischen der Parameter groupName und fieldName, jetzt wird nur noch die Reihenfolge groupName, fieldName akzeptiert. |
|
|
|
|
|
|
|
|
|
|
|
Für Verwendung im Workflow:
|
Die Methode setDuedate wurde entfernt.
|
Entfernte/geänderte Methode |
Ersatz |
|---|---|
|
|
|
Die umbenannten Zugriffsmethoden auf Benutzerdefinierte Felder wurden entfernt.
|
Entfernte/geänderte Methode |
Ersatz |
|---|---|
|
|
|
|
|
|
|
|
|
Beispiele für neue Methoden:
| Object.Method | Erklärung |
|---|---|
|
|
Mit CFEL ("contacts()") wird eine Liste aller Kontakt aus der Firma (Unit) abgerufen. |
Unit company = mainContact.getCompany()
|
Für einen Kontakt kann die Firma einfach abgerufen werden. |
newContact.set("company()", newCompany)
|
Für einen (neuen) Kontakt wird der Firma der CFEL-Ausdruck "company()" zugewiesen, der einen einfachen Zugriff auf das Firmenobjekt ermöglicht. |
List tickets = company.get("tickets()")
|
Es werden alle Tickets für eine Firma abgerufen. |
|
|
Es werden alle Tickets für einen Kontakt abgerufen. |
Integer count = contact.get("company().contacts()[0].tickets()[count]");
|
Ein Kettenausdruck, mit dem die Anzahl der Tickets für einen bestimmten Kontakt abgerufen wird. |
TicketCriteria ticketCriteria = new TicketCriteria();
Unit patternContact = new Unit("contact", customerGroup);
mdcmCriteriaBuilder.setReferencedContactCriteria(ticketCriteria, patternContact);
Code-Beispiel 15: Beispiel 1: Suche nach den Tickets eines Kontakts oder einer Firma
TicketCriteria ticketCriteria = new TicketCriteria();
Unit contactPattern = new Unit("contact", customerGroup);
mdcmCriteriaBuilder.setReferencedContactCriteria(ticketCriteria, contactPattern);
Unit companyPattern = new Unit("company", customerGroup);
companyPattern.setFieldValue("name", „ConSol");
mdcmCriteriaBuilder.setReferencedCompanyCriteria(contactPattern, companyPattern);
Code-Beispiel 16: Suche nach den Tickets eines Kontakts, der zu einer bestimmten Firma gehört
UnitCriteria unitCriteria = new UnitCriteria();
Unit companyPattern = new Unit("company", customerGroup);
mdcmCriteriaBuilder.setReferencedCompanyCriteria(unitCriteria, companyPattern);
Code-Beispiel 17: Suche nach Kontakten einer bestimmten Firma
Detaillierte Informationen über die Methoden einschließlich der Eingabeparameter (Methodensignaturen) und der Ausgabedatentypen finden Sie in der ConSol CM Java API Doc.
Welche Objekte im Skript verfügbar sind, hängt natürlich vom Kontext des Skripts ab. Die folgenden Beispiele zeigen einige mögliche Anwendungsfälle:
| Ausgangspunkt | Skript | Objekte | Beispiel |
|---|---|---|---|
| Firmenseite |
Datenobjekt-Aktionsskript |
unit steht für die Firma |
def contacts = unit.get("contacts()")
|
| Kontaktseite |
Datenobjekt-Aktionsskript |
unit steht für den Kontakt |
List tickets = unit.get("tickets()")
|
| Workflow-Aktivität | Skript für Workflow-Aktion oder -Bedingung | ticket | def id = ticket.getId()
|
| Workflow-Aktivität mit Admin-Tool-Skript | Skript für Workflow-Aktion oder -Bedingung | ticket ist nicht implizit vorhanden! |
|