Delegates concept in D365

Delegates allow us to access elements in higher models form a lower model. With a model split a hierarchy has been created where a higher model can take dependencies and access elements in the models below, but not in models above.

While the model split provides many benefits, it creates a problem when trying to access elements defined in higher models. Delegates are the recommended method for accessing elements in higher models from a lower model. Delegates are very similar to events in that when a delegate instance is invoked, a handler with compatible signature code is executed. This permits higher layer code, the handler, to be called by lower layer code, the delegate instance.

Delegate methods serve as a means for defining a contract between the delegate instance and the delegate handler. A delegate takes no action itself. This is enforced by having a void type and having no code in the method.

A delegate declaration must have three things:

• The delegate keyword
• Type void
• Empty method

For demo purpose, please refer Using Delegates in AX7 / D365 blog post that can describe how we can use delegates using X++.

Display menu item Form View Option in D365

In this blog we will discuss how we can use same form at back-end and show two different views (Listing and Detail) at front end. Working with forms customization almost every developer came across this requirement in which our user wants a listing page and detail page of same nature of records. So for achieving this requirement follow below steps.

Step 1: 
For listing view, create a display menu item set it's object property to your form name and Form View Option property to Grid as shown in image.

Step 2: 
For detail view, create a display menu item set it's object property to your form name and Form View Option property to Details as shown in image.

Step 3: 
Build & Sync your code.

Result: 

List view

Detail view

Framework events in D365

In Microsoft Dynamics 365 tables, form data sources, form controls, and other element types that support extension events list the available events (and delegates) under an Events collection node. Events are exposed on the designer on different element and sub-element types, like table events, form events, form data source events, form control events, and others.

• Events are implemented as multi-cast delegates, which means that more than one event handler can be subscribed to any particular event.
• Events are broadcast there is no sequencing of calls to event handlers.
• Event handlers execute within the transaction scope of the base methods.
• Events are raised as preceding and succeeding operations around the base methods. This means that you have the opportunity to run code before a base method is called and after it has completed.

There are three types of events that you can subscribe to in Microsoft Dynamics 365 for finance and operations.

• Standard events
• Delegates
• Pre/Post Events

Display inventory dimensions dynamically in D365

In this blog I will discuss how you can add inventory dimensions in your custom forms. Please see step by step instructions.

Step: 1
First drag and drop the EDT (InventDimId) and create relation with InventDim.

Step: 2
Add InventDim datasource in form and join (Inner Join) it with datasource which contains your item id.

Step: 3
Create a new group under your gird. Set its datasource property to InventDim and Data group property to InventoryDimesions.

Step: 4
Now write some code as shown in below images.

4.1 Add code in class declaration also on form init method add below highlighted code.

4.2 Add inventory dimension class method in form.

4.3 Add Update design method. Make sure that you use your Datasource Item Id also please read comments on code.

4.4 Override your Item Id Datasource active method and add below code.

Step: 5
Add InventDimParmFixed Display menu item to your action pane menu.

Result:

That is all you need to do.

You can also refer this link: How to: Dynamically display inventory dimension

Understanding data entities in D365

A data entity in D365 is an abstraction from the physical implementation of database tables. For example, in normalized tables, a lot of the data for each customer might be stored in a customer table, and then the rest might be spread across a small set of related tables. In this case, the data entity for the customer concept appears as one de-normalized view, in which each row contains all the data from the customer table and its related tables.

Data Entity Categories

Parameter

Functional or behavioral parameters. Required to set up a deployment or a module for a specific build or customer. Can include data that is specific to an industry or business. The data can also apply to broader set of customers. Tables that contain only one record, where the columns are values for settings. Examples of such tables exist for Account payable (AP), General ledger (GL), client performance options, workflows, and so on.

Reference

Simple reference data, of small quantity, that is required to operate a business process.

Data that is specific to an industry or a business process. Examples include units, dimensions, and tax codes.

Master

Data assets of the business. Generally, these are the “nouns” of the business, which typically fall into categories such as people, places, and concepts. Complex reference data, of large quantity. Examples include customers, vendors, and projects.

Document

Worksheet data that is converted into transactions later. Documents that have complex structures, such a several line items for each header record. Examples include sales orders, purchase orders, open balances, and journals.

Transaction

The operational transaction data of the business. Posted transactions. These are non‑idempotent items such as posted invoiced and balances. Typically, these items are excluded during a full dataset copy. Examples include pending invoices.

Data Entity Use Cases

Synchronous service (OData)

Data entities enable public application programming interfaces (APIs) on entities to be exposed, which enables synchronous services. Synchronous services are used for the following purposes:

• Office integration

• Third-party mobile apps

Asynchronous integration

Data entities also support asynchronous integration through a data management pipeline. This enables asynchronous and high-performing data insertion and extraction scenarios. Here are some examples:

• Interactive file-based import/export

• Recurring integrations (file, queue, and so on)

Job to get WBS ID / Key having activity number in D365

Recently I have been working on Work break down structure in which I want to get the work break down structure Id or Key. So when I back track the code it seems little complex to find WBS hierarchy task id. So for other technical AX developers I have created a job for finding WBS Id while having activity id related to Project that can save their time and efforts.

Code snippet:

Result:

How to resolve memory model provider has been already disposed error in D365

Recently I have faced an error "Memory model provider has been already disposed" while updating the model parameters. This error is usually occurred when build dependencies for the particular model is not updated. 

For resolving this error follow below mention points:

1- Close visual studio.
2- Restart IIS server.
3- Perform full build. (First check if error is still occurred by doing above activity then run full build otherwise not).

Performing builds in D365

The build process is an important process when you are finished creating or editing code and elements in Visual Studio. Let’s take a closer look at the process now.

When we create models and projects that contain customization's of elements or new elements, we need to build them so that they can be used by the application. A full build can be performed on an entire model or multiple models. A build can also be performed on a project, meaning the build system will only build the elements in the current project. When a build command is run on a project, Visual Studio will only build the elements that are new or changed since the last build. You can force a build of all objects in a project, regardless of whether they have changed, by starting a rebuild.

During a build operation, various validations and file generations occur automatically as shown in below image.

There are three options in D365 that can be used for build operations which are as follows:
1- Build project.
2- Rebuild project.
3- Build a model.

Build Project:

When you build a project, only those elements that are new or that have changed are built. During the build process, you might notice that some elements that are built aren’t part of the project. This behavior is required because of the way that assemblies are created for Microsoft Dynamics 365 for Finance and Operations. When you build an element, you’re actually building the .NET module that the element is included in. A single .NET module contains multiple model elements, and a single assembly contains multiple .NET modules. The assembly can be created only if all the .NET modules in the assembly have been built and are up to date. If any elements in any of the .NET modules for an assembly haven’t been built or aren’t up to date, they will be built, even if they aren’t included in the current project.

Rebuild Project:
If you want to build all the elements in a project, regardless of whether they have changed, you must perform a rebuild operation.

Synchronizing the Database at Each Build

A project property lets you specify that the synchronize operation for the database should be performed every time that you build the project. This can be useful when you’re making changes to the table structure for an application. Each time that you build, you will know that the database is synchronized with the tables as they are defined in the project.

If your application has a large number of tables, and you aren’t yet testing the application, you can set the Synchronize database on build property to False. This change will reduce the time that is required to build the project. Then, when you begin testing, you should set this property back to True.

Build a Model:
To build all the elements in a specific module, you must perform a full build on the package that the model belongs to. Follow these steps.

1- On the Dynamics 365 menu, click Build models.

2- In the Models list, select the model or models to build.

3- If you want to build the dependent models first, select Build referenced models. Any dependent models that must be built will be listed.

4- On the Options tab, review the options for the build process. The following options are available:

4.1- Build Pre-Compiled: Generates static HTML for each form during the build process. This allows faster rendering of forms at run time.

4.2- Build Reports: Builds reports.

4.3- Build Aggregate Measurements: Builds aggregate measurements.

4.4- Run Best Practice Checks: Performs best practice checks during the build process.

4.5- Synchronize Database: Updates the structure of the SQL database during the build process so that it matches the models. This behavior can be overridden by the project-level setting.

4.6- Build Cross Reference Data: Updates the data for the cross-reference feature during the build process.