Test the demo application

OK, ready to test! The Zentitle UI server side should be set up. You will have edited the config file and placed it in the demo app folder. You should open the Zentitle UI in your browser and have the test activation codes ready to paste into the desktop app.

Don't forget to add your customized .config file per the instructions and set up the server-side Zentitle UI, or nothing will work!

We will now start a range of tests back and forth between the desktop and the server-side Zentitle UI. Please have both open on your monitor so you can take action and then see what happens in both directions.

These tests will demonstrate the functionality of our "dynamic cloud" controlling your applications in the field.

Desktop app

Go to the new folder "OnPremDemoApp for testing," this was created when you unzipped the files provided.

The demo app will query the Zentitle server on the first run using the config file settings. In this case, the app has never been run before or activated using an activation code, so it shows with the functions greyed out and only one option to license the app as shown.

Ensure you have copied the test activation code from a previous step into your clipboard (or open the file with codes from the export).

Well done, you have a successful test!

Now, let's check what happened on the server side by returning to your account on the Zentitle UI.

Find the test entitlement.
Select the "Activations" tab on the top menu.
Review the record, and you should now see your activation record. You can check the seat ID name you set, the time, and the status of the activation. Here, we can see we have an active seat.

Of course, you could have also used the search function in Zentitle and found the entitlement that way, too.

Now we have activated a license, we can review the interaction with the server-side data and things we set up and how that is rendered in the desktop UI.

With the app open and in the activated state, you can now see that the feature section on the right is highlighted (vs. greyed out), and we have a range of choices to test.

There are three functions you can test other than the output format that are impacted by the license rules we set:

Encoding a file or files (up to the limit from our entitlement).
Change the number of processing threads (up to the limit from our entitlement).
Change the slider speed-quality change time needed to convert.

Before we test, let's also look at the data that's been rendered into the UI from data collected on this entitlement (from the attributes we set server side, as you can see top):

The top right section shows all the features and advanced features (threads) we added [4].
The bottom left shows the attribute "Company" [3] and the license end date based on the "Plan" we set for one year [2].
Bottom right, this shows the consumption token in use with a live count of how many (out of the 10 set) encoding tasks we can do [5] - in this case, one left and the "plan" attribute of standard [1] we also set.

Note in the images, that we have already used up 9/10 "files to convert" consumption tokens to show you what happens below.

So we can see in action the use of the various things we set up earlier and how they could be used in your app as required. Of course, there are a lot of other use cases, but this is a nice, simple one showing some ideas for you to think about.

Finally, we can also access useful data collected during the activation process by clicking on the "license" button again and selecting "License info."

Demonstrating consumption tokens in use

Now, let's try and use the demo app to encode a file. This is the function of this demo.

Now, let's use the app to encode a dummy file. These are provided in the app.

The "Processing" section on the left will show the results.

As you can see, the process worked; it made an MP3 file and used up the last of the files remaining on the count (yes, we did a set of previous actions to use up the ten allowed file conversions).

Now that the consumption limit has been hit, you see the right-hand section is greyed out again, like when not activated at the beginning - this shows you the consumption licensing controls in action. Now, the app won't convert files until more "files" are added to the entitlement or it's reset for reuse on the server side (or via the API, of course).

In the Zentitle UI, click the three dots to the right of the feature.
Click reset used count.

This alerts you about your action.
Click "reset".

Now you can see the feature count reset serverside.

Depending on your needs, you perform these actions using the API or the UI.

Let's restart the demo app on the desktop so that the app refreshes the license rights from the server (this is also done automatically by the lease time, but we will do it here for speed).

Now we can see on the desktop app we have all ten (10) file conversion uses again.

Of course, you can have as many consumption tokens as your business model requires.

This functionality is key in utility-based billing models.

Demonstrating element pools in use

Now, let's try another of the advanced features: the thread count. In this use case, we want to show an upgrade option i.e., the current entitlement is set at a certain level, and if you want a better/higher level, you need to upgrade to get it.

We could now edit that number server side to a larger number (after receiving payment), and the user would immediately get access to the feature until the limit is reached again.

Of course, you can have as many element pools as your business model requires.

This is the type of function used to control good, better, best models and suites of features in your business models. It is flexible and can be used to control any form of limits.

Demonstrating feature controls in use

Next, let's try editing the features (simulating a downgrade) on the server side and show how that removes functionality from the desktop app.

Using the same entitlement page as before, let's edit the features section and deselect certain features.

As you can see, the app has now removed the features we de-selected on the server side, showing you how to add or subtract features via the UI or the API based on what's happening with your client and their needs.

This type of complete control allows for upgrades, downgrades, and even to go between trial modes (i.e., downgrade features from a trial until paid).

This functionality can be useful if users don't pay and you wish to switch off their app automatically and remotely, as it can be attached to a commerce function using our API.

It could also be used for those non-paying clients where you wish to keep the app in use but wish to remove certain functionality until they pay again.

Demonstrating removing a license/license portability

Next, let's try and remove the seat by de-activating the license code to release it back to the server (i.e., to move the seat elsewhere like home > work, etc).

Now, you can instantly see the app is back to the previous state where we started.

Please navigate to the 2nd tab on the top menu of the entitlement we have been testing.
Check the same report that we checked previously and now you can see the seat has been removed and is free to be reused.

The report above shows the activation records with the seat ID, times, actions, and seat used.

The graph shows seat usage over time, which is more applicable to bulk licenses with many users.

This concludes our quick testing process, showing you the many uses of various options - there are many other variations of business models and uses for these flexible elements.

There are more tests you can try, like editing the parameters serverside to try and few more options, or feel free to keep testing by using our SDK and APIs in your own applications.