CHAPTER 1: CLIENT/SERVER INTEGRATED DEVELOPMENT ENVIRONMENT (C/SIDE)

Chapter 1: Client/Server Integrated Development Environment (C/SIDE) CHAPTER 1: CLIENT/SERVER INTEGRATED DEVELOPMENT ENVIRONMENT (C/SIDE) Objectives Introduction The objectives are: Discuss Basic Objects in Microsoft Dynamics NAV 2009. Describe fundamental aspects of C/SIDE development, including the UI, application objects, C/SIDE concepts, and the types of databases. Discuss the database structure. Describes some integration tools and advanced development concepts. The starting point to learn developing solutions in Microsoft Dynamics NAV 2009 is to understand the basic objects available in Microsoft Dynamics NAV, understand the Client / Server Integrated Development Environment (C/SIDE, which is the development environment for Microsoft Dynamics NAV) fundamentals and understand the concepts of the database structure. 1-1

C/SIDE Introduction in Microsoft Dynamics NAV 2009 Basic Objects in Microsoft Dynamics NAV There are eight basic objects available in Microsoft Dynamics NAV 2009, they are as follows: Object Tables Forms Pages Reports Dataports XMLports Codeunits MenuSuites Description Used to describe how data is stored in the database and how it is retrieved. Understanding tables is the key to using all of the other objects in C/SIDE. Used to display data to users in the Microsoft Dynamics NAV Classic client. Forms allow users to add records to a table, and to view and modify records. Used to display data to users in the Microsoft Dynamics NAV RoleTailored client. Pages allow users to add records to a table, and to view and modify records. Used to summarize and print detailed information by using filters and sorting, which are selected by the users. Used to export or import table data in text format. Not supported in the RoleTailored client. Used to export or import table data in XML format. In the RoleTailored client, XMLports replace Dataports as a means to export and import data, even in text format. Used to organize and group code which is written by the developers. Used to contain menus that are displayed in the Navigation Pane in the Classic client and the Departments page in the RoleTailored client. Is Microsoft Dynamics NAV Object Oriented? Microsoft Dynamics NAV is not object-oriented but object-based. This is an important distinction. In an object-oriented language or environment, developers can create new types of objects based on the ones that are already in the system. In C/SIDE, developers have eight types of application objects and that is all. Developers can create and use Tables, Forms, Pages, Reports, Dataports, XMLports, Codeunits, and MenuSuites, but nothing else. Limiting developers to use these eight objects makes their work faster and more efficient. The biggest benefit from this limitation is stability. It is fairly difficult to create a severe bug in C/SIDE. 1-2

Chapter 1: Client/Server Integrated Development Environment (C/SIDE) C/SIDE Fundamentals A C/SIDE application is composed of the eight types of application objects, which are described in the previous lesson. Each application object is created using a specific designer. For example, tables are created with the Table Designer, pages are created with the Page Designer, and so on. FIGURE 1.1 THE CLASSIC CLIENT WITH TABLE DESIGNER OPENED The application objects which are created by using designers are all based on several general concepts. A fundamental knowledge of these concepts speeds up the C/SIDE application development process. C/SIDE User Interface C/SIDE is accessed from the Classic client. The C/SIDE user interface is composed of the following: Object Designer, which contains designers for each of the eight object types. Navigation Pane Designer, which is used to arrange MenuSuites on the Navigation Pane. Various Tools and Editors, including a Toolbox for adding controls to forms, a C/AL Editor for editing code, a Properties window, a Debugger, and other tools and editors. 1-3

C/SIDE Introduction in Microsoft Dynamics NAV 2009 The user interface gives access to a number of tools and functions. Some parts of the user interface also provide information about the current state of the system. To... Get information about the name and path of the current database Access functions on drop-down menus Access the frequently used functions Work with the application design tools View basic status information about the system (such as the current date and user ID) Use the... Title Bar Menu Bar Toolbar Work Area Status Bar Depending on the task the users are working on, the system automatically changes the menus and icons in the Menu Bar and the Toolbar. Design Application Objects Any application designed in C/SIDE is based on the eight different types of application objects available through the Object Designer. Tables are the fundamental objects that store the actual data. Other application objects are needed to insert, modify, delete, or view data from tables. A form or a page is typically used to enter or retrieve data from the database and a report is used to print data. NOTE: All application objects are identified by an ID number. There are, however, restrictions about which numbers can be used when creating application objects. In the Object Designer, select the type of application object to work on. The following can be done from the Object Designer: Run an application object (except for page, XMLport and MenuSuite objects.) 1-4

Chapter 1: Client/Server Integrated Development Environment (C/SIDE) Open the application object designer to modify an existing object. Create a new application object. FIGURE 1.2 THE OBJECT DESIGNER The following table lists the tools that are accessed from the Object Designer and when to use them. Use the Table Designer Form Designer Page Designer Report Designer Dataport Designer XMLport Designer C/AL Editor Navigation Pane Designer When working on Tables Forms Pages Reports Dataports XMLports Codeunits MenuSuites There is a specific designer for each type of application object. When creating or modifying an application, developers can work on any number of application objects at the same time, and each application object is shown in its own designer. For example, if a developer works on three pages at the same time, each page is displayed in its own Page Designer. The Navigation Pane Designer is the only designer that cannot have more than one instance running at a time. 1-5

C/SIDE Introduction in Microsoft Dynamics NAV 2009 General C/SIDE Concepts The eight application object types are based on some general concepts. Some of these concepts are restricted to one type of application object whereas others apply to several types. The following table summarizes how the application objects are related to these general concepts and explains for what each type of application object is used. Application Object Type Table Form Page Report Dataport XMLport Uses A table is used for storing the actual data. Typically a business application has a Customer table that stores information such as name, address, phone number, and contact person for each customer. A form is used to access the information contained in tables in the Classic client. Forms are used when users enter new information and when they view existing information. A page is used to access the information contained in tables in the RoleTailored client. Pages are used when users enter new information and when they view existing information. A report is used to present data that contains summary information. For example, use a report to print a list of customers. A dataport is used to import and export information to and from other programs in a text format (for example, a commaseparated text file). Dataports are used only in the Classic client. An XMLport is used to import and export information to and from other programs in an XML format. XMLports simplify and streamline the process of exchanging data in XML documents. In the RoleTailored client, XMLports are also used to import and export Concepts Properties, Fields, Field Groups, Keys, C/AL, Triggers Properties, C/AL, Controls, Triggers Properties, C/AL, Controls, Triggers Properties, C/AL, DataItems, Sections, Controls, Triggers, RequestForm, RequestPage, Client Report Definition ( RDLC) report layout Properties, C/AL, DataItems, RequestForm, Triggers Properties, C/AL, NodeNames, NodeTypes, XMLport Events, RequestPage 1-6

Chapter 1: Client/Server Integrated Development Environment (C/SIDE) Codeunit MenuSuite information in a text format. A codeunit contains user-defined functions written in C/AL code. These functions can be used from the other objects in the application. This minimizes the size of the application because the same code can be reused. A MenuSuite contains the menus displayed in the Navigation Pane and in the Departments Page. C/AL, Triggers Menu Node, Menu Group, Menu Item Terminologies The following shows descriptions of several terms in the third column: Properties: Properties control the appearance and behavior of application objects and all sub-objects. Properties are used to control the appearance of data, specify default values, specify colors, and define relationships. C/AL: C/AL is the language used for writing functions in C/SIDE. In the previous table, C/AL refers to functions written in this language. Triggers: When specific things happen to the application objects, the system automatically activates a trigger. Inside a trigger, developers can add C/AL code if they want to modify the default behavior of the application object or extend its functionality. Fields: A field is the smallest unit of information in the database. A field typically stores information such as a name or a number. Keys: A key defines the order in which data is stored in the tables. Speed up searches in tables by defining several keys to sort information in different ways. Controls: Controls are objects on a form or report that display data, perform actions or decorate the form. Typical examples are command buttons and text labels. Request Form: A request form is a form used in a report or a dataport. Before a report or a dataport is run, a request form appears to let the user specify filters and options for the report or the dataport. Request Page: A request page is the request form equivalent in the RoleTailored client. 1-7

C/SIDE Introduction in Microsoft Dynamics NAV 2009 Data Items: A data item is a building block used for defining a model of data when creating a report or a dataport. By using a hierarchy of data items, developers define which data to include in the report. A data item represents a table and when a report is run, the system cycles through the records in the associated table. In a report, a data item can have one or more sections. Sections: A section is a substructure of a data item. A section is where controls are placed to display information. Generally, sections are used to define the body, header, and footer in the report. NodeName: NodeNames are used to specify the name of a node in an XML document. The name specified is inserted in the NodeName field of the XMLport Designer of the element or attribute in question. NodeTypes: This property is used to specify whether an XML object is an element or an attribute. Menu Node: A Menu Node can be either a Menu Group or a Menu Item. Menu Group: A Menu Group is a collection of Menu Nodes. Menu Item: A Menu Item is the lowest level of the menu tree. It is associated with a specific application object. The Physical and the Logical Database Typical database users are not concerned with where each piece of data is stored on the hard disk or what its size is; they just want to be sure that when they refer to a name, the correct value is returned. This is why the C/SIDE database system provides a conceptual representation of data that does not include too many details about how the data is stored. An abstract data model is used for this conceptual representation. This data model uses logical concepts (such as objects, their properties, and their relations) that are easier to understand. Therefore, it is helpful to distinguish between the logical and the physical database. When speaking about the logical database, only be concerned with the structure of the data and the relationships between different bits of information. That is, users do not deal with how these structures and relations are implemented. The physical database deals with how the structures in the logical database and the search paths between them are implemented. When the term database is used, it generally refers to the logical database unless otherwise noted. 1-8

Chapter 1: Client/Server Integrated Development Environment (C/SIDE) What is visible to the user as a coherent set of information in the C/SIDE database system can be stored in several physical disk files, but this is transparent to the user. The following figure illustrates how one logical database can be physically stored on three hard disks but still comprise a single (logical) database. FIGURE 1.3 ILLUSTRATION OF LOGICAL VERSUS PHYSICAL DATABASE Access to the data is made possible by a well-defined logical organization composed of: Fields Fields Records Tables Companies A field is the smallest logical structure used in the C/SIDE database. A field is used to hold a single bit of information, such as a name or an amount. Any particular field can hold information of only one specific type. Fields are assembled into a structure called a record. On its own, a field is not useful as it can hold only a limited amount of information. Having these small bits of information assembled into records results in a much more flexible "information-holder" that is also better organized because it groups fields that belong together. Records A record is a logical structure assembled from an arbitrary number of fields; it is used to store a single entry in the database. The fields in a record are used to store information about important properties of the entry. Records are organized in tables. Tables A table can be thought of as an N times M matrix. Each of the N rows describes a record and each of the M columns describes a field in the record. Tables are organized in companies. 1-9

C/SIDE Introduction in Microsoft Dynamics NAV 2009 Companies A company is the largest logical structure used in a C/SIDE database. A company may be considered as a sub-database; its primary use is to separate and group large portions of data in a database. A company can contain private tables and tables that are shared with other companies. Integration Tools FIGURE 1.4 RELATIONSHIP OF LOGICAL DATABASE STRUCTURE Microsoft Dynamics NAV 2009 provides several integration tools that can be used inside or outside of Microsoft Dynamics NAV to integrate to other applications. Web Services Web services are a standardized way for independent software systems to communicate with one another over standard Internet protocols. Web services architecture is designed for dynamic program-to-program interaction. Microsoft Dynamics NAV 2009 supports Web services, which makes it easy to integrate Microsoft Dynamics NAV with other systems. This is possible with the introduction of Microsoft Dynamics NAV Server. There are several types of Web service in Microsoft Dynamics NAV 2009: The simplest Web service type is developed by using the page object. By using the page object, Microsoft Dynamics NAV constructs a default Web service that has a fixed set of methods. Generally, it corresponds to general data access, such as get and set individual values or retrieves and updates lists of values. Another Web service type involves including codeunits and the functions from those codeunits in the Web service. The last type of Web service includes the ability to pass complex data types by using an XMLport object as a parameter in a codeunit function. 1-10

Chapter 1: Client/Server Integrated Development Environment (C/SIDE) ODBC Open DataBase Connectivity, or ODBC, is a standard database access method developed by Microsoft. The goal of ODBC is to make it possible to access any data from any application regardless of which database management system (DBMS) is handling the data. ODBC manages the access of data by inserting a middle layer called a database driver between an application and the DBMS. The purpose of the middle layer is to translate the application's data queries into commands that the DBMS understands. For this to work, both the application and the DBMS must be ODBC-compliant; that is, the application must be capable of issuing ODBC commands and the DBMS must be capable of responding to them. C/FRONT C/FRONT is an application programming interface that can be used to access a Microsoft Dynamics NAV database. C/FRONT facilitates high-level interaction with the Microsoft Dynamics NAV database and enables developers to manipulate any Microsoft Dynamics NAV database. The central component of C/FRONT is a library of C functions. These functions provide access to every aspect of data storage and maintenance, and enable the integration of both standard and custom applications with a Microsoft Dynamics NAV database. C/FRONT comes as a DLL for direct linkage with a program and also as an OCX that a program can use. OCX OLE Custom control, or OCX, is an independent program module that can be accessed by other programs in a Microsoft Windows environment. OCX controls end with an.ocx extension. OCX controls represent Microsoft's second generation of control architecture, the first being VBX controls written in Visual Basic. Both VBX and OCX controls have now been superseded by Microsoft ActiveX controls. However, ActiveX is backward compatible with OCX controls which means that ActiveX containers such as Microsoft Internet Explorer can execute OCX components. There is a vast array of commercially available OCXs that perform a variety of tasks and developers can produce their own. They can use tools such as Microsoft Visual C++ or Visual Basic to create OCXs that can be called by Microsoft Dynamics NAV. 1-11

C/SIDE Introduction in Microsoft Dynamics NAV 2009 Summary Automation OLE Automation is the name for the ability of one program to expose any or all of its capability for another program to use. The program that provides the functionality being called is the Automation server and the program that uses the functionality of the Automation server is the Automation controller (or client). C/SIDE supports Automation servers by acting as an Automation controller and by using OCXs (custom controls). However, Microsoft Dynamics NAV is not an Automation server. The most common use of Automation within Microsoft Dynamics NAV is to control applications such as Microsoft Word, Microsoft Excel, and Microsoft Outlook. Both OCX and Automation are part of Microsoft COM technologies. Developers who plan to use existing COM objects from C/SIDE, such as controls or Automation servers, do not need a complete understanding of COM. Although, understanding how to use objects and how to access the COM object may be necessary. Using the functionality provided by a COM object is no different than using any C/AL function. A thorough understanding of C/SIDE enables developers to streamline their development processes by learning how to develop customizations and integrations for the Microsoft Dynamics NAV system. This training material explains how to navigate within the development environment, how to create and use the basic objects, and how to implement best practices for ensuring smooth software upgrades in the future. Additional resources (Microsoft Dynamics NAV 2009 Developer and IT Pro Documentation) can be found in the following locations: Location Address Download Center http://go.microsoft.com/fwlink/?linkid=126282 MSDN http://go.microsoft.com/fwlink/?linkid=126283 1-12

Chapter 1: Client/Server Integrated Development Environment (C/SIDE) Quick Interaction: Lessons Learned Take a moment and write down three Key Points you have learned from this chapter 1. 2. 3. 1-13

C/SIDE Introduction in Microsoft Dynamics NAV 2009 1-14