Configuring Custom Attributes

• Configuring Custom Attributes
  • Overview
  • Process
    • Base Data Types
    • Custom Attribute Types
    • Service Custom Attributes
    • Adding Service Custom Attributes to Screens
  • Storage of Custom Attributes
  • Example Queries on Custom Attributes

Overview

Custom attributes allow you to extend what can be stored in CCLAS. At system configuration, any data that cannot be stored in an existing field of an entity can be stored in a custom attribute field on that entity. This is done by adding a service custom attribute of a given custom attribute type to a service. The service custom attribute is then associated with a field on a screen.

This custom attribute type extends on the simple base validation provided by the base data type. For example, an acceptable range for an Integer field, or the ability to use an CCLAS service to validate a string field entered as actually a valid Employee Id.

Custom attributes can be:

• Placed onto search result grids.
• Placed onto detail forms on a tab or in a field group.
• Available in reporting classes.
• Secured within the rights/roles environments.

Process

Base Data Types

A base data type defines the type of data to be stored. For example, a Date field presents a date picker on the screen and performs date validation. A List field presents a drop-down selection list. The default data types in CCLAS 6 are:

• Boolean
• Decimal
• Date
• File
• Integer
• List
• Time stamp
• String (a free-type string value into which the user can enter information)
• Time
• Text Area.

Custom Attribute Types

Where additional validation or restrictions are required for a field, a custom attribute type can be created.

The MSECAT—Custom Attribute Types application is used to maintain custom attribute types.

Custom attribute types are created at instance level.

A custom attribute type is based on a base Data Type, has a Label and content based on the Data Type:

• Integer/Decimal—With an optionally defined Start Value and End Value.
• Decimal—With a defined Scale.
• String—With a defined Field Length.
• List—With a defined list, where each list item has a system-generated Sequence and defined Code and Description, to allow values to appear in a drop-down list for a field of the type.

A custom attribute type can have:

• Categories—One ore more categories can be defined for a custom attribute type. Categories are used to group an attribute type with other related attribute types and are used as a search criteria when searching for custom attribute types.

• Validation Rules—Where a custom attribute type is added as a service custom attribute to one or more services, then for each Service Name, Service Operation and Service Field, validation rules can be defined by linking valid Literal values to an additional Service Field. As an example, client type could be added, using the literal value of F indicating that the entry is being validated on being a priority client as any other criteria.

  Where a screen contains a field associated with the service custom attribute, when data is entered into a field, then the validation rules particular to that service, operation and field are applied.

If the requirement is to delete a custom attribute type, note that it cannot be deleted if the custom attribute type still exists as a service custom attribute on a screen or service. To delete a custom attribute type, first delete the following entities, in the denoted sequence:

1. Delete the field from the screen layout. Refer to Personalising Screens.

2. Delete the custom attribute from the service attributes list of the screen personalisation window. Refer to Personalising Screens.

3. Delete the service custom attribute from the list of attributes for that service. Refer below to Service Custom Attributes.

4. Delete the custom attribute type.

Maintain custom attribute types

Service Custom Attributes

To create a custom field, a custom attribute type must first be added to a service, to create a service custom attribute.

The MSEATT—Service Custom Attributes application is used to maintain service custom attributes.

Service custom attributes are created at instance level.

A CCLAS 6 service, of a given Service Name and Service Type, can contain multiple service attributes, some of them relating to core CCLAS 6 and others being custom attributes based on a particular custom attribute type.

Note: A Service Name is case-sensitive.

A service custom attribute has an Attribute Name, links to an Attribute Type which is either a core or custom attribute type, and is flagged for Multiplicity which means that the custom attribute can store more than one value, so it should be rendered as a multi-value field on a screen.

Once a custom attribute is added to a service, it is treated the same as a core attribute on any object created by the service, as though it was read from the default table associated with the service.

Service custom attributes for selected services can be exported to a JSON file and imported into other instances of CCLAS 6, as required, to assist with system configuration.

Maintain service custom attributes

Note: It is only when a user is given permission to use a custom attribute that the user can 'see' and 'use' the custom attribute. When a custom attribute is created, it needs to be added to a right to which the whole laboratory (in most cases) has access. This effectively means that all custom attributes created for an environment should be assigned to a custom right, that custom right assigned to a custom security role, and that custom security role assigned to any user who wishes to 'see' and 'use' the custom attribute (refer to maintaining security roles when Maintaining Users).

Adding Service Custom Attributes to Screens

Once service custom attributes are created, the attribute becomes available in the Service Attributes tab of the Screen Personalisation tool, from where it can be added to the screen requiring personalisation.

Once added to a screen, where the service is associated with the screen, then the attribute is populated accordingly. Refer to Personalising Screens.

The Screen Personalisation tool also has the ability to create service custom attributes by launching the MSECAT—Custom Attribute Types application directly from the personalisation environment. This process internally links the CA, the CAT, and the DTO entity.

The benefit of using screen personalisation over the MSEATT—Service Custom Attributes application is that you can see which service is supported by the user interface, the list of core attributes that are available for that service, and the list of custom attributes that are available for that service. However, the MSEATT—Service Custom Attributes application does allow for custom attributes to be imported.

Storage of Custom Attributes

The following tables contain custom attribute definitions and their associated values on entities:

• MSF0P1—The type of custom attribute fields

• MSF0P2—The list items where the type of custom attribute field is a list

• MSF0P5—Custom attribute string values stored against entities

• MSF0P6—Custom attribute image BLOB values stored against entities

• MSF0PC—The categories that are linked to a custom attribute

• MSF0PS—Holds the custom attribute at the service level

• MSFPV1—Holds the validation service linked to a custom attribute type

• MSFPVP—Holds the validation service field pairing

• MSFRTA—Custom attribute rich text CLOB stored against entities

Example Queries on Custom Attributes

Locate specific custom attributes (string type) on a job:

select J.CODE, P50.PROPERTY_VALUE as J_HAZARD from MSF0P5 P50, CCJOB J

where P50.ENTITY_KEY = J.ID

and P50.ENTITY_TYPE='CCJobService.CCJob.CA_HAZARD'

and J.CODE ='180000000004'

Locate specific custom attributes (string type) on the job scheme for a specific job:

select JS.JOB_CODE, P50.PROPERTY_VALUE as JS_METHODCODE from MSF0P5 P50, CCJOBSCHEME JS

where P50.ENTITY_KEY = JS.ID

and P50.ENTITY_TYPE='CCJobSchemeService.CCJobScheme.USRMETHOD_CODE'

and JS.JOB_CODE ='LAB001233_2017'

Locate specific custom attributes (string type) on users:

select U.CODE, U.NAME, U.FULL_NAME, U.IS_ACTIVE, P50.ENTITY_TYPE, P50.PROPERTY_VALUE as USER_PROP

from MSF0P5 P50, CCUSER U

where P50.ENTITY_KEY = U.ID

and P50.ENTITY_TYPE like 'CCUser%LICENCE%'

and IS_ACTIVE='N'

and P50.PROPERTY_VALUE like 'Con%'

Report all custom attributes in an environment:

Select

TRIM(MSF0PS.ATTRIBUTE_NAME) CustomAttribute,

TRIM(MSF0PS.SERVICE_NAME) ServiceName,

Trim(MSF0P1.PROPERTY_NAME) AttributeType,

Case MSF0P1.PROP_DATA_TYPE

When 'B' Then 'Boolean'

When 'C' Then 'Decimal'

When 'D' Then 'Date'

When 'F' Then 'File'

When 'I' Then 'Integer'

When 'L' Then 'List'

When 'M' Then 'Image'

When 'P' Then 'TimeStamp'

When 'S' Then 'String'

When 'T' Then 'Time'

When 'X' Then 'Text'

When 'R' Then 'RichText'

Else

'000'

End as DataType,

MSF0P1.PROP_LENGTH as StringLength

from

MSF0PS , MSF0P1

where

MSF0PS.PROPERTY_ID = MSF0P1.PROPERTY_ID

Order by MSF0PS.SERVICE_NAME, MSF0P1.PROPERTY_NAME