Integration between Microsoft Dynamics CRM and Dynamics Ax4 has arrived with the release yesterday of Feature Pack 4 of the Connector for Microsoft Dynamics!
Out-of-the-Box entity mappings provide immediate value by integrating the key data in both systems. That basic integration can be extended by adding new maps, or by leveraging the SDK to create custom integrations.
- An Upgrade Readiness tool will be available. You install this tool on your live AX4/2009 system.
- The tool offers a lot of benefits. First, it enables you to verify that the data in your live system can be upgrade. For example, if an optional column is being converted to an mandatory column, and your current production data has <blank> contents in the field – then the data upgrade is bound to fail.
- In the past you discovered issue like this much later in the process – you could call it trial-n-error.
- This pre-verification allows you to fix your data on your live production system before starting the actual upgrade.
The Upgrade Readiness tool will enable you to enter data that is required to run AX2012.
In the past you would be entering this type data after the actual data upgrade but still during the downtime. Now you can enter the data up-front while the system is live. It is a quite comprehensive amount of data you need to provide, covering global address book, site, financial dimensions, organizational model etc.
The Upgrade Readiness tool allows you to copy live data to a staging area with data transformations in the process, to lower the complexity (and thus execution time) for the upgrade scripts that needs to run during the downtime. This process is of course delta-based, so any updates happening in the live system can be reapplied to the staging area. Control how much of your live system’s resources should be used for this, e.g. you may only want to use 0% during peak hours, 20% during night time, and 40% in the weekends.
. The upgrade process now schedules the actual upgrade scripts based on the distribution of the actual data you have. . At this point you have completed about 80% of the data upgrade process, and now is the time to take the system offline to do the actual data copy/transformation.
The upgrade model contains all the DEL_ tables/fields/indexes, and as you don’t need these anymore – you might as well remove those completely from your system. This way your developer experience on the system gets much improved.
· An Upgrade Readiness tool will be available. You install this tool on your live AX4/2009 system. The tool offers a lot of benefits. First, it enables you to verify that the data in your live system can be upgrade. For example, if an optional column is being converted to an mandatory column, and your current production data has <blank> contents in the field – then the data upgrade is bound to fail.
· In the past you discovered issue like this much later in the process – you could call it trial-n-error. This pre-verification allows you to fix your data on your live production system before starting the actual upgrade. The Upgrade Readiness tool will enable you to enter data that is required to run AX2012. In the past you would be entering this type data after the actual data upgrade but still during the downtime. Now you can enter the data up-front while the system is live. It is a quite comprehensive amount of data you need to provide, covering global address book, site, financial dimensions, organizational model etc.
The Upgrade Readiness tool allows you to copy live data to a staging area with data transformations in the process, to lower the complexity (and thus execution time) for the upgrade scripts that needs to run during the downtime. This process is of course delta-based, so any updates happening in the live system can be reapplied to the staging area. Control how much of your live system’s resources should be used for this, e.g. you may only want to use 0% during peak hours, 20% during night time, and 40% in the weekends.
The upgrade process now schedules the actual upgrade scripts based on the distribution of the actual data you have. . At this point you have completed about 80% of the data upgrade process, and now is the time to take the system offline to do the actual data copy/transformation.
The upgrade model contains all the DEL_ tables/fields/indexes, and as you don’t need these anymore – you might as well remove those completely from your system. This way your developer experience on the system gets much improved.
- Improvements in the X++ language in Dynamics AX 2012:
- New AS and IS keywords – with the same semantics as in C#. In X++ they work for class and table types.
- Support for Attributes – just like in C#.
- Table inheritance.
- Tightening up of various language constructs. X++ no longer allows return type covariance, return type contravariance parameter covariance, parameter contravariance, and visibility contravariance. This fully aligns X++ with C#. To explain this in less language-savvy terms, it means an overriding method must have the same return type and parameters as the method it is overriding. Further; it cannot reduce the visibility, e.g. it cannot make a public method private.
- The dangling semi-colon is not required anymore..
X++ as a managed languages.
The BC.NET component is re-engineered.
In Dynamics AX 2009 it is a face-less client that allows the managed world to call into the AX stack. The X++ code in AX 2009 can call out into the managed world using interop. When you call out into managed code, you cannot call back into the same AX session. I.e. no round-tripping.
In Microsoft Dynamics AX 2012 this is changed. The new BC.NET component is a thin conversion layer that can attach itself (in-process) to the AX client(s), the AOS and regular managed code. It will ensure all marshaling and type conversions happen seamlessly between the two realms.
AN X++ class can pass itself to a C# class, and let the C# class change the state of the object, by invoking a method on the X++ class.
. In Dynamics AX 2012 we are compiling X++ code to the CLR. At compile time we generate an XML representation of the pcode, which we can convert into IL. At run-time we will be execute the IL for batch jobs, service calls and RunAs constructs.
(RunAs is a new method allowing you to request the X++ logic to be executed as IL(Intermediate Language) which is the constituent language of the Cross-Language capabilities of CLR environment (Common Language Runtime Environment) )
The performance characteristics are vastly different particular in situations with extremely many objects or extremely many methods calls.Even in less-extreme situations running X++ as IL is beneficial as for example it reduces the time database locks are held, and thus improves performance and scalability.
