Chapter 8. Development Considerations

Almost every Microsoft Dynamics NAV implementation will have some development. The customized code must fit inside the standard code within Microsoft Dynamics NAV, and it should look like it was a part of the standard Microsoft Dynamics NAV. This makes it easier for the users to understand how the customized modules work and for the partners to support it. A good initial development also makes any future changes easier and more efficient, for both the customer and the partner.

Now let's talk about development in Microsoft Dynamics 365 Business Central on-premise and SaaS. Microsoft Dynamics 365 Business Central will have some development, but the development model is different. For the on-premise release, it is still possible to develop applications defined "internal" (not based on extensions), but they will be deprecate in the near future-year 2020; for the SaaS release, it's not possible to modify the standard code, and only extensions can be used to...

Development in Microsoft Dynamics NAV and Business Central general concepts – setup versus customization

Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central offer many configuration options within all of the modules. These options make ERPs work differently in different companies, depending on the option selected; for example, you could define that your locations will use warehouse documents for shipping or process shipping directly from the sales order.

When you set up a new company, you will find more than 200 tables that can be considered setup tables. You will find the setup table of each module, its journals, and its sections. In addition, there are global setups, such as the accounting periods, the payment terms, and dimensions.

You will find there are hundreds of setup options in the base Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central product. It is really difficult for a person who does not work with ERPs full time to be aware of all the options and...

Data model principles

After analyzing the standard functionality, if there are needs to do custom development, it is important to develop the solution with the same structure that Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central on-premise use in their modules (it's necessary to follow the standard of product).

Note

For Microsoft Dynamics 365 Business Central, SaaS is different because it is not possible to access the source code and it is possible to develop customizations only through extensions; this will be discussed in the following paragraphs.

The users that are going to use the functionalities are users that are also going to use the standard parts of the application. To avoid confusing them, it is essential to use the same philosophy and the same structure everywhere. This way, once a user knows one part of the application, they can intuitively use the other modules.

This is something that will also help us; we do not have to reinvent the wheel every time. There is...

Personalization feature versus "In-client" Designer feature in Web client

What are the differences between using the personalization feature and in-client designer feature with Web client? In Microsoft Dynamics 365 Business Central SaaS, with sandboxes you have both at hands, while in production you only have personalization. In shorts, there is also personalization feature that could be used if you want to add fields hidden on a page.

"In-client" Designer—you can use the "In-client" Designer feature to personalize your page:

Put the cursor on Customize Fields and select the Add Field to Page option. After a drag and drop operation on a selected field (in this case, the Height field), the field will be added to the Items list page, as shown in the following screenshot:

When you have completed the customization, click on Done to save it:

The customized Item Units of Measure page now has the new fields added, as you can see in the following screenshot:

So, remember that if you want a field from...

Development methods – the CSIDE Development Environment and the New Modern Development Environment

It's possible to develop both with the CSIDE Development Environment and with the New Modern Development Environment in Microsoft Dynamics NAV 2018 and in Microsoft Dynamics 365 Business Central on-premise; for Microsoft Dynamics 365 Business Central SaaS, it is possible to use only the New Modern Development Environment.

Working with the CSIDE Development Environment

Though it is still possible (at the time of writing this book) to develop with the CSIDE Development Environment. To open the Development Environment, you have to install Microsoft Dynamics NAV Development Environment (or Microsoft Dynamics 365 Business Central Development Environment, the appearance and the name are similar). Open it and navigate to Tools | Object Designer (or press Shift + F12). The following window will open:

On the left-hand side, you will find a number of icons representing the different objects available. On...

The posting process

The posting process is the most important process in Microsoft Dynamics NAV. It commits the data entered by the users into the financial ledgers. There are a few different posting processes; however, they all follow the same structure. The posting process runs through a lot of code from a lot of functions. In fact, many functions are executed many times. This section does not cover the posting process in depth; instead, it shows the overview of the codeunits and how they are structured.

There are several posting routines, one for each journal table and one for each group of documents. All posting routines use more than one codeunit. In Microsoft Dynamics NAV, you can find more than 80 codeunits with the word post in their description. That's quite a few!

Let's see a couple of examples of the posting codeunits' structure. The first example is the posting codeunits for sales documents. In the second example, we will see posting codeunits for General Journal lines.

The codeunit...

Where to write customized code

While writing your own customized code for Microsoft Dynamics NAV, it is important to choose where to write that code. Code can be written in different places, and the application will still work as you had intended. Unfortunately, not all places are good choices. Depending on where you write your code, it may be easier or more difficult to expand or change functionality.

As already mentioned, developing Microsoft Dynamics 365 Business Central on-premise and Microsoft Dynamics NAV can be done in the same way. However, developing Microsoft Dynamics 365 Business Central SaaS is different because of the following reasons:

• It's not possible to modify the standard
• It's possible to develop only through extensions
• Microsoft extension code is open. It is possible to see the source code of published extensions (It depends ifshowmycodeis set to true or false).

Therefore, the model of development changes radically.

Note

In this section, we will give you some guidelines for choosing...

Formatting customized code

Your customized code should look like the standard code. Keep in mind that any code you write today will probably be maintained by others in the future. If you follow your own programming conventions, we are pretty sure you'll find it easier to write and read. Unfortunately, others may not be used to your conventions, so you'll be making their lives a lot harder.

All Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central on-premise developers are used to reading code from the standard application. If everyone writes customized code like the standard application does, everybody will only be able to read their own code. To make it easy to maintain an application, it is important to follow a few strict guidelines while writing C/AL or AL code, the standards can be found in the C/AL programming guide and AL programming guide.

Note

The C/AL guide can be found published on MSDN at https://docs.microsoft.com/en-us/dynamics-nav/programming-in-c-al. The AL guide...

Development in Microsoft Dynamics 365 Business Central SaaS

In this section, some differences related to the development for native applications for the cloud compared to the development of applications for on-premises will be listed; what works correctly on on-premise deployments may not work on the cloud as some restrictions existing on the cloud are not present in on-premise.

General considerations

Developing for the cloud is different than developing for on-premise because the architecture is very different: You can't have access to hardware, operating systems, installations, and components.

In the case of development for the Dynamics 365 Business Central SaaS platform, the developer must be aware of some of the following constraints:

• The database cannot be accessed (data, managing, queries, and so on)
• We do not have a local backup of the data (we can only ask for a recovery)
• It is not possible to access server services (only for some functions and telemetry)
• The standard product cannot be...

Source Control Management (SCM)

SCM is necessary to keep projects under control, especially on multi-projects spanning different environments.

A good SCM system should manage the following:

• Versioning and chronological changes
• Comparing and merging
• Restoring to checkpoint

Git and GitHub

If you need to use Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central with SCM integration, Git is the best solution (free, open source and natively integrated with VS Code).

What is Git? Git is a version control system for tracking changes (SCM) in computer files and coordinating work on those files among multiple people. Git is an open source distributed version control engine. VS Code supports Git natively.

Some Git commands are as follows:

• cmd: git remote add origin master <repo url>
• cmd: git push –u origin master
• cmd: git push -u add master

The Git local repository commits to GitHub, pushes the content of the local repository into the branch calledmaster.

The following screenshot shows Git commands...

Publishing your apps on AppSource

Let's now learn how to publish an app on Microsoft Store. Publishing an app is simple: you can do it either as a Microsoft partner or as an individual. Partners can already use the partner account to do this. For individual people, a registration is required as a personal publisher, and a one-time cost for publication is required. The app, after being proposed and evaluated, must be verified for publication, and will be assigned an ID with a dedicated number; once published it will be available for download/installation.

The Microsoft | Store home page looks as shown:

Steps to publishing an app

Two steps are necessary to publish an app on Microsoft Store:

1. Create an account
2. Send your idea of an app

To create an account, you can choose an account type: partner or developer

• Partner account: You need an MPN partner ID
• Developer account: A private account granted to a developer

Note

To be a developer—if you aren't a partner, you can register as a developer here:https:...

Summary

In this chapter, we saw that Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central offer many configuration options and workarounds that we should use before starting to write our own code. If you need to write customized code, it is important to do it following the same structure as the standard application, to avoid confusing the users. The structures of the tables and the pages are the most important ones, and we've seen them in depth.

The posting processes, or posting routines, are the ones in charge of creating historical documents and entries. If you need to modify them, you have to be careful and know what you are doing. That's why we have explained the main idea of posting routines. Last but not least, we saw where and how to write customized code on the Microsoft Dynamics NAV objects.

Almost every Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central implementation will need some kind of changes.

In the old development model, the customized code could...