Let's finish up our introductory review of NAV's object types.

A codeunit is a container for chunks of C/AL code to be called from other objects. These chunks of code are called Functions. Functions can be called from any of the other NAV object types that can contain C/AL code. Codeunits can also be exposed (published) as Web Services. This allows the functions within a published codeunit to be invoked by external routines.

Codeunits are suited structurally to contain only functions. Even though functions could be placed in other object types, the other object types have superstructures that relate to their designed primary use, such as pages, reports, and so on.

Codeunits act only as a container for C/AL coded functions. They have no auxiliary functions, no method of direct user interaction, and no pre-defined processing. Even if we are creating only one or two functions and they are closely related to the primary activity of a particular object, if these functions are needed from both inside and outside of the report, the best practice is still to locate those functions in a codeunit. For more guidance, see NAV Design Pattern of the Week - the Hooks Pattern at http://blogs.msdn.com/b/nav/archive/2014/03/16/nav-design-pattern-of-the-week-the-hooks-pattern.aspx.

There are several codeunits delivered as part of the standard NAV product, which are really function libraries. These codeunits consist totally of utility routines, generally organized on some functional basis (for example, associated with Dimensions or some aspect of Manufacturing or some aspect of Warehouse management). Many of these can be found by filtering the Codeunit Names on the Management and Mgt strings (the same could be said for some of the tables with the string Buffer in their name). When we customize a system, we should create our own function library codeunits to consolidate our customizations and make software maintenance easier. Some developers create their own libraries of favorite special functions and include a function library codeunit in systems on which they work.

If a codeunit is structured very simply and can operate in a standalone mode, it is feasible to test it in the same way one would test a report or a page. Highlight the codeunit and click on the Run button. The codeunit will run for a single cycle. However, most codeunits are more complex and must be tested by a calling routine.

Queries are objects whose purpose is to create extracted sets of data from the NAV database and do so very efficiently. NAV 2017 Queries translate directly into T-SQL query statements and run on the SQL Server side rather than on the NAV Service Tier. A query can extract data from a single table or multiple tables. In the process of extracting data, a query can do different types of join (Inner Join, Outer Join, or Cross Join), can filter, can calculate FlowFields (special NAV calculations that are discussed in detail in Chapter 3, Data Types and Fields), can sort, and can create sums and averages. Queries obey the NAV data structure business logic.

The output of a query can be a CSV file (useful for Excel charts), an XML file (for charts or external applications), or an Odata file for a web service. Queries can be published for web service access similarly to pages and codeunits. The results of a query can also be viewed by pages (as described in Chapter 5, Queries and Reports) and Cues (as described in the Walkthrough: Creating a Cue Based on a Normal Field and a Query documentation section (https://msdn.microsoft.com/en-us/dynamics-nav/walkthrough--creating-a-cue-based-on-a-normal-field-and-a-query)), but are especially powerful when output to charts. With a little creativity, a query can also be used to feed data to a page or report via use of a temporary table to hold the query results.

MenuSuites are the objects that are displayed in the Navigation Menus. They differ considerably from the other object types we have discussed earlier because they have a completely different structure and they are maintained differently. MenuSuite entries do not contain triggers. The only customization that can be done with MenuSuites is to add, delete, or edit menu entries that are made up of a small set of properties.

In the RTC, the data in the MenuSuites object is presented in the Departments page.

XMLports are a tool for importing and exporting data. XMLports handle both XML structured data and other external text data formats. XML (eXtensible Markup Language) is the de facto standard for exchanging data between dissimilar systems. For example, XMLports could be used to communicate between our NAV ERP system and our accounting firm's financial analysis and tax preparation system.

XML is designed to be extensible, which means that we can create or extend the definition as long as we communicate the defined XML format to our correspondents. There is a standard set of syntax rules to which XML formats must conform. A lot of new software uses XML. For example, the new versions of Microsoft Office are quite XML friendly. All web services communications are in the form of an exchange of XML structured data.

The non-XML text data files handled by XMLports fall into two categories. One is known as comma-separated value or comma-delimited files (usually having a .csv file extension). Of course, the delimiters don't have to be commas. The other category is fixed format, in which the length and relative position of each field is pre-defined.

XMLports can contain C/AL logic for any type of appropriate data manipulation, either when importing or exporting. Functions such as editing, validating, combining, filtering, and so on can be applied to the data as it passes through an XMLport.