Changes in Reporting tools and Enterprise Portal in AX 2012

Hi there!

Well, I would assume that we are all excited about the new changes around the Reporting and Enterprise Portal tools in Microsoft Dynamics AX 2012, right?

Well, we should be, as Microsoft Dynamics AX 2012 has truly eliminated the need of having to install two different pieces of software to support reporting and EP development.  Currently, in AX 2009 the Reporting and EP tools are required components that we “have” to install in order to integrate AX 2009 and Visual Studio 2008.

 In AX 2012, however, standard Microsoft Visual Studio 2012 tolls can be used to achieve this Reporting and EP Development.  

In AX 2012 most of the basic development and some customization tasks (like creating new pages or adding Web parts to existing pages are all performed directly in SharePoint) related to the Enterprise Portal can be performed using SharePoint Foundation 2010 or SharePoint Server 2010. In addition, AX 2012 allows us to focus on the development of content Web parts in the Enterprise Portal by only using the Enterprise Portal framework and Visual Studio.  In fact, the most sophisticated functionality of Enterprise Portal is created by using Visual Studio.

Personally, I believe, the fact that EP proxies were taken out of the equation is a great step, as this created endless issues when updating EP proxies between AX 2009 and Visual Studio 2008. In fact, it was a suitable nightmare!

Reporting is not that bad in AX 2009, but the fact that we needed to install a piece of software to make it work really bothered me. Instead, AX 2012 provides a model-based approach to develop any type of report. It also provides templates and modeling tools that are part of Visual Studio.  Further, the reporting features provided by AX 2012 are really well integrated with SQL Server Reporting Services, which includes a set of tools for us to define reports in the Visual Studio.

I believe in simplicity, and the less we need to worry about installing several pieces of software to only make “one thing” work, the better.

Take care!

Configuring and running the AX 2012 Hyper-V image with VirtualBox

Hi!

A while ago I started setting up the AX 2012 virtual box in my laptop. It took me a few days to download and have everything ready to start setting the machine up. However, when I finally found the time to install it, I got a few errors on virtual PC . As a result I was unable to boot the machine successfully due to a file corruption error.

The following is a link that helped me out in fixing a few issues.

http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/a0565fd0-f978-4dbc-955b-45e0818440d8/


A few days later I found a video (below) that explained on how to install AX 2012 Hyper-V using the Oracle VM. After following the video (really easy to understand) I was able to successfully run AX 2012 VM on my computer.

NOTE: You will need access to partner source to download the AX 2012 VM files.

Check it out

Take care!

Debug X++ code in a Batch Server in AX 2009

Hi there!

Today I would like to discuss how to debug X++ code in a batch server. One of the common scenarios in AX development is the debugging of X++ code in the client.

For example, if you want to debug the SalesFormLetter class after posting either a Packing Slip or an Invoice, you just would go to the AOT > Classes>SalesFormLetter look for the method you want to debug and add a breakpoint. Simple!

In AX 2009, however, we have the ability to run Batch jobs directly on the server (unlike prior versions (i.e. 3.5)). The problem is that to accomplish this, we have to configure a few things.

The following are the steps to accomplish debugging X++ code in a batch server. The example is going to be using the SalesFormLetter class run method.

NOTE: Please use a Development or Test environment to try these steps.

1- Open the Client Configuration Utility and Click the Manage button. Choose Create New Configuration.

2- Give it a name. (I have chose Debug2713)

3- Set the server name, instance name and port (the default for the first instance of AX will be 2712. If you have more than one instance make sure you have the right port. In my case the AX second instance is 2713)

4- Go to the developer tab and check the both "Enable user breakpoints to debug in the business connector" and "Enable global breakpoints to debug code running in the business connector or client" check boxes.

5- Now open the Server Configuration File and Click the Manage button. Choose Create New Configuration. Give it a name (i.e. Debug)



6- Set the application file location and the alternate bin directory and the Application instance. In addition, check both the "Enable breakpoints to debug X++ code running on this server" and "Enable global breakpoints to debug X++ code running in batch jobs" check boxes.

7- Click the Database Connection tab and set both the server name and database name.

8- Open the AR module and go to Periodic > Clean Up > Sales update history clean up

9- Choose the Executed Clean Up option and a date and click OK.

10- Open the AOT, go to Classes and look for the SalesFormLetter class. Open the class and look for the Run method and place a breakpoint anywhere in the code.

12- Open the AX 2009 debugger

12 - Go to AR > Common Forms and open the Sales Order Details form. Choose an Open Order and click the Post button. Choose Packing Slip (i.e.)

13 - The SalesEditForm will open. Click the Batch button and set the batch.

14- After clicking the OK button you should see the following message

If you want to check the status of your batch you can go to Basic > Inquiries >Batch Job. Your scheduled job should be in there. Wait a few minutes and the debugger should open at the breakpoint you inserted before.

NOTE: Sometimes you will have to restart the AOS service when the debugger does not open and your job has already executed. In addition, you MUST have a batch group setup.

Take Care!

Application Object Server (AOS) architecture

The Application Object Server (AOS) provides the infrastructure to execute the business logic of the Microsoft Dynamics AX application. The AOS handles the required connectivity, security, and database connection management. You can install the AOS on a single computer or on multiple computers and group these computers in a load-balanced cluster.

In Microsoft Dynamics AX 2009,you can create a single cluster or multiple clusters of AOS servers.

Microsoft Dynamics AX requires Windows-integrated authentication for all servers in the system, which means that you must be running Active Directory. For security reasons, the AOS must be installed on a Windows server operating system.

A system used for demonstrations, development, or testing can be set up to use more than one AOS instance. For details about developer installations of Microsoft Dynamics AX 2009, see the Installation Guide.
In Microsoft Dynamics AX, the AOS is implemented as a Microsoft Windows

Service to take advantage of the following features:

• Windows service applications run in the security context of a specific user account that is different from any logged-on user or the default computer account. The AOS service uses a system account for authentication during start up. This account is used by the AOS to access the file server and database server.
• A Windows service application runs in its own Windows session and takes advantage of the service control manager (SCM, a feature of the Windows Server 2003 operating system or higher) to maintain status information and to provide the user interface for managing the AOS.
• Windows services can be configured to start at system startup or upon demand, and they continue to run even when no user is logged into the system.
• Server status can be reported to the Windows event log, allowing administrators to view errors and warnings that can aid in troubleshooting problems.

The following diagram provides a view of the architecture of the AOS.