Microsoft Dynamics® AX 2012
Developing Microsoft Dynamics AX business logic with managed code
This paper describes the possibilities afforded to the developer of business logic in Microsoft Dynamics AX 2012 in terms of leveraging managed code.
Table of Contents
Using X++ 3
Using managed languages 3
Using managed APIs from X++ 3
Writing business logic in managed code 3
Using X++ as managed code 5
Glossary of terms 5
The Microsoft Dynamics® AX environment features a rich palette of options for the business application developer. The system is model-based and much can be achieved by describing the expected functionality by editing metadata in the Application Object Tree (AOT). However, there will always be a need to perform computation to provide the required functionality. This requirement can be satisfied in two ways: by using the X++ language and by using managed languages.
The Microsoft Dynamics AX Integrated Development Environment (IDE) features a rich environment that was specifically designed to provide a Rapid Application Development (RAD) environment for writing business applications. A pivotal part of this environment is the X++ language that was created specifically to implement large scale ERP systems where efficient data manipulation is of paramount importance. The X++ language is hosted within the MorphX IDE that contains everything needed for successful development work: debugger, code profiler, tracing tools, and so on.
Using managed languages
In addition to the features provided by the X++ stack as just described, it is possible to author business logic in either C# or Microsoft® Visual Basic® (VB).NET. As most C# and VB.NET developers would expect, this development takes place in Microsoft Visual Studio® 2010, Microsoft’s premier multipurpose extensible IDE. The Microsoft Dynamics AX tools are integrated with this environment, allowing you to use all the features within that framework.
Using managed APIs from X++
The X++ language embraces managed objects as first class citizens. In other words, you can create and use objects of managed types from within X++ code quite seamlessly. Syntactically, .NET types are distinguished from X++ types by using the full name of the managed type, including the namespaces. The lifetime of the objects is managed by the .NET garbage collector. You can use managed APIs from assemblies that are added to the references node in the AOT, or you can author the code in a managed project that is hosted within the AOT: In the latter case the C# or VB source code and the project definition is available for editing directly from within the Microsoft Dynamics AX IDE.
The following X++ code shows how a managed API can be used from X++:
public client static boolean copyFile(str fileName, str newFileName, boolean overwrite = false)
System.IO.File::Copy(fileName, newFileName, overwrite);
Using managed code from X++ as described above is certainly useful, but it is not the complete story. It does not provide a compelling story for building interesting business logic in managed code: For that you need a system that can seamlessly crisscross the boundaries between X++ and managed code. Such a system is provided with Microsoft Dynamics AX and its integration with Visual Studio 2010. It is built with proxies and the Business Connector. To use this functionality, you must have installed the Microsoft Dynamics AX Visual Studio tools.
Managed developers are entitled to an editing experience where the X++ artifacts they interact with appear as just another set of full fidelity managed objects, with the convenience of documentation comments and full type safety. This richness is provided by using managed proxies to access the X++ code artifacts (classes, tables, and enumerations): The Microsoft Dynamics AX proxy concept is similar to the proxy concept that Visual Studio provides for consuming web services: The consumer does not see all the complex plumbing that takes place under the covers to make the interoperability happen, either with the X++ objects or with the service implementation. The X++ proxies are more dynamic than service proxies: Visual Studio will build the proxies anew every time a build takes place, so that “stale” proxies never become an issue.
Proxies are used by selecting the artifacts that are required from the Application Explorer in Visual Studio, and then simply dragging them to the solution that contains the managed application code. This will build the managed proxies for the dragged artifact (and the artifacts that they depend on) behind the scenes, so the proxies are ready to consume from the managed code. The illustration below shows a Visual Studio solution using a few proxies.
If the solution is added to the AOT, then you will be able to deploy the assembly to the tier (that is, either the client or the server) where it is executed. If the assembly is used on the client, the client may have to be closed and restarted to use the new assembly.
Figure Visual Studio project showing a few proxies
When the client or server calls into the managed code, the context of the call is set up. This context includes the user identity, the transactions running, and so on. This means that the managed code will always run in exactly the same context as seen by the X++ code, creating parity between the runtime environments.
As described previously, the proxies are managed representations of their X++ counterparts. Both representations actually refer to the same instance: When the state of the object is changed on either runtime environment, the change is reflected in the other runtime environment. This concept is sometimes referred to as “object idempotency.”
Using X++ as managed code
In this scenario, the X++ code is compiled into managed code, and is therefore executed by the .NET runtime system instead of the X++ runtime environment. This is currently done for code running batch jobs and services on the Application Object Server (AOS), where the heavy lifting warrants executing in managed code, where non-deterministic garbage collection is in effect.
Glossary of terms
AOT (Application Explorer)
The application object tree where the model describing the application can be viewed and modified.
Pronounced “C sharp,” an object-oriented managed programming language, used primarily by professional programmers.
A managed object-oriented programming language that can be viewed as an evolution of the classic Visual Basic language (VB) which is implemented on the .NET framework.
Visual Studio 2010
An integrated development environment (IDE) from Microsoft. It can be used to develop applications in both native code and managed code. Also, Microsoft ships tools that integrate with Microsoft Dynamics AX.
Part No. 0000-0000 (mm/yy)
Microsoft Dynamics is a line of integrated, adaptable business management solutions that enables you and your people to make business decisions with greater confidence. Microsoft Dynamics works like and with familiar Microsoft software, automating and streamlining financial, customer relationship and supply chain processes in a way that helps you drive business success.
U.S. and Canada Toll Free 1-888-477-7989
This document is provided “as-is.” Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. You may modify this document for your internal, reference purposes.
© 2011 Microsoft Corporation. All rights reserved.
Microsoft, Microsoft Dynamics, the Microsoft Dynamics logo, Visual Basic, and Visual Studio are trademarks of the Microsoft group of companies.
All other trademarks are property of their respective owners.