License Features
Software vendors frequently need the capability to independently manage entitlements for distinct components or modules within their primary application.
LicenseSpring accomplishes this through its advanced licensing features. It offers two types of feature licensing: consumption-based and activation-based.
This tutorial will explore the effective utilization of license features within your application.
- Completed the Getting Started tutorials, specifically:
- Initialized LicenseManager (or LicenseHandler) with your configuration using the appropriate settings.
- Activated a license.
- Activation features are straightforward, operating as either enabled or disabled based on a license.
- Consumption features offer more complexity, featuring a "Maximum Consumptions" parameter that increments the "Total Consumptions" count whenever a user utilizes the feature. Additionally, you have the flexibility to establish overage settings for individual product features and specify a period for resetting consumptions.
License features can be added on the LicenseSpring platform, on the product page under "Features".
See our Features page for a more in-depth look at adding license features.
There are two ways of retrieving license features:
- Retrieving a product (license) feature by feature code.
- Retrieving all product features available for the license.
First, to access a specific license feature within the SDKs, the following method can be used:
This method either returns a LicenseFeature object with the provided feature code, or throws an InvalidLicenseFeatureException if the feature code does not exist.
The other strategies includes receiving all available product features for a given license:
The features() method returns a vector of LicenseFeature objects in the C++ SDK and an array of LicenseFeature objects in the .NET SDK.
Note: In the Java SDK, getProductFeatures() is called on a LicenseData object, not License.
Consumption feature licensing enables measuring the usage of a feature within the application.
This proves valuable when the vendor intends to restrict the frequency of specific functions being executed or reports being generated, among other scenarios.
To modify the usage levels of features, the following method is used:
The first parameter is the unique feature code associated with the feature under update, while the second parameter signifies the consumption value to be added. The last parameter determines whether the update is to be stored locally.
There are two options for measuring consumption on a device: local consumption and total consumption.
When employing local consumption for a specific feature, consumptions are exclusively retrieved from the local license file, bypassing the backend. This approach can be advantageous for caching local consumption amounts per device, as LicenseSpring charges on a per API call basis. Consequently, you can configure the setup such that local consumption synchronization with the backend occurs only when the program concludes or during other designated scenarios.
Total consumption operates differently by encompassing both the total consumption on the LicenseSpring platform and the local consumption on the device. Hence, if total consumption is chosen for a particular feature, all users utilizing the same license will collectively share the consumption pool displayed on the platform.
When dealing with total consumption, developers utilize the following to synchronize feature consumption:
It is advisable to call this method before trying to obtain the total consumption value and after updating the total consumption count.
If you are syncing properly, then your total consumption should be equal to your local consumption at any time.
Note: To identify expired features, developers have the option to employ syncFeatureConsumption. In cases where a feature has been removed from the license, attempting to locate it using syncFeatureConsumption on the LicenseSpring platform will result in an InvalidLicenseFeatureException being thrown.
