Development for Localization

I promised in an earlier post to discuss what I see as the failings in the approach taken by Microsoft's Localization development team.

Here goes at least for a start.

The feature keys and their close cousins the security keys are a very underutilized tool in the product, they allow you in one case to disable entire parts of the system, that is to not even have a trace of the fields and tables in the database that are controlled by the feature keys. And in another case their close cousins the security keys are usefull tools to control the access for users to certain parts of the system.

So why do I start discussing these parts of the system in this context ?

In Ax you have two means of controlling how the software behaves ostensibly, one is through the feature keys and the security keys, the other is through parameters in the parm tables that are part of each of the modules in the product.

The localization team often ties a feature key (the country feature key) onto any given countries localization objects, this enables us as implementers / users to by enabling / disabling the country feature key to remove the fields & perhaps tables that are specific to any one country from the system.

However in multi country installations you want the fields but in countries not concerned you just want them to be empty and inaccessible.

So you cannot disable the feature key, you can however use the feature key as a security key and create user groups that have access one way or the other to the system in the different companies, this does not however provide the answer to our prayers as regards having a shared localized system.

For an example of how bad it is take a look at the CE layer from V3 SP4 onwards, and specifically only one class SalesFormLetter_Invoice which provides the system with the functionality of creating an invoice and updating all relevant associated tables.

Let us again narrow it down to just one method remember what we see here is present throughout the classes that are modified for localization purposes. The method is a key one in the SalesFormLetter_Invoice it is called UpdateNow and is the main executing method in the invoice update process.

As you can see here is an example of the use of a configuration key test to determine whether code should be executed.










Unfortunately in a multi country implementation of Axapta the configuration key would be enabled even though you do not want the code to be executed for some companies so it is not very smart to test the configuration key, rather one needs to setup a parameter that controls the behaviour instead.

Here is an another example of a configuration key test. And in other parts of the code in just this one method of this one class there are examples of code additions that do not test for anything prior to being executed.

I have been called out to a customer implementation in Russia, where they were having trouble with the speed of their system, aside from finding issues in the added code that the partner had added. I also found that the invoice update process spent 5-15 sec's for each invoice update running a multi level select statement for no gain as the field in which the result was stored was disabled by a configuration key.

A select maxof is done on the inventrans linked to all the salesparmlines that are being updated, in the case where group updates are being done or serial numbers the above takes a long time, and as there is no index availeable sometimes SQL will be confused and do a full table scan on inventrans which takes a very long time.

In other methods added for localization the configuration key concerned is tested, again my comment is this works for a single country implementation but multi country implementations just do not function based on this principle.

So what do I recommend

GDL should lay down some ground rules for their developpment efforts.

1. Any functionality added needs to be parameter controlled in the code, as well as being configuration controlled in the Tables / Fields.

2. All functionality must be tested for non regression after implementation of localization code.

3. All code should be unit tested against large databases to ensure that the code can withstand / be used on larger scale implementations.

These rules shloud be applied on top of all the usual Development Best Practice rules that should of course also be followed :-).

Really this article is only about the very first one but as I am stating a wish list why not include the other items on the list.

/Sven

PS for some reason or other the JPG's turn out awfull as far as readability is concerned and the BMP's are worse anyhow will tinker to get them right.