I hope everybody had a great week and that you are ready for a well-deserved long and restful weekend. As you already know, I will be working on a series of articles related to the Microsoft Dynamics AX 2012 POS application. Last week I wrote an article called AX 2012 POS Development - Application Triggers. Please check it out if you haven’t already done so.
In the course of this week I have been gathering a lot of information about the AX 2012 POS application, and the more I work with it, the more sense it makes to me. There are many different layers to this application, but this will be covered in future articles.
Anyway, this week I was working on a new instance of the AX 2012 POS application. To run it from Visual Studio, I followed the steps outlined in my last article AX 2012 POS Development - Application Triggers.
When all the setup steps were completed, I started the solution, keyed my user name and password and all of the sudden I got the following error:
This was odd as I went back to the demo instance I have and after following the same steps, I did not get this error. Luckily, there is LOG table called RETAILLOG in the AX 2012 POS application that can tell you what’s going on, and for my surprise, I was missing the Microsoft.Dynamics.Retail.EventTraceParser.dll as depicted in the following picture (from a working application).
The solution was easy; I just placed the missing dll to my AX 2012 POS application root folder. So, the Event Trace Parser enables rapid analysis of traces to find the longest running code, longest running SQL query, highest call count and other metrics useful in debugging a performance problem.
The Microsoft.Dynamics.Retail.EventTraceParser.dll is installed when installing AX 2012 for Retail and you can find it in your AX 2012 client folder.
That’s it for now folks. I hope you have a wonderful weekend. And stay tune for more to come on AX 2012 POS development. Next week I will post about how to use the AX 2012 POS System.Settings dynamics library and its in-memory functions.
Also, the following week I will write about Blank Operations by going through a really cool simple project. Take Care!
I hope everybody had a really good weekend. I rode my motorcycle to upstate New York and it was awesome.
Anyway, I will be working on a series of post related to the Microsoft Dynamics AX 2012 POS application. There is a lot to learn and therefore to cover, so I made the choice to start by showing a simple example on how the Application Triggers work.
Application Triggers are called before and after certain operations when the Microsoft Dynamics AX 2012 POS application is running. This is the first assembly that AX 2012 POS looks at when starting. In addition, you can override the default Application Triggers’ operations by using the IApplicationTrigger interface provided by the Microsoft.Dynamics.Retail.Pos.Contracts.Triggers namespace in Visual Studio 2010.
It is important to understand AX 2012 Retail POS development lies heavily on using interfaces. Most operations that interact with AX 2012 POS are executed through interfaces. For example, the following picture depicts the use of the ICustomer interface.
NOTE: The dll for this namespace can be found in the AX 2012 POS Fiscal Form. For more information on this, you can download the AX 2012 POS Fiscal Sample from Partner Source.
So, let’s start by setting up the environment in Visual Studio 2010. Please note that to complete this tutorial you will need to have the AX 2012 POS application running in a machine you can work on.
Open the Visual Studio Solution Fiscal Sample and do the following:
1- Right click on the ApplicationTriggers project and choose properties.
2- In the Application tab make sure both the Assembly Name and Default Namespace have the name ApplicatioTriggers. In addition, make sure your Output Type is set to Class Library.
3- In the Build tab chose All Configurations from the Configuration drop down list and click the brose button. Navigate to the AX 2012 POS application and look for a folder called Triggers.
4- In the Debug tab, choose All Configurations from the Configuration drop down list. In addition, navigate to the AX 2012 POS application and look for the POS executable. This is really cool as by doing this, we can accomplish two things. (1) Start the AX 2012 POS application when debugging, and (2) we can debug all the code we want straight from our cozy chair in from of our Visual Studio 2010.
5- All the assemblies need to be signed. The Fiscal Sample comes with an assembly called FiscalSample.snk. I’m using my own, which does not make any difference for the purposes of this tutorial. In fact, for this tutorial, you can create your own.
6- In the Signing tab, check the Sign the assembly and choose New. A new window will appear and just give it any name you want. This will create an assembly file in your Visual Studio solution. You can then copy it and paste it to other projects.
7- We need to add a few references. So right click in references and choose the one depicted in the figure in step 8
8- Import the following references.
9- Add the references depicted above to your .cs file as seen in the following picture. Also, the following picture shows the IApplicationTriggers interface being implemented by our class. This is actually very important as without it, nothing will happen and you will not be able to run your AX 2012 POS application. Make sure your code looks as the one below.
10- Build the solution. By doing this, you are overriding the default ApplicationTriggers.dll dynamics library with the code in step 9. Make sure you don’t have any build errors.
11- Run the solution and you should see the following two messages.
The messages above are executed from the following two methods:
a- Public void ApplicationStart() b- Public void LoginWindowVisible()
12- Before the login windows appears you should see the following message.
The message above are executed from the public void PreLogon() method.
13- Enter the user name and password and you should see the following message.
The message above are executed from the public void PreLogon() method.
14- Click the Log Off button and you should see the following message.
The message above are executed from the public void LogOff() method.
As I mentioned at the beginning of this post, there is a lot to learn. I also think that the Microsoft team did an excellent job simplifying the POS development from the AX 2009 POS version. Unfortunately, there is not a lot of information available for AX 2012 POS development in Partner Source and/or TechnNet, and it is my hope the Microsoft can start releasing some of it soon. Until then, let's wok together on discovering the new stuff in AX 2012 POS.
That’s all for now folks.
Stay tune for my next post on Blank Operations for AX 2012 POS development. In addition, I will also cover the POS architecture and other really cool stuff around it.
I found a video of Bill Gates introducing Microsoft Dynamics AX 4.0 and the integration with the Linc Group. It is amazing to see that his vision is now a complete reality with AX 2012 and AX 2012 for Retail.
