Category Archives: Dynamics 365 for Operations

Dynamics 365 for Operations – Determine table/field/datasource name on form and query of data

If you see a field in Dynamics 365 for Operations and need to navigate out to it, you can do the process in Figure 1 below. You right click on the field of interest, hover over ‘Form information’ option, and then click the ‘Form Name: ….’ option.

You’ll see the ‘Form name’ window appear which contains a wealth of information. It shoudl be fairly similar but you will notice a few additions. In Figure 2 below, you’ll see:

  • Control Information
    • Datasource = the name of the datasource (not the table name but generally is. The table name ‘should’ be fairly similar. You’ll want to look for the query statement to confirm)
    • Data field = the name of the datasource field (generally table field name)
  • Form Information
    • Form name = the form that the menu item is tied to
    • Menu item name = the name of the menu item as it is in the AOT
    • Menu item display = the type of the menu item (display/output/action)
  • Query Statement
    • The query for the datasource. This is nice to see on the front end. No need to dig for it in the back end with the QueryBuildDataSource in code.

Hope this helps!

Figure 1 – Navigation to the form information


Figure 2 – The information on the form information

Where is Source code located in Dynamics 365 for operations!

 With Dynamics 365 for Operations (D365Ops), there is so much change from its immediately previous version. And one such major change is done in How the Source code is saved?

If you have every worked in AX2009, you know that the source code is saved in files in a specific file location in the AOS server. Now with D365Ops, Microsoft has fallen back to the concept of storing the files in filesystem instead of a database (model database in AX2012 used to hold all the code base).

And the developers working with D365Ops, the primary question is where & how the source code is kept & handled.

Where to find the Source code:
The application code for Dynamics 365 for operations is stored in File system, usually in a directory named PackageDirectory. You can find the details on the configuration related to AOS in a web.config file.

Steps to follow:

  1. Open IIS and go to the Sites\AOSService (in case you missed, AOS is a web service with D365Ops).
  2. Right click > Explore
  3. You should be directed to a folder (to J:\AosService\WebRoot if you are using MS demo environments)
  4. Now search for the web.config file and open it.
  5. Search for a keyword – “Aos.PackageDirectory” and you should be able to find the value for the Package directory.
  6. It should be J:\AosService\PackagesLocalDirectory (if you are using MS demo environments)

How is the Source code updated in the File system:
Now if we try to look into how the code is stored in the File system. In the above identified PackageDirectory, you will find that there are individual folders to consist the code changes for each Model.

The simplest way to understand the structure is to create your own model and verify the below:

  1. Look for the folder relevant to your newly created model (in my case, APM)
  2. Under path //PackageLocalDirectory/APM/APM– you will observe that there are #78 new folders created for each element type in the AOT. All with a subfolder Delta which is going to store the changes made.
  3. And under path //PackageLocalDirectory/APM/Descriptor – you will find a config file storing the information about your model.
  4. And under path //PackageLocalDirectory/APM/XPPMetadata – the metadata information about the AOT objects is stored.

I will write more about few AOT elements and the extensions introduced with D365Ops and we will look more into the structure and changes in the XMLs placed under Delta folder.



Dimension Controls in a Dialog for Dynamics 365 for Operations


To put it simply, we just need to create our own custom control type, let’s call it “Dimension Entry No Datasource” control.

Firstly, create an extension package so that you are not tempted to overlayer code. Be sure to include the Dimensions model in your package.  Visit the Dynamics ‘AX7’ menu and create a new model:

Name it however you wish:

And select extension package:

Include any other packages you want to reference.  Think of this as an assembly (DLL) referencing other assemblies.

Extensions is the new bag, baby!

Create a new class in your model, and extend the DimensionEntryControl class:

  1. [FormControlAttribute(‘Group’, ”, classStr(DimensionEntryControlBuildNoDS))]
  2. class DimensionEntryControlNoDS extends DimensionEntryControl
  3. {
  4. public DimensionDefault getDimensionRefRecId()
  5. {
  6. return this.parmDimensionValueSetId();
  7. }
  8. }

You’ll notice in the metadata I’ve also drafted a separate extension class for DimensionEntryControlBuildNoDS as well.

In the class example above, you’ll see we have overridden the getDimensionRefRecId() method which is declared as Protected in the parent class.  By setting it to public, we can use it as required in our dialog form.

Build your package from the AX7 menu.

Now it’s time to make use of your training in SysOperation Framework from AX 2012! Create a new controller class which extends SysOperationServiceController, in this example I’ve called it MyController.  Override the templateForm() method and specify a new form:

  1. class MyController extends SysOperationServiceController
  2. {
  3. /// <summary>
  4. /// Swenka internal use only.
  5. /// </summary>
  6. /// <returns>
  7. /// A <c>formName</c> value.
  8. /// </returns>
  9. protected FormName templateForm()
  10. {
  11. return formStr(MyTemplateForm);
  12. }
  13. public static void main(Args _args)
  14. {
  15. MyController c = new MyController();
  16. c.initializeFromArgs(_args);
  17. c.startOperation();
  18. }
  19. }

The new form I’m using above called MyTemplateForm is just a duplicate of the SysOperationTemplateForm.  Expand the design to the DialogStartGrp group which is the main group for any SysOperation dialog.

Add your new custom dimension control here by right-click and new control:

Typically a dimension entry control can infer the type of dimension entry we are requiring based on the Extended Data Type (EDT) of the table field that is associated to the control.  This will either be a Default Dimension such as on master data, or a Ledger Dimension such as on General Journal lines.

In our case however, we have no datasource on the form. So we must specify explicitly the default dimension controller class in the control properties.  Also set the auto declare to True.

From here it is a quick couple lines of code in the init() of the form to tell the control to display values upon loading:

  1. public void init()
  2. {
  3. super();
  4. DimensionEntryControlNoDS.parmDisplayValues(true);
  5. }

And upon closing the dialog we want to capture that default dimension recId and save it to our data contract for use in our service:

  1. // <summary>
  2. /// Command control message called when the form’s OK button is clicked.
  3. /// </summary>
  4. public void closeOk()
  5. {
  6. if (this.controller().checkCloseDialog())
  7. {
  8. super();
  9. var someRecId = DimensionEntryControlNoDS.getDimensionRefRecId();
  10. //now we need to save this in the data contract
  11. //via calling…
  12. DataContract c = this.controller().getDataContractObject(‘_myContractParameterName’);
  13. c.parmDim(someRecId);
  14. //now we can close the form, and execute the job
  15. if(this.controller().skipRunOperation())
  16. {
  17. this.controller().skipRunOperation(false);
  18. }
  19. else
  20. {
  21. this.controller().dialogClosedWithOk(this.dialog());
  22. }
  23. }
  24. }

Using a simple action menu item to invoke the service, we can see the dialog displays our default dimensions for the current legal entity:



All About Dynamics 365

Dynamics 365, D365, Implementor


This blog contains information about Functional techniques and guidelines in Microsoft Dynamics AX, including tips, tricks, tutorials, tools and upcoming news enhancement in Microsoft Dynamics Ax

Philippsen's Blog

Everyday findings in my world of .net and related stuff

Microsoft Dynamics AX

A great site

Finite Minds

Adventures in IoT

Dynamics Ax

Technical Knowledge


A blog about implementing Microsoft Dynamics AX and Dynamics 365 for Operations

Microsoft Dynamics 365 Blog

All Things Dynamics 365, A Blog by sandeep chaudhury

DEVSerra - Dynamics AX development blog

Your official Microsoft Dynamics AX blog.


Discovering Dynamics


A blog by Hai Nguyen

Learn Dynamics Ax with Johnkrish

Live as if you were to die tomorrow. Learn as if you were to live forever - Mahatma Gandhi ****** The more I learn, the less I know - Albert Einstein

Twisted Untwirled

Just another site


Just another site

guyterry's Dynamics AX blog

Just another Dynamics AX blog

Chaitanya kumar

Happy DAXing...!!! :)