Application Extensibility

Application extensibility has always been a strong feature from the initial origins of Microsoft Dynamics 365 for Finance and Supply Chain Management. What was Axapta that later became Dynamics AX. It had a clever layer system to isolate modifications between development parties. When editing a standard object, such as a class, the element being changed (such as a method) would be copied to the developer's current layer where it was modified. The compiler would look down from the top layer (from the USR, VAR, and ISV through to the base SYS layer) to build the solution. This made upgrades much simpler and carried a lower risk than its peers. When coupled with a very advanced development environment, the cost of implementation and maintenance was a major selling point of the system.

Despite all of this advanced technology, some customers still found...

Technical requirement

You can find the code files for this chapter at the following GitHub links:

• https://github.com/PacktPublishing/Extending-Microsoft-Dynamics-365-Finance-and-Supply-Chain-Management-Cookbook-Second-Edition/blob/master/Chapter%205%20-%20ConVMSReports.axpp
• https://github.com/PacktPublishing/Extending-Microsoft-Dynamics-365-Finance-and-Supply-Chain-Management-Cookbook-Second-Edition/blob/master/Chapter%205%20-%20ConVehicleManagement.axpp

Adding fields to a standard table

Adding fields to standard tables is the most common change we do, and in this recipe we will add a field to the SalesConfirmHeaderTmp table, which we will use in the How to customize a document layout without an over-layer recipe. The requirement for this is to add the order sales pool to the report.

Getting ready

In order to do this, we need a solution. Since we are writing a new requirement—a change to a report—we will create a new project within our ConVehicleManagement package. Separating requirements into separate projects allows software development to be planned more easily. It results in easier code maintenance as there is less trawling through a mammoth project to find...

Writing data-event handlers

Data-event handlers deal with delegates exposed on every table. These delegates are listed under the Events node.

These events do not fire if the associated method (for example, insert) is overridden on the table and super() is not called.

How event handler methods are organized is up to the developer, but they do need to be placed logically so that others will find them easily. A good naming convention (from experience) is to use the following convention: TableName_Project_DataHandler, so in our case it would be SalesConfirmHeaderTmp_ConVMSSalesReports_DataHandler.

It would be tempting to name it ConVMSSalesReportsDataHandlers, and stick them all in one class, but when we eventually have many projects with data-events, it can get hard to see what events are firing. Having one class for all table events means that it becomes a library class, and our...

Using a Chain of Command to initialize data

A Chain of Command can be used as an alternative method to copy the value from our new field to the report's data table. This is a preference for reports as it will usually avoid looking up the source table in the data-event. Sometimes data is inserted using a set-based operation, and could mean the event is never fired.

A Chain of Command is done by creating a final class that references the class it augments, using a class attribute. These classes do not extend the class; they augment it. This is explained further in the How this works section of this recipe.

Getting ready

We will continue with our reporting project, ConVMSSalesReports, in this recipe.

...

How to customize a document layout without an over-layer

The example here adds an extension field to a print-managed standard document without over-layering the report. We will use the sales order confirmation report to add the sales order pool name to the report.

There are two main types of reports: listing reports and documents. The documents, such as the sales order confirmation document, use temporary tables to make the layout easier to write. Any report can use this technique, but it is more common on document layouts and complicated listing reports.

We've already discussed the older method of keeping reports: a separate package. This is not ideal in SCM as the only benefit is the ability to deploy separately to the main package. Due to the fact that packages reference in one direction, we can't use fields written for a reporting package in the main package. This...

Modifying a standard form

Adjusting the layout of a form, as an extension, has been made very easy for us. This is covered in the first part of the recipe. We will also cover a new technique to work with form code.

Getting ready

Re-open the main development project, ConVehicleManagement, for this. Before we start using the Adding fields to a standard table recipe to add a field to the SalesTable table for the ConVMSVehicleServiceId EDT, also add a relationship to ConVMSVehicleServiceTable. Create a field group also called ConVMSServiceGroup with a label for Service details.

How to do it...

...

Using Chain of Command with a form

The forms in SCM can contain a lot of code that we may wish to augment to suit a specific requirement. We have added a service ID field to the sales order, so it may seem a fair requirement to default the service ID if it were called from a service order.

When a form is opened, an args object is passed. If we add the SalesTable menu item to our service order form, and set the dataset to the service order, the args object will be constructed with a reference to this record. We can use this to filter a list of sales orders or use it in the form to set defaults on a new sales order record.

How to do it...

First, we will add the sales order menu item to our service order, and then use the Chain...

Replacing a standard lookup with our own

Sometimes we will need to add a field to a lookup or change the way it filters the list shown to the user. In this example, we will change the item lookup on the sales order line data source so that it only lists items that are on a related service order. This recipe will show you how to write a lookup, add a filter and an exists join, and prevent the standard lookup from being displayed.

We will be writing this lookup against a lookup event for the ItemId field on the SalesLine data source, on the SalesTable form.

How to do it...

To create a new lookup handler event, follow these steps:

1. Since this handles the lookup event on the SalesTable form, create a class named SalesTable_ConVehicleManagement_FormHandler...

Adding a form display method to a standard form

We can add display methods to tables and forms using extension classes. The table route is preferred, as tables are reusable. We sometimes need to add display methods to a form because some information is only available when the form is built, such as data on the form's data sources.

This is a limitation in that the display methods on forms cannot be added to the data source object, and they don't currently accept a record as a parameter. For this reason, they can only use the current record of a data source and cannot, therefore, be used as on-grid controls—they would show the same values on all rows.

In our case, we will write a display method to show information from a service order, in order to state that new orders will be attached to the service order. Of course, if this is intended as a warning, it needs...