Manually Deploying SSRS Reports to NEW Dynamics AX (AX7 Azure Hosted)

Hi there,

Anyone there not liking Automation?  I love it.  However there are times, we need to look back and analyze the manual way of doing things, situation demands at times :).  Deployment is one of them we are going to talk about here!

I'm sure you would have had some experience deploying the application packages, reports, etc., into Local AX7 VM using the PowerShell Cmdlets.  The same approach would still work with Azure Hosted VMs too with little changes.

I was going thru the deployment document where I found the way to redeploy all the reports which also includes your custom reports.  You normally execute this at the end, after the package is successfully deployed,

Here is the PowerShell cmdlet that works with local hosted VM,

1. Type Set-ExecutionPolicy UnRestricted
2. Select 'Y' when prompted and hit 'Enter'
3. Execute this script       command: C:\Packages\Plugins\AxReportVmRoleStartupTask\DeployAllReportsToSSRS.ps1

This works perfectly well with local hosted VM, but not with the Azure Hosted VM.  The problem is, there is no such folder called C:\Packages\ in Azure Hosted VM.

Smartly found the replacement folder for C:\Packages which is J:\AosService\PackagesLocalDirectory (this is case with version 7.0.1265.3015).  And, tried the following:

J:\AosService\PackagesLocalDirectory\Plugins\AxReportVmRoleStartupTask\DeployAllReportsToSSRS.ps1

Did it work?  Well, NO :(.  It was not working either, but throwing the following error:

Get-ItemProperty : Property BinDir does not exist at path 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dynamics\Deployment.

At J:\AosService\PackagesLocalDirectory\Plugins\AxReportVmRoleStartupTask

      \DeployAllReportsToSSRS.ps1:64 char:36
+ ... Location = (Get-ItemProperty -Path Registry:HKEY_LOCAL_MACHINE\...
 + CategoryInfo : InvalidArgument: (BinDir:String)

Looked at the specified path at windows registry, there is no such entry for "BinDir" but does exist in local hosted VM.  Creating a new entry in the registry settings does not seem the good idea for me, so dig little deeper and found that BinDir is one of the optional parameters of the PowerShell Script that can be specified along with the command.  

So, modified the PowerShell script to the below resolved the problem and was able to deploy the reports manually!

J:\AosService\PackagesLocalDirectory\Plugins\AxReportVmRoleStartupTask\DeployAllReportsToSSRS.ps1 -PackageInstallLocation "J:\AosService\PackagesLocalDirectory"

Cheers!

Deploying NEW Dynamics AX's Custom Data Entities from DEV to TEST instance

G'day everyone,

Talking here about an excellent feature of AX7, the Data Entities.

When we build the data entities in DEV environment and wanted to test if it is working, we just setup the respective object as StartUp object in Visual Studio, enable database synchronization upon build and hit Start to initiate the build and do a quick test.  In the Data management workspace, during import or export, you will get to see your custom data entities listed for selection, and the custom data entities would be available in the Data Entities page too.  No additional configuration or setup is required.

Now, you want to build, create package and deploy the same into the TEST environment.  But, after the deployment, you would not get to see your custom entities listed in the data management import/export neither in Data Entities page.  But the underlying schema would get deployed.  You will need to manually configure the Custom Data Entities at the Entities page first before you use your Data Packages for Import/Export.  You can also think of using Data Connector App to do this quickly.

Cheers!

Consuming External DLL from NEW Dynamics AX (AX7)

Hello there,

Whats the big difference between AX 2012 and AX7 on consuming external DLLs.  We do add the DLLs as the references at the Reference folder and copy the DLLs over to a specified folder and just use it.  Yes, it works for both the versions, but the difference comes here on building the external DLLs and the path to copy the DLLs.

If you have used ManagedInterop DLL to consume AX 2012 business logic from within the DLL, then that model would not work with AX7.  See my another blog that explains on consuming AX7 Business logic from outside AX here.  You will need to change the approach that fits AX7.  And, the Project assembly should NOT be signed.  You will likely to get run-time errors if it is signed.  See here for more details.

Also, you will need to choose the .NET Framework Version as 4.5 at the Project properties.  I've tried using the below and above versions, but was not working.

Then comes the folder path to copy the DLLs over for the application to consume.  The DLLs need to be copied over to the following folders:

• C:\Packages\ApplicationSuite\bin
• C:\CustomerServiceUnit\DOBind\Packages\Cloud\AosWebApplication\AosWebApplication.csx\roles\AosWeb\approot\bin

We've upgraded our solution to AX7 and the model is residing under the ApplicationSuite folder and hence, the respective DLLs need to go under ApplicationSuite\Bin folder.  You can also copy over the PDB files over there if you want to debug.  This is the case with AX7 Local VM, cloud hosted ones is the different story.

Note:  This is the case with AX7 RTW (7.0.1265.3015).

Cheers!

Limitations of Consuming External DLL from NEW DYNAMICS AX (AX7)

Often the times that we need to consume external DLL from within AX7 by adding the DLLs as the references in the References node of the Application Explorer.  One of the limitations that I have encountered is that external DLL cannot be consumed if it is a SIGNED one.  We will likely to get some run-time errors.  Remove the assembly sign, build the solution and use the unsigned DLLs.

Note: This is the case with AX7 RTW (7.0.1265.3015) and the previous CTPs.

Consuming NEW Dynamics AX (AX 7) Business Logic from outside AX

Many a times, we come across with this - accessing AX Business logic from a Third-party application.  I assume that to be C# for this blog.  There exists different ways doing this.

1. We can create Public Data Entities inside AX and consume the same thru OData Endpoints.  
2. We can create Services inside AX and consume the same by adding Service References.
3. We can add reference to the AX7 DLL and consume the respective business logic.  

I'm focusing on the #3 in this blog.

In AX 2012, this can be achieved using the DLL Microsoft.Dynamics.AX.ManagedInterop.  But this is not the case with AX7.  As every model that we create leads to assemblies, we need to directly add reference to the respective assemblies.  For example, Microsoft ships AX7 with Fleet Management module.  If we need to get access to a table in Fleet Management module, say "FMRental" from a .NET application, then the following DLLs needs to be referenced in the Visual Studio Project.

• Dynamics.AX.FleetManagement
• Microsoft.Dynamics.AX.Xpp.Support
• Microsoft.Dynamics.AX.Xpp.AxShared

The DLLs Microsoft.Dynamics.AX.Xpp.Support and Microsoft.Dynamics.AX.Xpp.AxShared can be found in the C:\Packages\Bin folder.

Let say, you have upgraded your solution from AX 2012 to AX7 and the upgraded model is residing under the ApplicationSuite folder.  Then, you will need to add reference to the Dynamics.AX.ApplicationSuite DLL.

Here is the simple code example that calls the "CustomerName" method of the FMRental table,

Thanks!