All Blog Posts - page 15

May 5, 2011 - AX 2012 & .NET - Coding Business Logic in C#

Filed under: #daxmusings #bizapps

AX 2012 has pushed the boundary of .NET interop, and - as Microsoft touts - makes managed code a “first-class citizen” in the application. This is true - with some limitations on the eventing side in my personal opinion - but there are some caveats, which can easily be overcome if you understand the underlying workings of the proxies.

Consider the following example, in C#:

Query query = new Query(); query.addDatasource(Global.tableName2Id("CustTable")); QueryRun queryRun = new QueryRun(query); while(queryRun.next()) { /* .... */ }

At first glance, this would work. And it compiles as well. However, a runtime error occurs complaining that object of type “Query” does not have a method called “Next”.

So what’s happening? Well, remember the classes in managed code are proxies. So, they can be instantiated by giving them a reference to an existing X++ object. When you pass in your query object to the constructor of QueryRun, it will try to wrap the managed QueryRun proxy around the X++ object reference, which is the Query.

As you can see in the IntelliSense, the other overload of the constructor is to pass in an object of type “object”. Not much documentation there, but that is in fact the X++ New() parameter profile we would like to invoke. So, we change our C# code to:

query = new Query(); query.addDataSource(Global.tableName2Id("CustTable")); queryRun = new QueryRun(query as object); while (queryRun.next()) { /* .... */ }

Now, this will work as expected.

Apr 27, 2011 - AX 2012 Events

Filed under: #daxmusings #bizapps

With the introduction of events in AX2012, a slew of possibilities has opened up. At the technical conference in January 2011, Peter Villadsen first unveiled the power of the new functionality. In conjunction with that, I had prepared a lab exercise which was available at the conference. I am working on preparing a new lab document, which I will post here on my blog, which is largely based on the original tech conference document, but with more detail and showing every possibility (the tech conference lab was limited to 1 hour of work, so some features were not explicitly shown).

Before I start posting these labs here, I would like to point out a few VERY important things that I feel the AX developer community should be aware of.

1) The pre/post handlers are a powerful concept, but one needs to be aware of its limitations. The power lies mostly in the ability to add behavior without modifying, and the power to apply/install multiple solutions together without the need to merge (think AxModels, or even traditional XPOs). However:

when subscribing a handler, the subscription has a “name” property, which should ALWAYS be changed to a meaningful yet unique name. Failure to do so immediately eliminates the power of installing models without merging, since now you have two subscriptions titled “EventHandler1” and one will overwrite the other.
when changing return values in a post-handler, be aware you may not be the last handler to do so. When changing the value of a validateField(), only change it to FALSE if you have a reason to do so, otherwise, leave the return value alone. In other less obvious cases, be aware of the limitations and potential other code impacting the return value.
same goes for pre-handlers and changing arguments to the original method!

2) Managed handlers are powerful, but have their limitations. I will go into this in my lab posts, but there are limitations in what you can and cannot do, and what you should and should not do. Remember any data manipulation you do from managed code will have to cross the boundary again and could impact your code’s performance.

3) When creating delegates, look at best practices for C# delegates. Arguments should be the sender object, and a class, Extending XppEventArgs base class, containing all the variables you wish to pass. This will ensure that the API your delegate provides will never get broken. If you ever wish to add more data, you would add it to the class, without breaking any delegate subscriptions depending on your delegate method’s signature.

As far as delegates and events go, please review C# best practices for naming conventions (eg “InvoicePosting”, “InvoicePosted” as delegates, and the subscribers should be “InvoicePostingEventHandler” and “InvoicePostedEventHandler”).

Apr 14, 2011 - New, Changed and Deprecated Features for Microsoft Dynamics AX 2012

Filed under: #daxmusings #bizapps

Microsoft has a released a comprehensive 207-page document entitled “New, Changed and Deprecated Features for Dynamics AX 2012”.

You can download XPS and PDF versions on the Microsoft Download Center.

Apr 12, 2011 - Dynamics AX 2012 Public Beta

Filed under: #daxmusings #bizapps

The opening keynote by Steve Ballmer at Convergence 2011 marked the public availability of the beta of AX 2012.

Check out Dynamics AX on MSDN, which now has an AX 2012 beta page.

You will need CustomerSource or PartnerSource access to download the betas. Remember the virtual image is Hyper-V, for which you will need a Hyper-V server, OR you can also try the unofficial non-supported way and try to run it using OracleBox.

Mar 16, 2011 - Unit test & TFS/VS updates

Filed under: #daxmusings #bizapps

First of all, Visual Studio 2010 SP1 was released. On top of that, Visual Studio Power Tools and Team Foundation Power Tools were also updated, you can now get the March 2011 update.

Secondly, I want to give an update on the TFS integration. I have gotten a lot of positive feedback on the TFS build scripts release. No word on anyone actually using or testing it, but I’m hopeful there will be feedback soon. I’m still encouraging people to please contribute their own scripts, no matter how minor you think they may be. Please contact me and I will add you as a developer on the CodePlex project so you can upload your own work. Meanwhile, I have slightly changed our scripts here to try something new. I figured there may be an easy way to incorporate the standard AX unit tests into the TFS build scripts. Basically, I added a line to the build script that executes an AX test suite from the client command line. This produces an XML file (Unit.xml) in the client configuration log folder, with the results of the unit tests. Next, a C# test project which, instead of performing tests in each test method, basically returns the result of a test method, as read from the XML file AX produced. Very simple to implement, worked like a charm without having to change anything in the TFS workflow (well, I did have to add msbuild back in just like the standard template). Expect that code on CodePlex soon. I will be talking to Microsoft probably this week, since they had another approach to this unit test framework which they wanted to discuss with me. More news on that soon I guess.

Mar 11, 2011 - AX TFS Build Script - fully released

Filed under: #daxmusings #bizapps

I have added four more scripts to the CodePlex project on http://dynamicsaxbuild.codeplex.com/ .

CleanAOS.ps1 - this script “cleans” the AOS before a build. Move old layers to the old folder, remove indexes (object, label) etc.
ExtractXMLCompileMessages.ps1 - this script extracts specific type of messages from the AX compile log XML and outputs them to the standard output
BuildScript.ps1 - this is the main script we use in our TFS build, which uses an AXC file to find all the paths, AOS info etc and runs all the scripts for the build.

I have tried to outline the build flow and some comments per script on the documentation tab on the CodePlex project. Feel free to contact me with questions.

Next problem I will tackle and publish code for is the source control integration problem within AX (one-aos/multi-developer, TFS workspace, etc).

Feb 18, 2011 - AX TFS Builds - CodePlex Project

Filed under: #daxmusings #bizapps

During and after the Dynamics AX Technical Conference, I have spoken and emailed with a lot of people suffering from integration issues with TFS and AX 2009. After demoing our TFS setup to the Microsoft team, we are advising Microsoft on things to be fixed on the TFS integration in AX2012. Of course, they are also tied to how much new functionality they can introduce at this stage in the game, but we’re hopeful something will come out of it. At the technical conference, Microsoft demoed work item integration inside of AX during check-in. However, the big debate and issues are around the one-aos-multi-developer scenario. I’m not expecting all of those issues to be fixed, but they are talking about a workaround for us to overcome the integration issues. No final decisions yet.

In the meantime, I’ve been asked by several parties (including Microsoft) to release the scripts and code fixes we are using here internally at Streamline Systems, or at least document our changes and process. To that end, I have set up a CodePlex project called “Dynamics AX Build Scripts” where I will gradually release our scripts. I’m currently in the process of migration our CMD and VBS mess to Powershell versions, so as I get things converted and tested, I will put those scripts on CodePlex.

There are three scripts so far:

AxCompileHTML2XML.ps1 - this scripts converts the html compile log to xml (basically strips out the few html elements) so it can be queried
CompineXPOs.ps1 - this combines all the source tree XPOs into one big XPO that can be imported easily through command line
CopyLabels.ps1 - this script accepts and FROM and TO path, and copies label files only if they actually contain any label data

All these are pieces to our overall big build script, which I will soon release as well.

I would like to use the CodePlex project as a place for the community to share their ideas and solutions for doing proper ALM with Dynamics AX. To that end, I would like to encourage people who have set up their own scripts to share those as well!

Contact me using the “contact me” button on the right menu, if you have stuff to contribute, and I will get you setup as a contributor on the project.

Dynamics AX Build Scripts

Jan 11, 2011 - Dynamics Ax 6.0 Technical Conference (2)

Filed under: #daxmusings #bizapps

Preparations are in the final stages for next week’s Technical Conference. As a first of its kind you will not be disappointed. The new version of AX has so many new things to offer, you will be blown away! The only thing you will regret at the end of the conference, is that the product isn’t actually released yet!

Lab times and days are not announced yet, but I will be sure to post details on the instructor-led lab I will be holding at the conference. Expect some great new X++ features, .NET integration and debugging options to be a part of it!

Still awaiting the official ok, but I’m hoping to release all details with documentation and code on my blog.

Nov 14, 2010 - Dynamics Ax 6.0 Technical Conference

Filed under: #daxmusings #bizapps

If you haven’t heard yet, you absolutely need to click the banner above. I you have heard, but haven’t registered, time is running out! Currently we have registrations out of 44 countries, and the event is going strong to be sold out.

There will be lots of session on all of the numerous, exciting technical changes in 6.0. Trust me, you will not be disappointed, and there is plenty to learn (and re-learn) for anyone working with Ax, whether you’re a developer, consultant, or user.

I will be presenting one of the hands-on labs on X++, stay tuned for more information. And keep an eye on the site, session content is gradually being published.

http://www.microsoft.com/dynamics/DynamicsAXTechnicalConference2011

Oct 13, 2010 - Dynamics Ax 2009 and TFS 2010 (part 2)

Filed under: #daxmusings #bizapps

I’m happy to report our TFS implementation is taking shape.<div>We our now actively using TFS for two implementations, and planning to add more projects soon, including clients we are supporting that are live already.</div><div> </div><div>Our current setup involves a TFS server, which also hosts the unfortunately named “Team Server” for Ax which manages the object IDs.</div><div>We have a Hyper-V hosted virtual server 2008 for each client project, where only developers have access. This virtual server hosts the Ax development environment hooked into TFS.</div><div>When development is ready to be tested by our consultants, one of the developers is responsible for merging the code into the TEST branch. This is done based on changesets, the policy is the changeset check-in comments need to clearly identify the development task number. Based on the changeset comments’ task numbers, the developer (we’ve dubbed him the “branch manager”) merges changesets into the TEST branch (at which point the TFS development work items are associated… a great tool for reporting what went into a new release!). TFS detects any code conflicts, which can fairly easily be resolved using the TFS compare tool (on the XPOs).</div><div>When all is merged, we have a TFS build that will be queued, which automatically refreshes our AOS server (combines all XPOs into one, shuts down the AOS, moves the layers into “old”, copies the most recent label files from the source control tree into the application directory, deletes label and layer indexes, starts the AOS, imports the code + compile, runs a synchronize). The whole build process takes about 30-40 minutes. When all is done, it actually stops the AOS again, copies the layers out and TFS puts those in the drop folder together with the label files (and starts the AOS again).</div><div>When things are properly tested and ready for client/user testing, we merge those changesets into the RELEASE branch, which will then also again build a release AOS, more for the purpose of getting a layer file built (and for one client test the final product before shipping to client, to make sure there’s no branch/merge issues).</div><div>Our drop folder now contains labels and layer to be shipped to the client.</div><div> </div><div>Important to note our script to combine XPOs will add a macro in the XPO that contains the build number from TFS. This is necessary to easily identify the build number a client has running on their different environments.</div><div> </div><div>That said (and noting we’re pretty excited about our new process which has been great so far), several obstacles had to be overcome to get here.</div><div>Besides my explanation in the previous post about using TFS 2010, there are SEVERE limitations to the setup. On a given machine, only one user can use a particular local repository folder or TFS complains (as I understand it, it’s more a Ax limitation of using TFS options such as public workspaces) about the workspace already being in use.</div><div>A workaround would be to use a separate folder for each user. Well, there’s two Ax issues with that. First, Ax expects to find the XPO for a source controlled object in your local repository. So if someone added an object in the Ax AOT, you will see it in the AOT, but your local repository will probably not have the XPO. Annoying Ax-AOT errors ensue.</div><div>Secondly, there is just no way to specify different folders for different users in the Ax source control setup.</div><div> </div><div>The solution we came up with consists of (1) a customization to the Ax - TFS integration to support different folders for different users, and (2) make those user folders NTFS junctions to the same folder, so all XPOs will always exist.</div>

Previous Page: 15 of 16 Next

Code Crib