Month: September 2015

Part 1: Why Do You Need to Understand the Technical Structure of Dynamics NAV

Why does a business decision maker need to know about the technical structure of the product I hear you ask? Well it keep to lots of restrictions about the way Dynamics NAV works and it’s performance so I am by explaining it to give you insight into that in this 6-part series.

Clients & Servers

First let’s look at what we ‘geeks’ call the client server structure. Put simply it means – what computing units do you need to run Dynamics NAV these days. I called them computing units deliberately because actually all three can be on the one physical computer or all three separate physical or virtual machines, or any variation in between.

First we have the bit that users interact with, which we call the client. This can be either a windows PC with programmes installed, a web browser used to connect to a Dynamics NAV web site or an app on our tablet of choice; ones from Apple, Google and Windows are supported.

These all have to talk to another computing unit called a middle tier. This is a ‘server’ that does all the processing of information, implementing your business logic and updating the information as you input it. The number of clients that can talk to one ‘middle tier’ depends on what they are doing, but I would not recommend over 50 where they are doing any serious work.

Finally, at the back we have the database server. This is simply a SQL database server which stores the information input after it has been processed and verified by the middle tier. You can only have one of these per system although they can be clustered to provide a level of fault tolerance if one falls over. Clustering SQL is expensive though and be prepared for eye watering increases in SQL licence costs (to enterprise edition) and to pay of two lots of hardware, one of which will just sit there in case it’s needed.

Finally, we can split the middle tier processing service from the web server, if the loading on the web server and mobile client makes it sensible. Splitting it off to a separate server is a performance and security decision rather than a fault tolerant one because if the middle tier doesn’t work then your web server won’t operate. Splitting it out then is only sensible when you either want to publish the website out onto the Internet and then having the web server in a special DMZ or buffer zone between the internet and your critical systems protects you against hackers.

The other reason is that your middle tier is running too slow and you need to create extra resource for it to use. Moving the web server to a separate service is one way to do that.

Having said all this Dynamics NAV can be installed all on a single machine that covers all three roles. We often run that way for a demo, development or testing purposes. It not recommended for any live system though and will be impossibly slow above just a few users.

Other things to think about? Should you have more than one middle tier just for resiliency in case one ‘goes down’. Well if your serious enough to need the guaranteed uptime of clustering then yes, you should. As standard you will have to set each group of users to point to a particular middle tier though so it’s not automatic fail over, they will have to know what to do if their server stops working.

Plus, there is no way as standard to load balance users across middle tier servers, which means you have to try to predict which one will be the most loaded.

The company I work for has a great solution to both these issues that’s simple and just works – so I’ll try to share that on a future blog post.

Executables

Well first there are what’s regarded as the ‘executables’ which are the programs that actually run on the servers and client. There are a set designed to run on their server and another set that are run on a suitable client such as your local windows PC. There is also a set which runs on your web server and provides the site through which you can access Dynamics NAV via a URL, from your web browser or via your tablet.

Just remember that all the server servers and clients have to be running the same version (and we do mean the same exact version) of the executables. If you upgrade the middle tier you need to upgrade the web server and all the computers with the client software installed at the same time.

Often after you upgrade the executables it will ‘upgrade’  the database which means it cannot be downgraded again (without some very clever and risky manual editing which you don’t want) so be sure you’ve back it up before upgrading your executables

Objects & Databases

In a ‘traditional’ (as opposed to multi tenanted) deployment NAV has the ‘objects’ are stored in each database along with the data for the companies created using that system. This means that all the companies have the same logic and data structure although differences in the setup options selected can introduce differences in the way they operate.

What do we mean by ‘objects’? Well there are thousands of definitions (In a specific programming language called C/SIDE) that control the information stored in each table and the business process logic options available. Customising the system means editing or adding to these Dynamics NAV objects.

Objects can be exported from one database to another in order to transfer functionality from one system to another. Users running Dynamics NAV will often hear a systems admin, consultant or developer say that they need to ‘import some new objects’ or ‘get that object changed’ which is how we change the logic your system has.

Note

This post is part of a 6-part series. A link to all the posts in this series are below;