New and Noteworthy in SiteWhere Community Edition 1.1.0

//New and Noteworthy in SiteWhere Community Edition 1.1.0

New and Noteworthy in SiteWhere Community Edition 1.1.0

The main focus of the SiteWhere 1.1.0 release is to improve usability of the SiteWhere asset management subsystem. It also addresses quite a few bugs and requested improvements in other areas of the system.

New Server Runtime Status Page

The home page for the administrative console application is now a server status page. You can quickly find which version and edition of SiteWhere is running in addition to other information about the operating system and JVM. More information will be added to the page in future releases.

Manage Assets in the Administrative Console

Previous versions of SiteWhere only supported asset modules loaded from XML files or from external asset management products. While this worked for most users, it was not ideal because assets were not editable from the administrative console interface. SiteWhere 1.1.0 changes the default behavior to store assets in the datastore along with all of the other SiteWhere data. There is still the option of using XML files and external asset management solutions if needed.

In the administrative console interface, there is a new Assets tab which contains the new features. This leads to an Asset Categories page which allows categories of assets to be created. SiteWhere separates assets into four types:

  • People – Person assets contain information such as name, username, and email address.
  • Places – Location assets contain information such as latitude, longitude, and elevation.
  • Things – Hardware assets contain information such as product name, description, and SKU.
  • Devices – Device assets are a special class of hardware assets that can be used for device specifications.

Each asset category contains assets of one of the above types. Users can add any number of asset categories, then add any number of assets per category. At startup, SiteWhere creates an asset module for each category in addition to the asset modules already configured using XML files or asset management systems. Asset modules can be reloaded at runtime using the asset management REST services.

Better Support for WSO2 Identity Server

SiteWhere has supported WSO2 Identity Server as an identity management provider since before 1.0, but the module had not been updated to be configurable via the Spring XML schema. SiteWhere 1.1.0 adds Spring XML schema support and a number of new configuration options to make integration easier. A WSO2 Identity Server asset module can be configured by adding the following to the SiteWhere configuration:

<sw:asset-management>


  <!-- Loads assets from WSO2 Identity Server -->

  <sw:wso2-identity-asset-module moduleid="wso2" scimusersurl="https://wso2is:9443/wso2/scim/Users" username="admin" password="admin" ignorebadcertificate="true">

  </sw:wso2-identity-asset-module>


</sw:asset-management>

Once configured, the WSO2 asset module will load all of the assets on startup via the SCIM protocol. If more assets are added via the WSO2 user interface, you will need to call the asset management refresh REST service. For more information about the configuration options, take a look at the documentation.

New Asset Search Options

A new REST method has been added to support queries of all assignments associated with a given asset. This can be used to get a list of devices currently associated, or to provide a history of all previous assignments for the asset. The new method is useful in applications that are more asset-centric rather than device-centric.

Multitenancy on the Way!

The SiteWhere 1.2.0 release will focus on making SiteWhere a truly multitenant system. New management features will be added to allow for the creation of tenants and the association of one or more tenants to each system user account. Each tenant will have its own SiteWhere “engine” that can configured meet its system requirements. This allows tenant isolation at the processing level.

From a data perspective, each tenant will have separate data storage with no intermingling of data. When using MongoDB as the datastore, each tenant uses a separate database. For an HBase datastore, each tenant will have their own group of tables. The administrative console will change to allow editing of data for a single tenant at a time. When a user logs in, they choose which tenant to interact with based on the list they are authorized to access.

http://www.sitewhere.com/

Cheers!

The SiteWhere Team

By | 2017-10-17T22:04:13+00:00 August 1st, 2015|Developer Blog|0 Comments