Things-Client - events and messages

The Things service identifies every things-client by its unique ID. The client ID is used by the Things service to check permissions and dispatch messages to clients.

A client ID consists of two parts:

  • the solution ID
    this part your retrieve after successfully booking a service instance
  • a suffix
    helping to distinguish e.g. different applications of a solution.

The permissions on a thing can be described as ACL entries (for API v1) or as a Policy (for API v2 respectively). If you need to receive events or to handle messages, it is crucial that the ACL (or Policy) of a Thing contains an entry for every client ID that should have proper access rights.

Permission examples:

  • In case the client is allowed to write a thing, it can for example create, read, update and delete the thing, its attributes, features, properties, etc.
  • In case the client is allowed to write a thing's policy, it can change the permissions.
    This proves useful especially in case your client needs to handle a claim message.
    Find an example at basic concepts > Claiming.
  • In case the client is allowed to read a thing, it will be informed with an event for all changes executed by another client.

Events caused by commands from a connection are not published to the same origin. The Java client can receive a response, but will not additionally get an event.
For example, messages produced by the same Java client (to update a thing attribute) are forwarded to all subjects with read permission, which would include the (publishing) Java client. However, the server would by default filter out such a notification.

In case you don't need all events of a thing but only specific ones, find details about filtering at the protocol section > Event filter.

The things-client can be clustered.