Properties

The topology API has two categories of properties, generic and user. Generic properties have fixed data types, while user-defined properties do not.

  • Some properties have special semantics, as described in Generic properties.
  • The pre-defined properties are listed in the Pre-defined properties table.
  • You can add any property as required, as described in User properties.

Generic properties

Generic properties are few and constrained to a fixed data type. They can also be subdivided into those which are read/write and those which are read-only.

  • uniqueId

    The uniqueId is the string that is used to match resources from the same provider. It could be, for example, a UUID by which the provider can look up its own local data store for information about that device.

    If you send the same resource with the same uniqueId and the same provider more than once, it will be treated as the same resource.

    The provider is a project (namespace) for the resource's uniqueId. That uniqueId property is unique only within the scope of a provider.

  • matchTokens

    These tokens are used to store strings, which are significant to that resource, and might match it to events.

  • name

    This string does not have to be unique, and it should be short and memorable.

  • tags

    Tags can be used to search for resources in the topology view, and to group resources. For more information on configuring tag rules and tag-based templates, see the following sections:

  • entityTypes

    These are defined as a set, though with usually only a single member, of one or more types this resource represents.

    For more information on entityTypes, see the Entity types topic.

Predefined properties

Name Type Cardinality Alias Read-only Indexed
age integer single   no y
aliasIds ID set _aliasIds yes n
beginTime long single _startedAt yes y
changeTime long single _modifiedAt yes n
createTime long single _createdAt yes y
deleteTime long single   yes n
description string single   no y
edgeTenantId ID single _edgeTenantId yes n
edgeType string single _edgeType yes n
endTime long single _deletedAt yes y
entityTypes string set   no y
eventId string single   yes n
eventManager string single   yes n
expireTime long single _expiredAt yes n
geolocation GeoLocation single   no n
hasState string single   yes n
icon string single   no n
id long single   yes n
keyIndexName string single   yes n
label string single   yes n
matchTokens string set   no y
name string single   no y
observedTime long single _observedAt yes n
operation string single   yes n
partOfExternal Boolean single   yes n
prevBeginTime long single   yes y
providerId ID single   yes n
providerName string single   yes n
reconciliationTokens string set   yes n
referenceId ID single   yes y
referenceNo long single   yes n
serializedHashMap HashMap single   yes n
severity string single   no n
speed long single   no y
statusType string single   yes n
tags string set   no y
tenantIds ID set _tenantIds yes y
uniqueId string single   no y
uuid ID single _id yes y
version string single   no y
vertexType string single   yes y

User properties

User-defined properties are free-form, and are not constrained by any data type. You can add new user properties as needed.

You can define any custom properties, such as, ipAddress.

Note: All user-defined properties such as ipAddress are not in the generic set, and are stored as a serialized blob data type instead. The implication of this serialized data type storage convention is that these properties cannot be filtered, as they are incompatible with the _filter query parameter used in the REST API.

JSON record depicting both types of properties

The following picture depicts how the properties in a JSON record from an Observer can be split into both generic and user properties.

JSON record properties