Cumulocity API Services / com.softwareag.jc.cumulocity.services.models / ManagedObject / <init>

<init>

ManagedObject(id: String?, serialNumber: String?, name: String?, supplier: String?, model: String?, revision: String?, type: String, subType: String?, location: Position?, notes: String?)
ManagedObject(name: String?, notes: String?)

Creates new ManageObject to be posted to Cumlocity via ManageObjectService

ManagedObject(o: JSONObject?)

This is the single most important asset type referenced by Cumulocity. Principally identifies the devices to be managed, but can be used to define any required asset type, such as groups, buildings, rooms etc. etc.

It's formal definition is given in the Cumulocity REST API Guide

Customisation

ManagedObject's can be easily enriched with custom attributes, however this is problematic for a typed language such as Kotlin or Java. In this implementation custom attributes are added to a properties attribute of ManagedObject and identified by the name of the value. Complex structures are flattened into a single key/value pair e.g.

{
 "my_custom_structure": {
     "name": "this is an example"
     "sub_elements": {
             "value": "Can have as many sub-levels as you want"
         }
     }
 }

becomes

properties["my_custom_structure.name"] == "this is an example"
properties["my_custom_structure.name"] == "this is an example"
properties["my_custom_structure.sub_elements.value"] == "Can have as many sub-levels as you want"

You can also add single custom attributes to ManagedObject and reference them too, however they have to be prefaced with 'x' in order to be included e.g.

{
 "xMy_Custom_value": "123456"
}

becomes

properties["xMy_Custom_value"] == "this is an example"

The above is required because there is no formal description available for a ManageObject and hence no way to formally distinguish between standard and custom attributes, hence the 'x'

This could put forward the argument that all custom values should be placed in complex structure as above. Unfortunately this is not always possible, due to the fact that only simple top level custom attributes can be included in Cumulocity dashboards.

You can also register your own classes to replace the flattened structure with a proper object representation if you wish. Refer to the documentation for PropertiesBase for details.