Learn Dynamics 365 Finance and Operations(Axapta)

If you are a senior developer on Dynamics AX, you may wonder how come these issues still exist. This is the reason why I decided to write this article. Developments are now shared among diverse team, sometimes across multiple partners and outsourced to vendors, meaning different skills and processes. Therefore such well known issues still remain in production when customized best practices rules and internal review are not properly defined. The following list is not exhaustive and is only based on our experience from the field. 1. Wrong caching leads to unnecessary database calls This is one of the most fundamental feature of the product today. The three tiers architecture of Dynamics AX allows you to define caching on AOS and client. Not using caching properly is the first root cause for performance. Make sure the following rules are defined: All your customized tables have relevant table group defined in AOT. For example, master data should have “Main” category and transact...

Good Article https://stoneridgesoftware.com/setting-up-version-control-in-dynamics-365-for-operations-with-visual-studio/

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 file system instead of database (model database in AX2012 used to hold all the code base).  For 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 fol...

Extensions aren’t available in Dynamics AX 2012. Dynamics 365 for Operations introduces extensions.  This allows us to add functionality to existing code.  We can create new elements and create extensions of referenced elements in our project.  By creating extension elements, all the customizations and code are stored in a separate assembly, which contains only the code added or changed in the extension. Since this code resides in a separate assembly, it improves the performance of building and testing. This approach is also ideal when it comes to upgrading, as it eliminates metadata conflicts. With extensions, we can extend an object without touching the base object. This means  we can add new fields, methods, or controls to tables, classes, and forms and those additions are contained in our own extension object.  We have not affected the base object. Also, the base objects have many, many events added to them.

Elements  in Dynamics 365 for Operation are the objects that reside in the  AOT  in the  Application Explorer . Elements can be customized once they are added to a specific  project or model A Dynamics 365 for Operation  model  is a group or  collection of elements . A model is a design time concept. A model may contain multiple  Visual Studio projects,  each containing a subset (or all) of  elements  from the originating model. A Dynamics 365 for Operation  package  is a deployment unit may contain  one or more models . In addition to elements, this includes model metadata, which is the descriptive data that defines the properties and behavior of the model.  A package can be exported to a file, which can then be deployed into a staging or production environment. Packages are folders located in the  model   store folder , as can be seen below: Model folders are contained in their pa...

In Dynamics 365 for Operation, you could either use Team Foundation or Git. Each developer needs their own virtual machine (VM).  This was already the recommended approach with Dynamics AX 2012; now, with Dynamics 365 for Operation, it’s mandatory. You will need a TFS/VSO server that has a main repository  (typically the code that matches your Production AX environment). Then you branch off a development branch from the main repository.  Each of your developers will have their own VM and connect to the same branch. All check-ins and check-outs are happening against the dev branch, and, upon check-in, your developers will get the popup window to resolve conflicts.  Once they get used to it, they should be resolve any conflicts on their own by just looking at it; no big overheads here. If development is finished and tested and you are ready to release it to production, all you need to do is hand-pick the change sets that are ready to go and merge them with th...