Introduction
The Feature Availability server function returns information, to a client, about the amount of feature resources that remain available (i.e. not checked-out) to all the clients activated on the same license code. For floating features, this means the number of remaining feature seats. For element pools, this means the number of remaining elements. For consumption tokens, this means the number of remaining tokens.
There are other client API functions that provide related feature-usage information, but only for that client, i.e. not globally for all clients using the same license code. For example, NSLGetPoolInfo returns the total number of elements in that pool and the number checked out by that client. However it does not provide the total number checked out by all clients and so cannot be used to deduce the number remaining in the pool. It is the purpose of the Feature Availability server function to provide this information.
This server function should be used with an important caveat. By the very nature of the information that it requests, it is impossible to guarantee that it will always be 100% reliable. For example, client A may request the number of elements remaining in a pool. In the short delay between the server constructing its response and this response being received by the client, a second client B may check out more elements from that pool. The response received by client A will then no longer be correct. This kind of scenario is impossible to avoid and so care should always be taken when interpreting the response from this server function.
Server-Side Implementation
Configuring License Codes
Server Functions Configuration
However, unlike some other server functions e.g. LTCO, this function is always enabled. It also has no special server parameters that need to be set. As such, it has no server configuration to edit and so there is no edit button.
Server Functions Usage History
There are no entries for the Feature Availability function in the Server Functions Usage History table, as calls to this function will always be granted (under normal operating conditions and if the queried feature exists.)
Configuring Profiles
As on the license code edit page, there will be an entry for the Feature Availability function in the Server Functions Confiiguration table on the profile edit page. This entry will show the function as being always enabled, having no server parameters and no edit button.
Client-Side Implementation
Client Parameters
The table below shows the parameter values required to obtain Feature Availability information using the general RPC functions NSLRemoteCall and NSLRemoteCallV.
| Parameter | Value for Feature Availability |
| rpcName |
A NULL terminated, UTF-8 encoded string containing the name of the remote procedure to be accessed. Should be initialised as "FEATAVAIL". |
| rpcReturn | On success contains the return information from the rpc as a NULL terminated, UTF-8 encoded string. For feature availability this will be the global number of feature seats/pool elements/consumption tokens available. |
| rpcVarNames | Must be set to "featCode". |
| rpcVarVals | This should be set to the 5-character feature ID. |
Wrapper Functions
Our example applications contain wrapper functions for NSLRemoteCallV in C#, VB.NET and Java. You may use these to help integrate this rpc into your application.