Entitlement in its simplest form is about enabling/disable product features. In addition to that, SLASCONE’s licensing core provides limitations, which are numerical values used in order to measure and optionally restrict the scale of some operations e.g., maximum number of users or jobs.
Limitations can be used/interpreted by the client application in two ways:
- Static: In such case, the limitation constitutes a global restriction, regardless of usage patterns, e.g., maximum number of documents that can be stored in a database. It is the client’s responsibility to ensure compliance of this limitation.
- Consumption-Based Quota: In this case, the limitation constitutes a consumption-based quota, that resets periodically. For example, the license allows the creation of 10 documents monthly. SLASCONE tracks the consumption of this quota and informs the client when the quota is depleted.
DEFINING A CONSUMPTION-BASED LIMITATION
Whether a limitation is static or consumption-based, is defined in the license. In case of consumption-based, you have to additionally define the reset mode:
- Lifecycle: In this reset mode, the defined quota, for example 10 documents, does not reset, which means once the 10 documents have been created, SLASCONE informs the client, that no more are allowed. This mode is typically used in trial licenses.
- Periodical (number of days): In this reset mode, the quota is reset every n days.
- First day of month/quarter/year: In this reset mode, the quota is reset on the first day of the next month/quarter/year.
GOODWILL
A typical requirement in such scenarios is the ability to allow an overconsumption, or goodwill. In SLASCONE you can define this in percent. A limitation of 10 combined with a 20% goodwill, means that a consumption of up to 12 is allowed but not more.
This is an edition (not a license) property.
ENFORCE LIMIT
By default, limits are enforced, meaning that the respective consumption heartbeat fails. Deactivating this results in allowing consumption heartbeats to exceed the set limits. This is recommended for metering scenarios (in which the limit is secondary or even optional).
This is an edition (not a license) property.
AGGREGATION LOGIC
By default, consumption heartbeats are additive, which means that the balance is calculated as the sum of all consumption heartbeats in the respective period.
However there are metrics, such as stocks and inventory, that only the latest value is relevant. You can control this behavior at the product limitation level.
This is a product (not an edition or license) property.
CONSUMPTION MONITOR
The vendor portal provides an overview of the consumption and the actual balance:
CONSUMPTION ALERTS
You can define multiple consumption alerts for the same edition and limitation. For further information see CONSUMPTION ALERTS.
CLIENT/API CONSIDERATIONS
CONSUMPTION HEARTBEAT
Before starting a client action involving a consumption limitation, the client has to send a consumption heartbeat to SLASCONE:
POST /isv/{isv_id}/data_gathering/consumption_heartbeats
- If there is not enough quota, the response contains a null transaction_id.
- If there is enough quota, the response contains a valid transaction_id.
ROLLBACK
It is also possible to rollback a consumption directly in the Vendor Portal:
VALIDATION
If you want to check the consumption balance without sending a heartbeat you can use the following method.
POST /isv/{isv_id}/provisioning/validate/consumption
Comments
0 comments
Please sign in to leave a comment.