Test the demo application
Last updated
Last updated
Zentitle2
Service terms© Copyright - Nalpeiron, all rights reserved Website use subject to Terms and Conditions. See our Privacy Policy Use of Zentitle is subject to our Service Terms and Conditions
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.
Go to the new folder "OnPremDemoApp for testing," this was created when you unzipped the files provided.
Now go to run the "OrionOnPremDemo" Windows app in the "OnPremDemoApp" folder and start testing. If you need the desktop runtime, go here.
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.
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."
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.
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.
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.
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.
Let's jump on a call and discuss how we can help, get in touch with your account manager today → Setup a 1:1 discussion
Click the "license" button on the top right.
You will see a dialog box. Paste your test activation code here, and click the "Activate" button. This will test the link from the demo to the server, check if there are free seats on this app, and then activate if that is an allowed action.
In this case, the code was correct; seats were available on the rights for that entitlement and code, and the app was activated successfully. This shows we had the right setup in the config file and that the connection is working.
Click "add file." This adds a dummy file for you.
Click the output format.
Leave the rest of the settings for this test.
Click "Start Encoding".
Let's check the server side to see what's happened. Going back to the same page as before and checking the section on advanced features, you can see we went from 9/10 above to 10/10, i.e., no more allowed file conversions, which matches our experience on the desktop.
Now let's show you controlling the desktop again by resetting the consumption token count (as you would do if you sold another pack of uses, etc).
Let's try encoding another file as before, but this time, we will change the thread count to five (5) threads from the previous setting of one.
Click the start encoding button with five threads selected.
Now we get a pop-up that tells us that we have a maximum set at four (4) and we need to upgrade to use five.
Go back to the server side to check, and here we can see that we did set this to four (4) and that the action was correct.
On the top left section, click edit to change the entitlement features.
You can see all the features we previously added in the bottom middle section. For this test, de-select both the MP3 and OGG options by selecting them.
Click save.
Now, let's restart the app again and check the results on the desktop.
Click the "License" button again. Choose "Deactivate" and click that option.
Let's revisit the server side to check what happened there.
We can also check the activity log to see what's been happening on this entitlement over time. In our case, we activated and then deactivated once.
