We have developed some addon’s in our own local object ID range and we each time check in customer license whether they have permissions to run those object like
IF Granules.“XXX” THEN
EXIT(CheckObjectLicensePermission(LicPerm.“Object Type”::Codeunit,CODEUNIT::XXX))
But it is adding nearly 2 sec more while posting Sales Order.
Is there any method we can reduce no. of checks?
It’s a bit of a puzzle to me as to why you wouldn’t just let the NAV license do its job? If the client has a license to execute the objects then they should run without your intervention in code. Similarly if the client lacks the necessary license, the objects shouldn’t run, even without your intervention.
What is it about what you’re doing that can’t be accomplished by relying solely on the NAV license?
Assuming that there’s a good business case for implementing this license testing function, one way to improve performance would be to reduce the number of redundant calls to the function. I’d guess that your first step would be to determine the extent of redundant calls. If there are none, then this approach wouldn’t produce any noticeable results. If there are many, then you’re approach would be to record the parameters for each call and the result. Then you’d modify the function to check the local memory variables (as opposed to a NAV table that would require database io) that contain the results of prior calls before executing the rest of the function.
Another possible approach would be to read the Permission table into a temporary copy of the same record and then process the function against the temporary variable instead of the permanent table. You’ll take an overall performance hit to load the table, but if you make enough calls to it, the performance delta may eventually aggregate in your favor.
We have a setup table with all Granules (booleans)…
based on the activation of granule we need to either run Custom Code or Base code.
Ex:
IF Granule."XXX" the //this line will check the license permissions as I shown in first post
//CustomCode
ELSE
Standard Code;
Alright then, so maybe take a look at the two options discussed earlier.
And of course, you know all of this becomes moot if you publish your customizations as a licensable add-on through Microsoft? It involves some investment on your part, but the pay-off is that you don’t have to mess around with all of this overhead code.
Thank you for your patience.
I didnt understand this. what do you mean by licensable add-on?
Any of us who develop distributable customizations to NAV are free to register the customizations with Microsoft as a NAV Add-on. If you think of all of the products that you could license from Lanham, you’re thinking about add-ons that they have registered with Microsoft. There’s nothing stopping you from doing the same.
With the add-on registration, you purchase the objects you need for your customization just like end users purchase objects. Only in this case you get assigned an object number range that is specific to your add-on; no other objects anywhere will use those object numbers except you for your add-on. Then, when end-users or other solution centers want to use your add-on, they go to Microsoft to buy the objects in your add-on which allows them to run the objects in the package. They get an updated flf file with the new credentials. Then, after they’ve paid you, you install the objects on their system and make any necessary changes to existing objects.
The catch is that you owe Microsoft an annual maintenance fee for continuing to publish your add-on. To offset that, you charge your customers for annual maintenance. You can even configure the granule license so that no one can even open your objects in Designer, if you believe that’s in everyone’s best interest. You can find far more information about this on partner source or customer source.
Hope that helps.
Thank You again.
As I mentioned in my post, we have developed in our own object ID range. 11XXXXXX…
So, that being the case, how are your clients able to run those objects? That’s not a typical number range for “public” objects. Regardless of anything you do in your custom license validation functions, if the client’s fin.flf license doesn’t include permissions to run objects in your 11XXX range, they won’t run. And I’m not aware that client’s can just order objects in that number range. Well, it’s really a moot point that one.
So I guess we’ve come full circle. We’re back to the question on whether your custom CheckObjectLicensePermission function is performing any meaningful purpose. You won’t find anything like it anywhere else in standard NAV; the underlying premise being that the license file will manage access to licensed objects and block access to everything else. If this function is causing performance issues, take it out and let the chips fall where they may. When you’re implementing your custom objects at a client’s site, you would naturally re-point any existing calls to standard objects to your custom objects instead and rely on the correct license being in place. That’s the way every other add-on I’ve ever seen is implemented. No one I know of is testing the license file to decide what object to launch.
It’s like my old doctor used to say … “If it hurts when you do that, then don’t do it.” 
Well let me explain a bit more clearly.
We have a table where we have added all our granules.(around 50).
When I activate any of them, absed on the activation code should either run add-on code or Standard code.
In Order to check the granule activation, we are checking whether License has permission to run Add-on range object or not.(11XXXXXX).
Customizations are done in so many objects like Table 36, table 37, Codeunit 80, Codeunit 7000.
So each time we have to check whether Customer have permissions or not to either run custom code or standard code.
Which is increasing execution time…
Hope its clear. [:)]
OK, so that’s a bit more information. Just to check my understanding, this is something you have setup on your own database and not at client sites? And it sounds like you have all of your various add-ons in one database and you’re trying to turn them off and on individually at runtime? And you’re not actually checking the license file in the traditional sense, but rather you’re looking at a table that indicates the state (on or off) of each of your add-ons? I’m not at all clear how the license file ties into all of this or why it matters. Maybe you’re building a unique method for implementing or testing your add-ons?
So if we completely pass on the question of whether the design approach is a good idea, then we can go back to the first two possible means at your disposal for addressing the performance issues - eliminate redundant calls to the LicenseCheck function, and eliminate the load on the backbone by reading the data from the “setup” table into a memory variable once, then running your function against that data instead of the table in the database. What do you think? Is that worth a try?
Yes, we are also planning to do something similar in OnOpen company will be executed only once…and store the results in global variable kind of thing …
We have a seperate Codeunit for CHecking all these license checks.
we made that codeunit as Single Instance and created a global variable which will identify whether license is already checked before or not.
It will execute one time and from next time onwards returns result rather than checking everything.
Hope it helps.