Project settings

Aside from the specific settings for subjects and metrics there are also general project settings. These settings can be found under the general section in the settings menu. On this page you can find what the settings are about.

General

The general settings apply for each and every person in the project. So, changing the Theme will result in a Dark or Light theme for everyone. This is what you can set:

SSO settings

This setting is only available once SSO is configured at your organization’s SSO settings. For first time users, a default role can be defined to determine the level of access these users are granted.

Leave project

You can remove yourself as a member of the project. Be aware of the fact that you will lose access to the project right after you’ve hit the button ‘Leave project.’ If you want back in, you will need someone else to invite you to the project.

Change owner

This action can only be executed by the Owner of the project. As an owner of the project, you can transfer the project to someone else within the project. Especially useful when want to give someone else responsibility for the project when you are on a holiday or a well-deserved sabbatical of 3 months.

Remove project

This action can only be executed by the Owner of the project. As an owner of the project, you can remove the project and all its resources. This is a dangerous action, so be very, very, very careful with this action.

Here is an example of the General settings of the Blockbax Playground project:

Roles

Roles give control on what kind of access you grant to the members of your project. From default roles to fine-grained custom roles, it’s all configurable at the project settings.

Default roles

Each project comes with default roles with fixed permissions. The permissions for these roles are the ones we see most often.

Custom roles

Custom user roles can be used to define more fine-grained permissions for your members compared to the default roles.

Configurable permissions

View, edit and manage

The platform provides three permission levels.

Include and exclude subject permissions based on properties

The behavior of including and excluding subjects based on a property differs from selecting individual subjects.

Non-configurable permissions

Some resource permissions underlying certain sections in the interface are not configurable, but are derived or only accessible via system-defined roles.

Here you see a Blockbaxer creating a custom role.

Members

Member management empowers you to keep an eye on the people and their permission in your project. At this part of the platform you can easily invite new people for your project, change roles for your project members and remove an account from the project.

Invite link

The owner of a project can create an invite link in the members section. This makes it easy to invite people to the project without knowing and typing in their email-addresses.

People that use the invite link to join the project will automatically get the observer role.

The invite link can be revoked by the owner. The invite link is invalid after revoking and can not be used anymore. The owner can always create a new one, but never activate an old one again.

Properties

Properties can be used to label subjects. This is what you need to configure when adding or editing a property:

Access keys

Access keys are needed to integrate with our APIs. You can easily create one by giving the key a descriptive name to easily recognize and find it. Next, you can select the key type and set the permission to constrain the person or system on what it can do with your data.

Key type

Based on the the type of protocol you want to integrate with you select the type of key required.

Once created, you have to copy the secret information and use it straight away, because you won’t be able to see it again.

Permissions

Here you see a Blockbaxer creating an access key with specific subject permissions.

Webhooks

Webhooks are developed to send events to other systems in real-time. You can see it as a reversed API: provide your endpoint and the platform makes sure you get the events you are interested in once they occur. Note that suppressed events are never forwarded.

General information

The following general information is required for a webhook.

Event levels

Here you can select the event levels for which the webhook should be called. For example, you might only want to see Problem and Warning events being send to your external system.

Event triggers

Here you have some filter options to only have the webhook called for certain event triggers.

Subjects

Here you have some filter options to only have the webhook called for certain subjects.

The structure of the JSON message that is sent to the endpoint and more details can be found in the integrations section of the docs.

Inbound connectors

Inbound connectors are the integrations to ingest measurements into the Blockbax Platform. You can find the configuration and logs of your project’s default connectors here and you can create custom connectors. This is very useful when either the ingestion method or payload format is different from the standard HTTP, MQTT or CoAP connectors.

General information

Protocol

Protocols are divided in two categories: data that gets sent to Blockbax (push) and data that Blockbax fetches from an external server (pull).

The following push-based protocols are available:

The following pull-based protocols are available:

Auto-create subjects

To map measurements to subjects and metrics you can specify your own IDs. We call these ingestion IDs, by default these are derived from the subjects’ external IDs and metrics’ external IDs (e.g. MyCar$Location) but you can also override these with custom ones. When you use this option a subject is created if its external ID derived from the first part before the $ sign of the ingestion ID does not exist (i.e. for the ingestion ID MyCar$Location a subject with external ID MyCar will be created if the metric with external ID Location can be linked to exactly one subject type).

Payload conversion

In addition to a protocol an inbound connector requires specifying a payload conversion. The payload conversion is a script that is used to transform an arbitrary received payload to measurements that are ingested in the Blockbax Platform. A payload conversion has an expected payload format and is defined as a plain JavaScript function.

Payload formats

Currently, four different payload formats are supported by Inbound Connectors. Payloads must always be sent to the inbound connector as bytes, but the format specifies how these bytes are decoded and passed to the payload conversion function.

Payload conversion script

The payload conversion script is a user-defined script that is used to transform the decoded payload to measurements that are to be ingested by the Blockbax Platform. Additionally, log messages can be generated to provide feedback to the user from the payload conversion script.

The payload conversion is defined as a JavaScript (ECMAScript 2022 compliant) function with required signature convertPayload(payload, context) { ... }. The web client provides a convenient editor with auto-completion and method signatures on hover. An example script is shown below:

1
2
3
4
5
6
7

function convertPayload(payload, context) {
  const ingestionIdPrefix = payload.id + "$";
  const timestamp = date(payload.timestamp);
  for (const [key, value] of Object.entries(payload.data)) {
    context.addMeasurement(ingestionIdPrefix + key, value, timestamp);
  }
}

This script takes a JSON type payload and uses a top level property for prefixing the ingestion ids. The timestamp for all measurements contained by the payload is parsed from the top level object as well. The script then iterates over all key value pairs in the data field to ingest them as measurements.

Payload parameter

The payload parameter is the decoded payload sent to the inbound connector. This parameter can be either a JavaScript object, a string or an ArrayBuffer. The type of the payload depends on the specified payload format. The payload object is immutable and will throw a TypeError on modification.

Context parameter

The context parameter is an object used to pass measurements and logs to the Blockbax Platform. The context parameter cannot be modified. Its functionalities are described below:

Optionally when the MQTT subscribe connector is selected, it will also have the following functionality:

Library functions

Several library functions are available when writing your conversion function to make writing a conversion easier and more concise. The available functions are described below.

Testing payload conversion scripts

Payload Conversion scripts can be tested in the Blockbax Web Client. Depending on the payload type a test payload can be provided, and the conversion script is then executed for that payload. For the JSON, CBOR, String and Avro types, a string can be provided as payload. For the CBOR and Bytes type, a hex string can be provided. The test payload can be saved with the conversion script. This allows doing basic regression testing when making changes to the script and verifying that the output measurements are correct for that payload. When the conversion script is executed for the payload the web client will show the measurements and logs that were produced by the payload conversion. Please note that this is only a visual representation of the outcome of the payload conversion, no actual measurements are ingested. Any problems with the script or resulting measurements are shown as log messages.

Outbound connectors

Outbound connectors give you the opportunity to stream your data out of the Blockbax platform and into your own infrastructure. You are able to configure two outbound connectors, one for events and the other for measurements. when these are set up, data is forwarded whenever an event is triggered or measurement is received. There are two protocols to choose from: either have your data produced to an Azure Event Hub or to a Kafka cluster.

Kafka produce

Data can be produced into your Kafka cluster. For authentication there are 2 options: SASL/PLAIN (username and password) and SSL (certificates), one of which needs to be supplied. All the settings can be seen below:

Azure Event Hub produce

To produce data to your Azure Event Hub, the connector will need the following settings:

Audit log

The audit log shows a record of project activity over the last 90 days.

Blockbax keeps track of changes made to projects over time. In the audit log you browse recent activity and see who did what when. Creating subjects, modifying event triggers, updating alarms, and many more changes are all logged. There is only one exception: modifying the values of subject properties. If you do want certain property changes to be logged, you can offer an action to modify the properties instead, because action runs are logged.

Only administrators and project owners can access audit logs.