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 prerequisites completed the getting started tutorials, specifically initialized licensemanager (or licensehandler) with your configuration using the appropriate settings activated a license types of license features 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 adding license features license features can be added on the licensespring platform, on the product page under "features" adding product feature see our features docid\ ptsdhuar9yjhgpvbkxb4o page for a more in depth look at adding license features accessing 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 license >feature( "feature code" );license feature( "feature code" );if let feature = license features first(where { $0 code == "feature code" }) { } response = license get feature data("feature code") print(response)// go sdk v2 license data getfeature("feature code")license license = this getcurrent(); licensedata data = license getdata(); list\<licensefeature> features = data getproductfeatures(); 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 license >features();license features();licensedata getproductfeatures();let features = license featuresfeatures = license features() print(features)// go sdk v2 license data featuremanager licensefeatures 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 license features 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 license >updatefeatureconsumption( "feature code", 1, true );license updatefeatureconsumption( "feature code", 1 );license increasefeatureconsumption( "product code", 1 );try license updatefeatureconsumption(code "feature code", difference 2)license add local feature consumption("feature code",1)// go sdk v2 ld, err = license handler updatefeatureconsumption(featurecode, 1, true) 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 license >syncfeatureconsumption( "feature code" );license syncfeatureconsumption( "feature code" );license syncconsumptions()// sync exact feature try license syncfeatureconsumption(code "feature code") // sync all features try license syncfeatureconsumption(code nil)ld, err = license handler syncfeatureconsumption(ctx, featurecode)// go sdk v2 ld, err = license handler syncfeatureconsumption(ctx, featurecode) 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 identifying expired features can also be done through a license check with the includeexpiredfeatures parameter in that case, the api returns a list of all non expired and expired features bool includeexpiredfeatures = true; license >check( installfilefilter(), includeexpiredfeatures );response = license check(include expired features=true) print(response)