NAV 2009: A set of building blocks and development tools

If you look at NAV 2009 from the point of view of a developer, you may see it as a set of customizable off-the-shelf program objects (the building blocks) plus the IDE which allows you to modify those objects and create new ones (the C/SIDE development tools).

The NAV 2009 system is an object-based system, consisting of several thousand application objects, the building blocks, made up of the eight different object types available in NAV. NAV does not have all of the features of an object-oriented system. A full-featured object-oriented system would allow the definition and creation of new object types, while NAV only allows for the creation and modification of the predefined object types.

NAV object types

Let’s start with some basic definitions of the object types that are part of NAV:

• Table: Tables are the definers and containers of data.
• Form: Forms are the screen display constructs for the Classic Client user interface.
• Page: Pages are the screen display constructs for the Role Tailored Client user interface. Pages are designed and rendered (displayed) using technology that is new to NAV 2009.
• Report: Reports allow the display of data to the user in “hardcopy” format, either onscreen (preview mode) or via a printer device. Report objects can also update data in processes with or without accompanying data display output.
• Dataport: Dataports allow the importing and exporting of data from/to external files in the Classic Client.
• XMLport: XMLports are similar to Dataports. In the Classic Client, XMLports are specific only to XML files and XML formatted data. In the Role Tailored Client, XMLports handle the tasks of both XMLports and Dataports.
• Codeunit: Codeunits are containers for code, always structured in code segments called functions.
• MenuSuite: MenuSuites contain menus which refer in turn to other types of objects. MenuSuites are structured differently from other objects, especially since they cannot contain any code or logic. In the Role Tailored Client, MenuSuites are translated into Navigation Pane menu entries.

The C/SIDE Integrated Development Environment

NAV includes a full set of software development tools. All NAV development tools are accessed through the C/SIDE Integrated Development Environment. This environment and its full complement of tools are generally just referred to as C/SIDE. C/SIDE includes the C/AL compiler. All NAV programming uses C/AL. No NAV development can be done without using C/SIDE.

The C/SIDE Integrated Development Environment is referred to as the Object Designer within NAV. It is accessed through the Tools  Object Designer menu |option as shown in the following screenshot:

The language in which NAV is coded is C/AL. A sample of some C/AL code is shown as follows. C/AL syntax has considerable similarity to Pascal. As with any programming language, readability is enhanced by careful programmer attention to structure, logical variable naming, process flow consistent with that of the code in the base product and good documentation both inside and outside of the code.

Insert code1

A large portion of the NAV system is defined by tabular entries, properties, and references. This doesn’t reduce the requirement for the developer to understand the code, but it does allow some very significant applications development work to be done on a more of a point-and-choose or fill-in-the-blank approach than the traditional “grind it out” approach to coding. NAV gives developers the ability to focus on design rather than code. Much of the time, the effort required to create a new NAV application or modification will be heavily weighted on the side of design time, rather than technical development time. This long term goal for systems development tools has always been true for NAV. As the tools mature, NAV development continues to be more and more heavily weighted to design time rather than coding time.

Object Designer tool icons

The following screenshot shows a list of Object Designer tool icons. These Object Designer icons are shown isolated in the screenshot and then described briefly in the following table. Some of these icons apply to actions that are only for objects which run in the Classic Client, some are for objects for both clients. Additional information is available in the C/SIDE Help files and the Microsoft NAV documentation.

The following table lists the specific development tools used for each object type. Also, as shown in this table, some objects are limited to being used in the Classic Client, some are limited to being used in the RTC environment, some are used in both, and some are interpreted differently depending on the environment in which they are invoked.

NAV object and system elements

Let’s take a look at the following:

• Database: NAV has two physical database options. One is the C/SIDE Database Server; the other is the Microsoft SQL Server. The C/SIDE Database Server, formerly known as the “Native” database, only supports the two-tier client. The NAV 2009 three-tier functionality is only compatible with a SQL Server implementation. You won’t be surprised to know that one or two product versions in the future, the only database option will be SQL Server. At the basic application or code design levels, you don’t care which database is being used. For sophisticated or high data volume applications you care a great deal about the underlying database strengths, weaknesses and features.
• Properties: These are the attributes of the element (for example object, data field, or control) that define some aspect of its behavior or use. For example, attributes such as display length, font type or size, and if the elements are either editable or viewable.
• Fields: These are the individual data items, defined either in a table or in the working storage of an object.
• Records: These are groups of fields (data items) that are handled as a unit in most Input/Output operations. The table data consists of rows of records with columns consisting of fields.
• Controls: These are containers for constants and data. A control corresponds to a User Interface element on a form/page or a report. The visible displays in reports and forms consist primarily of controls.
• Triggers: The generic definition is a mechanism that initiates (fires) an action when an event occurs and is communicated to the application object. A trigger is either empty or contains code that is executed when the associated event fires the trigger. Each object type has its own set of predefined triggers. The event trigger name begins with the word “On” such as OnInsert, OnOpenPage, and OnNextRecord. NAV triggers have some similarities to those in SQL, but they are not the same. NAV triggers are locations within the various objects where a developer can place comments or C/AL code.
• When you look at the C/AL code of an object in its Designer, the following have a physical resemblance to the NAV event based triggers:
  • Documentation which can contain comments only, no executable code. Every object type except MenuSuite has a single Documentation section at the beginning.
  • Functions which can be defined by the developer. They represent callable routines that can be accessed from other C/AL code either inside or outside the object where the called function resides. Many functions are provided as part of the standard product. As a developer, you may add your own custom functions as needed.
  • Object numbers and field numbers: The object numbers from 1 (one) to 50,000 and in the 99,000,000 (99 million) range are reserved for use by NAV as part of the base product. Objects in this number range can be modified or deleted, but not created with a developer’s license. Field numbers are often assigned in ranges matching the related object numbers (that is starting with 1 for fields relating to objects numbered 1 to 50,000, starting with 99,000,000 for fields in objects in the 99,000,000 and up number range). Object and field numbers from 50,001 to 99,999 are generally available to the rest of us for assignment as part of customizations developed in the field using a normal development license. But object numbers from 90,000 to 99,999 should not be used for permanent objects as those numbers are often used in training materials. Microsoft allocates other ranges of object and field numbers to Independent Software Vendor (ISV) developers for their add-on enhancements. Some of these (in the 14,000,000 range in North America, other ranges for other geographic regions) can be accessed, modified, or deleted, but not created using a normal development license. Others (such as in the 37,000,000 range) can be executed, but not viewed or modified with a typical development license. The following table summarizes the content as:

  Object Number range	Usage
  1 – 9,999	Base-application objects
  10,000 – 49,999	Country-specific objects
  50,000 – 99,999	Customer-specific objects
  100,000 – 98,999,999	Partner-created objects
  Above 98,999,999	Microsoft territory