This article explains the necessary steps in named-device (on-premise) scenarios. Such scenarios require that each installation is uniquely identified.
CREATING A NAMED DEVICE EDITION
Named device functionality is unleashed as an edition (not a product) property. This allows you to simultaneously offer both named and floating licenses for a specific product. The following parameters are important when creating/editing a named device edition:
- Provisioning Mode: Named
- Client Type: Devices
- Activation upon license creation: not set
CLIENT/API CONSIDERATIONS
These are the fundamental functions you need to integrate in your software. You need to provide an area in your software in which the end user can:
- enter the provided license code (ACTIVATION)
- update/sync the license (HEARTBEAT)
Make sure that your environment has at least one license, in order to be able to test these functions.
LICENSE ACTIVATION
The licensing lifecycle begins with the activation of a device. In most cases, you need to provide an area in your software, in which the end user can enter the provided license code. Upon entering the license code, your software should call this method:
POST /isv/{isv_id}/provisioning/activations
SLASCONE provides 2 types of license keys:
- License key: when you create 1 license with n tokens, SLASCONE generates 1 license key and n token keys. The license key can be used n times for activation.
- Token key: a token key can be used only once for activation.
The activation might fail for several reasons:
- The license is not active (inactive or expired).
- The license key is already activated on a different client (to prevent license piracy).
- The license has not any available tokens left (all tokens are already assigned).
CLIENT REACTIVATION WITH A NEW LICENSE
In case you activate an already activated client with a new license, the old license becomes automatically available again.
HEARTBEAT
After activating a client, you need to make sure that your software periodically communicates with SLASCONE in order to sync the license data. More about the recommended heartbeat frequency can be found here.
POST /isv/{isv_id}/provisioning/heartbeats
The response body of the heartbeat method is very similar to the one of the license activation.
Beyond licensing purposes, when calling the heartbeat method your software needs to send its software version and operating system. This data is used in the Analytics area of SLASCONE.
LICENSE UNASSIGNMENT (DEACTIVATION)
The licensing lifecycle for a device ends with its unassigment/deactivation. It is recommended to provide an area in your software, in which the end user can unassign the used license code, so that this can be used on another device (typical hardware migration scenario).
POST /isv/{isv_id}/provisioning/unassign
WHAT TO SAVE IN YOUR CLIENT
Your on-premise application has to locally save (some) license data. This is necessary, not only for completely offline installations, but also to have license data during a potential freeride period.
LICENSE KEY
Obviously, your application needs to locally save the entered license key.
UNIQUE DEVICE ID
Only if you use an initial random id.
LICENSE CONTENT
Whether you need to save the license content depends on your connectivity strategy.
- If an internet connection is required during application start, then nothing needs to be locally saved. This implies, that the application can not be started if no connection can be established with SLASCONE.
- If an internet connection can not be guaranteed, the license content needs to be saved in order to make sure that the application can start nevertheless.
Make sure to properly encrypt them, in order to avoid easy manipulation.
Comments
0 comments
Please sign in to leave a comment.