Data Object Group Field Management and GUI Design for Customer Data

Introduction

One feature of ConSol CM versions 6.9 and later is great flexibility as far as customer data model (FlexCDM) and GUI design are concerned. You, as an administrator, can define any data field which is required and place it in the user interface wherever it is suitable. The basic principle is now the same as the one you know for ticket Custom Fields: full flexibility.

The management of the ticket data model and GUI design is explained in section Custom Field Administration (Setting Up the Ticket Data Model). The management of objects within the customer data model is explained in section Setting Up the Customer Data Model. Please refer to those sections for a detailed explanation. In this chapter, we assume that you have a working knowledge of those topics.

Defining Data Object Group Fields for Customer Data Using the Admin Tool

Admin Tool GUI

The data field definition for customer data is part of the definition of the entire customer data model, see section Setting Up the Customer Data Model. The data model is defined on the navigation item Data Models in the navigation group Customers, in the Admin Tool.

Data fields for data objects within the customer data model are called Data Object Group Fields. Data Object Group Fields are based on the same principles as ticket data fields (Custom Fields): data fields are managed in groups and the groups, as well as the single fields, can be annotated.

Figure 161: ConSol CM Admin Tool - Definition of Data Object Group Fields

Data Object Groups

Like the Custom Fields which you are already familiar with from previous CM versions, Data Object Group Fields are placed in groups, the Data Object Groups. Each data object within a customer data model can have as many Data Object Groups as required. For example, for a reseller company there can be a Data Object Group for the general data, one for the contract data, and one for the persons who are responsible for this reseller. For contacts within the reseller data model, one Data Object Group with general data is defined.

Figure 162: ConSol CM Admin Tool - Customer data model with several data object groups

The organization of data fields in groups has several implications. Please keep them in mind to make sure your data model design meets the users' needs.

A Data Object Group ...

Figure 163: ConSol CM Web Client - Company data organized in tabs (based on Data Object Groups)

Data Object Group Field Definition

The definition of Data Object Group Fields (i.e., data fields like name, address, or phone number) is based on the proven concepts which have been used for Custom Fields since the first CM6 version.

A Data Object Group Field ...

In contrast to Custom Fields and ticket layout, where you can use three columns for data fields, you can use as many data field columns as you like for the definition of Data Object Group Fields.

Please keep in mind that in CM versions 6.10.4 and below, the Business Card Feature will be active, i.e. in order to present all customer data aligned as on a business card, all fields of a line are presented left-aligned (i.e. starting with column #0), even if the first field in the line has the position column #2 (or other) according to the position annotation.

Labels for Data Object Group Fields

In CM versions prior to 6.9.4, the labels for Data Object Group Fields (e.g., name, address) are displayed in the Web Client as watermarks per default. If a distinct label is required, a separate Data Object Group Field of type string with the annotation text-type = label has to be used, as shown in the following figures.

Figure 164: ConSol CM Web Client - Default display of Data Object Group Field labels in versions prior to 6.9.4

Figure 165: ConSol CM Web Client - Labels as distinct Data Object Group Fields in versions prior to 6.9.4

As of CM version 6.9.4, you, as an administrator, can decide whether watermarks or labels (or both) should be used. Labels are now implemented similar to the labels for Custom Fields (i.e., the data fields for ticket data). Furthermore, tool tips can be added. The display modes of labels for Data Object Group Fields is controlled by annotations. Annotations can be set on Data Object Group level and on Data Object Group Field level. The field annotations overwrite the group annotations. In this way, you can define a group display behavior but can modify one or more single fields, as demonstrated in the example below.

Annotations for Data Object Groups:

Annotations for Data Object Group Fields:

Figure 166: ConSol CM Admin Tool - Configuration for Reseller Data Object Group, one field configured field-specific

Figure 167: ConSol CM Web Client - View for Reseller Data Object Group, one field (company_number) annotated field-specific (edit mode)

Figure 168: ConSol CM Web Client - View for Reseller Data Object Group, one field (company_number) annotated field-specific (Example: No influence on view mode)

The labels are inserted automatically, so in the end there might be, at most, six columns. In the following example, two columns are used.

Figure 169: Example for Data Object Group Field positions in the grid

Label Mode after an Update from CM Version Prior to 6.9.4 to a Version 6.9.4 and Up

The layout of the customer data model will be preserved during the update! All annotations will be set accordingly and can be modified later.

For all existing Data Object Groups, the annotation setting layout:show-labels-in-edit = false (which will hide standard labels in edit mode) is applied during the update.

Default Mode for New Data Object Groups and Data Object Group Fields

All new Data Object Groups will be rendered with the new default configuration. This means:

Figure 170: ConSol CM Web Client - Default display mode for Data Object Group Fields

Scripting Using Objects from the FlexCDM

In this book we will use the terms customer and customer definition. However, the corresponding scripts use the term data object and the names of the corresponding Java classes are Unit and UnitDefinition. All other Java classes which deal with customer objects are also still named Unit... Please keep that in mind if you work as both a ConSol CM administrator and programmer. Please refer to the ConSol CM Java API Doc for details.

New Scripting Features Since ConSol CM Version 6.9

Up to ConSol CM version 6.8, a Unit could have only one Custom Field Group. The expression unit.get("name") was always valid because a Custom Field with a specified name could exist only once, for example "group1.name".

Starting with ConSol CM version 6.9, a data object (Unit) may have one or more Data Object Group Fields with the same field name, e.g., "name" can be represented as "group1.name" and "group2.name" . In such cases, the expression Unit.get("name") is not semantically valid and throws an exception.

For backwards compatibility the code unit.get("name") will work as long as the Custom Field "name" is unique. If another Custom Field with the same name is added, the code unit.get("name") will no longer work!

Use the following notation to retrieve unit field (Data Object Group Field) data:

unit.get("contactFields:companyReference.companyFields:name")

Code example 14: Example to get the name of the company's contact

Extension of the Custom Field Expression Language (CFEL)

Starting with ConSol CM version 6.9, the Custom Field Expression Language (CFEL) has been improved to provide simple access to many objects. This applies to scripting for tickets and other objects as well as objects from the customer data model, i.e., Units (data objects: objects at the contact or company level). The improvements concerning units (data objects) are explained here. For a detailed explanation on how to write Java or Groovy code which uses customer data model objects, please refer to the ConSol CM Process Designer Manual.

You can access the customer data model objects from different scripts:

Changes in Scripting from ConSol CM Version 6.8 to Version 6.9

In ConSol CM version 6.9, some methods were declared deprecated and have been replaced by new methods. This is only relevant if you have scripts from version 6.8 or older. In this case, the scripts have to be refactored using the new methods.

AbstractField

Removed custom value accessors for each Custom Field type.

Removed/changed method

Replacement

StringField.getStringValue()

StringField.getValue()

NumberField.getNumberValue()

NumberField.getValue()

ActivityFormFieldsSet

Removed accessors with plain FieldDefinition, use ActivityFormElement instead.

Removed/changed method

Replacement

ActivityFormFieldsSet.addFieldDefinition(new FieldDefinition)

ActivityFormFieldsSet.addElement(new ActivityFormElement(new FieldDefinition()))

ActivityFormFieldsSet.getFields() returns List<FieldDefinition>

ActivityFormFieldsSet.getElements() returns List<ActivityFormElement>

ActivityFormFieldsSet.setFields(List<FieldDefinition>)

ActivityFormFieldsSet.setElements(List<ActivityFormElement>)

ActivityFormFieldsSet.removeFieldDefinition(FieldDefinition)

ActivityFormFieldsSet.removeElement(ActivityFormElement)

ActivityFormFieldsSet.removeAllFieldDefinitions()

ActivityFormFieldsSet.removeAllElements()

ActivityFormFieldsSet.getFieldDefinition(index) returns FieldDefinition

ActivityFormFieldsSet.getElement(index) returns ActivityFormElement

ActivityFormFieldsSet.addFieldDefinition(new FieldDefinition, index)

ActivityFormFieldsSet.setElements(ordered list of elements)

ContentFile

Added size parameter to input stream methods.

Removed/changed method

Replacement

new ContentFile(filename, inputstream)

new ContentFile(filename, inputstream, streamsize)

ContentFile.setInputStream(inputstream)

ContentFile.setInputStream(inputstream, streamsize)

ContentResource

Same changes as in ContentFile.

Removed/changed method

Replacement

new ContentResource(filename, inputstream)

new ContentResource(filename, inputstream, streamsize)

ContentResource.setInputStream(inputstream)

ContentResource.setInputStream(inputstream, streamsize)

FieldLogEntry

Removed modification accessors.

Removed/changed method

Replacement

FieldLogEntry.setModification(Modification)

FieldLogEntry.setValue(value) + FieldLogEntry.setPreviousValue(value)

FieldLogEntry.getModification()

FieldLogEntry.getValue() + FieldLogEntry.getPreviousValue()

Ticket

Removed renamed Custom Fields accessors and other changes.

Removed/changed method

Replacement

Ticket.getField(), Ticket.setFieldValue(), Ticket.removeField()

Previously mixing groupName and fieldName parameters worked, now only the order groupName, fieldName is accepted.

Ticket.setField(AbstractField)

Ticket.addField(AbstractField)

Ticket.addOrUpdateField(AbstractField)

Ticket.setFieldValue(pGroupName, pFieldName, Object pValue)

Ticket.getEnumValue

EnumValue enumValue = getFieldValue(String pGroupName, String pFieldName)

String enumName = enumValue.getName();

Ticket.setEnumValue(fieldName, groupName, enumName)

EnumValue enumValue = enumService.getEnumValue(enumGroupName, enumValueName);

Ticket.setFieldValue(pGroupName, pFieldName, enumValue);

For workflow usage:

Ticket.setFieldValue(pGroupName, pFieldName, getEnumValueByName(enumGroupName, enumValueName));

TimerTrigger

Removed setDuedate method.

Removed/changed method

Replacement

TimerTrigger.setDuedate

TimerTrigger.setDueTime

Unit

Removed renamed Custom Fields accessors.

Removed/changed method

Replacement

Unit.getFieldsSet()

Unit.getFields()

Unit.setFieldsMap(Map)

Unit.addFields(Set)

Unit.setField(AbstractField)

Unit.addField(AbstractField)

New (Convenience) Methods

Examples of new methods:

Object.Method Explanation

def contacts = unit.get("contacts()")

List contacts = company.getContacts()

Using CFEL ("contacts()") a list of all contacts is retrieved for the company (unit).
Unit company = mainContact.getCompany() For a contact, the company can be retrieved easily.
newContact.set("company()", newCompany)

For a (new) contact, the company is assigned the CFEL expression "company()", provides easy access to the company object.

List tickets = company.get("tickets()") For a company, all tickets are retrieved.

Ticket ticket = getTicket();

Unit mainContact = ticket.getMainContact()

List tickets = mainContact.get("tickets()")

For a contact, all tickets are retrieved.

Integer count = contact.get("company().contacts()[0].tickets()[count]"); A chain of expressions is used to get the number of tickets for a specific contact.

TicketCriteria ticketCriteria = new TicketCriteria();

Unit patternContact = new Unit("contact", customerGroup);

mdcmCriteriaBuilder.setReferencedContactCriteria(ticketCriteria, patternContact);

Code example 15: Example 1: Search for the tickets of a contact or of a company

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 example 16: Search for the tickets of the contact who is member of a certain company

UnitCriteria unitCriteria = new UnitCriteria();

Unit companyPattern = new Unit("company", customerGroup);

mdcmCriteriaBuilder.setReferencedCompanyCriteria(unitCriteria, companyPattern);

Code example 17: Search for contacts of a certain company

For detailed information about the methods, including input parameters and output data type (method signatures), please refer to the ConSol CM Java API Doc.

New Objects in ConSol CM 6.9 and Up

The objects which are available in the script obviously depend on the script's context. The following examples demonstrate some of the possible use cases:

Startig point Script Objects Example
Company page

data object action script

unit

represents the company

def contacts = unit.get("contacts()")
Contact page

data object action script

unit

represents the contact

List tickets = unit.get("tickets()")
Workflow activity workflow action or condition script ticket def id = ticket.getId()
Workflow activity with script in AT workflow action or condition script ticket not present implicitly!

import com.consol.cmas.common.model.ticket.Ticket

def id = ticket.getId()