Blog

Tons of documents exist about Microsoft Dynamics NAV, but most of them start with marketing lingo, and don’t wander away too much from it altogether. While it is nice to know that it is a system which will give you freedom to focus on your business, it is also nice to know what is it made of, and how it works inside. Inspired by a total lack of resources which would give a clear picture of all the system components and their relationships, I wrote this post in hope someone might find it helpful.

Microsoft Dynamics NAV in currently available versions (somewhere it is 5.0, while somewhere it is 4.0 SP3) utilizes the two-tier architecture. This means that the system consists of a client, and a server (as opposed to a multi-tier architectures, where system consists of a client, a series of middle tier, or business-logic tier components, and a database tier). Dynamics NAV also utilizes so called fat-client architecture. This means that majority of the logic is executed on the client. In case of Dynamics NAV, the client executes all of the logic, while the server component is the database server, and is used only to store and maintain the data. Not that there is something inherently good or bad about any architecture, two- or multi-tier, fat or thin. All of them have their pro’s and con’s, and what Dynamics NAV really does well is leveraging the benefits of its architecture, while minimizing its drawbacks. More on this later.

Dynamics NAV may utilize two database server options. First one is so-called native database server, which was the only one available for a long time. This database engine has many exciting benefits, including extremely fast sum calculations (something of a crucial importance in many ERP solutions), but also had lots of limitations: it scales really bad with the number of concurrent connections, it can’t use more than a single processor and it can’t grow beyond certain limit (128 GB for version 4.0). All in all, this database option appeals most to small companies with a very limited number of concurrent users, because it is very cost effective.

The other option is the Microsoft SQL Server. You may use either version 2000 or 2005, just bear in mind that version 2005 can only be used with Dynamics NAV 4.0 and newer. SQL Server is used almost exclusively as a storage engine, although in latest version (4.0 and above) it may be used to maintain access control to the information. Compared to Dynamics NAV native database server, SQL Server brings tons of advantages, effectively eliminating all of the limitations of the former. SQL Server also offers something that native server never could, and that is record-level security, which means that access to the information can be limited on a record-per-record basis (such as, e.g. allowing users to work only with certain customers, or certain general ledger accounts). The only drawback of SQL Server, as compared to the native database server, is its cost – you have to pay for the SQL Server license.

Small companies can start with a native database server option, thus keeping their costs relatively low, then after they reach a critical concurrent users number or database size, they can painlessly migrate to SQL Server, literally in an hour or two. Since both native database and SQL Server client applications are installed during application setup, users will have to change the shortcut in order to connect to the new server, and from the server perspective migration is as simple as a backing up the database on native database server, and restoring it on SQL Server using backup/restore facility built in into the client application.

Regardless of the database server option used, user experience is the same, and when users log on to the system, they normally can’t tell the difference between the two. It’s that transparent.

Although the database layer is used only to store data, its purpose is twofold: it stores both the data and the application objects themselves. Application logic of Dynamics NAV is not built-in into the client application (as might be expected from a fat-client application), but it is stored in the database, and upon connection, application objects are read from the database on as-needed basis, and stored locally in the cache for quicker access. This allows for a very interesting feature – whenever the system needs to be upgraded, the only thing that has to be updated is the application objects in the database, this can be even done live. For clients to get updated it only takes restarting the client application. This approach makes minor upgrades hassle-free and there is no impact whatsoever on the normal course of the business.

There are several access control mechanisms built into the system. At the highest level of all there is the customer license. Whenever you purchase Dynamics NAV, you get a file which is called license file. This little encrypted piece of information contains the configuration of access rights to particular areas of the system. For example, a license may include access rights to general ledger module, sales order management module and basic inventory management module, while prohibiting access to manufacturing module or warehouse management module. These functional modules are called granules. There is no way to override the access configuration stored in the license.

The second level of access control is a typical role-based security control system, where users are assigned roles, which allow or deny access to particular application functions. The system comes with a pre-defined set of default roles based on least-privilege principle, which allows for fine tuning the access control to the application and sensitive data. Users are assigned the sets of roles based on their responsibilities, and they can access those areas of the system assigned to any of the roles users belong to. The more roles a user have, the more functional areas will be available to them.

The lowest level of access control is record level security, and it works only on SQL Server. It allows for even finer tuning of not only which tables users can access, but also which records in these tables will be, or won’t be, available to the users.

Dynamics NAV comes with an integrated development environment, called C/SIDE. It allows the access to all of the application objects and application logic, depending on the license level. Normally, customers don’t purchase the granules for development environment, and normally only implementing partners have access to C/SIDE. Development environment consists of several layers of objects: standard worldwide objects, localization objects, customer objects, and vertical solution objects. Standard worldwide objects are the system itself. Localization objects are prepared by local Microsoft office and contain the functionality required to achieve compliance with local legal requirements (such as VAT specifics, business practices or similar). Customer objects are whatever the partner has created during the implementation phase in order to support the customer-specific business processes that are not supported either by global or local functionality. And finally, vertical solution objects are similar to local objects, with the difference that they cover for the requirements of a specific business vertical, such as, e.g. food-and-beverage industry. Depending on the license level, customers and partners may gain full or limited access to the development environment for all of these object classes.

C/SIDE consists of seven types of objects. Tables are used to store data and execute business logic related to data validity and integrity. They are transparent to the users, and normally users can’t gain access to them directly. Forms are used to allow reading and writing of the information stored in the tables. They are primary component of the user interface, since users spend most of the time working with forms. Reports are used to present data in printable form, but also to perform certain data-driven tasks. Dataports are used to export and import data from and to the system in text format, and are primarily used for integration with external systems. XMLports are used also to export and import data, but in XML format, and are used for XML communication with external systems. Codeunits are blocks of code defining the business logic. They are completely transparent to the users, and their functions are invoked from other objects, such as e.g. upon pressing a button on a form. And finally, MenuSuites are used to group user interface elements into logical groups that are presented as navigational menus to the users.

Other than reading and executing the business logic stored in application objects, the client application provides access to non-business functions such as navigating through data, inserting or deleting records, filtering, sorting and searching. These functions are consistent throughout application, and no matter which form is displayed over whatever underlying table, they will always provide the same functionality with the same keyboard, menu and toolbar shortcuts. Client application is also responsible for user experience, such as creating favorite shortcuts, resizing the forms and reports, and customizing the list forms appeareance to the liking of the user. Users can choose which information will be displayed, in which order, add or remove columns of information or modify widths and heights of columns and rows, and whatever they do will affect only them, and nobody else. All of these settings are stored in the user profile and are reapplied after users start the application next time.

When users are displaying information in any form, all of the displayed information can be copied and pasted to Excel. Users can, for example, open the list of customers, show the balance information, copy the list and paste it to Excel, and then perform some calculations over it. No programming or customization is necessary, and it works from everywhere.

Lovely part of the system is that it is completely multilingual. By default it comes in English and local language (or only English, if it is the local language), but as many languages as necessary can be installed. Users can switch between languages without exiting the system, and every user of the system may choose any of the available languages, regardless of the languages used by other users. Multilingualism goes one step deeper also. If you are doing business with partners from different countries, documents can be printed out of the system in the language of these partners, even without the changing the user interface language.

Dynamics NAV has no built-in automation of tasks. This means that whatever the system will do must be invoked by a user. There are no automatic things happening in the system, such as displaying a window to one user when another user has done something relevant to the first one. There is a solution, however, and it is called Dynamics NAV Application Server. Application Server is used to connect to the database in no-user-interface mode, and invoke certain preprogrammed operations. If there is a need to call certain procedure once a day, such as e.g. posting of costs to general ledger, then Application Server can be configured (and programmed) to start this procedure at required time intervals.

Data stored in the system is grouped in logical domains called companies. It is possible to use many companies at the same time, and each of these companies will have completely separate information from all others, literally allowing customers to run different businesses on the same database.

That’s all for now. There are many other components of the system and I would be able to discuss them at length, but I have to leave something for future posts. This one has been lengthy and probably unorganized, as I dumped the information as it crossed my mind, but I hope it will be useful as a quick reference on how the system looks like from the inside, and what it is made of. As you can see, it is made of lot of stuff.

See you later!