Dynamics 365 for Operation 中已更改的开发 / Development changed in Dynamics 365 for Operation

icrosoft Dynamics 365 Operations and Microsoft Dynamics AX 2012 R2-R3 aren’t very different in terms of functionality. However, the implementation approach is very different.

Today, I will show you how we need to prepare and what we need to know for development in Dynamics 365 for Operations.

1. What is integrated development environment (IDE)?

From my development experience perspective, Dynamics 365 for Operation is not a modern technology, but it will employ current technologies in a better way.

• The development environment is one-box deployment with its own local SQL database installed.
• There is no longer a rich AX client and there is no MorphX development environment to get into. We will use Visual Studio instead of MorphX.
• X++ is compiled to P-Code in Dynamics AX 2012, but in Dynamics 365 for Operation, the X++ compiler generates CIL for all features. CIL is faster and can run on a large tool base of .NET utilities.
• Application code is stored at different places and in different formats in Dynamics 365 for Operation.

• You also can import projects, export projects, or compare elements in Dynamics 365 for Operation.

• You need MorphX along with AOS in Dynamics AX 2012 for development, but in Dynamics 365 for Operation, you work with Metadata API (XML files) in Visual Studio so technically there is no need for AOS (as a service now) to be running during design and compilation.
• Executing X++ code, displaying a form or running a report is integrated with Visual Studio debug experience. This execution is through the AOS Web Application that is running in the local IIS.

2. How to control source version in Development?

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 the main branch. At that point, a code gatekeeper should go through the objects one by one to proof-read and double-check their work.

Once the branch merge is complete, you could trigger off the build from the main branch, and deploy that code/package to production.

3. What are Projects, Models, and Packages?

In Dynamics AX 2012, these terms will be Project XPO, AXModel, and AXModelStore. You can find more information about it here. In this topic, I will describe more Dynamics 365 for Operation.

This illustration show how they relate to one another:

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 package folder. Each model folder contains type-specific folders:

A package folder contains a descriptor folder that lists all models that belong to the package. A model descriptor file contains metadata about a model’s properties.

4. What are extensions?

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.

5. What is different about integration?

• Database connectionI have been supporting a lot of clients by using connection directly to AX 2012 Database for their integration. This was never supported and was a totally bad practice for integration. But, in Dynamics 365 for Operation, it’s completely impossible.

• There is no more Application Integration Framework (AIF) or Business connector (BC) in Dynamics 365 for Operation.Microsoft introduced a replacement to the AIF, the primary vehicle for integration since 2006. This new data access framework enables external access to AX data and business objects via the standard OData (open data) protocol using RESTful web services. This is a vast improvement over the proprietary AIF service.The AIF only supported SOAP-based web services that were brittle and cumbersome to manage. Microsoft has stated that the AIF would not scale in a cloud-based scenario and spent several years developing this new framework delivered in Dynamics 365 for Operation. I want to mention that a quite popular method is File System Adapter, but it is not supported in real time.
• Instruction of Data EntitiesThe last very large change in Dynamics 365 is the introduction of data entities. Data entities serve as the new framework for integrating with AX.The integration framework in Dynamics 365 for Operation is split into DIXF (data import/export framework) and OData. The schema definitions serving are both referred to as Data Entities.With data entities, all data coming into and going out of AX follow the same path, so you do not have to build two different things if you are calling an API or using DIXF to manipulate data. The data entities are very easy to create. There is a wizard that walks you through the creation process, like the wizard in Dynamics AX 2012 that is used to generate document services.Another notable change within integrations is that the services exposing data entities are restful state APIs using JSON-formatted data. In Dynamics AX 2012, all services were WCF services. This change means the way you call services is significantly different so, if you are planning to do integrations on Dynamics 365 for Operation, you will want to study how to call the APIs.

转载请注明：ww12345678 的部落格 | AX Helper » Dynamics 365 for Operation 中已更改的开发 / Development changed in Dynamics 365 for Operation