Read the other posts in this series:
Why Create an AX Build Server/Process?
Part 1 - Intro
Part 2 - Build
Part 3 - Flowback
Part 4 - Promotion
Part 5 - Putting it all together
Part 6 - Optimizations
Part 7 - Upgrades

This post is a precursor to another post I’m working on, but the information in it is too unique and involved to just add to that post. Instead, I’m putting this in its own post so it’s easier to reference.

In short, this is to answer one question I have, until recently, been struggling with: Why should an AX development and the deployment process consist of a build server?

Unlike most programming structures, the use of a build server or build process is not as intuitive for AX. However, after attending Summit this year, I’m beginning to understand that while it may not reach it’s full potential when there is a small development team, it becomes incredibly helpful for larger teams. This doesn’t mean you shouldn’t use one in a small team, but with one or two developers it creates more overhead than it would for a large team.

A lot of the considerations revolve around standard development practices, and what the community has established as Best Practices. If you already have a development infrastructure in place (separate development, test, and pre-production environments), this can also be very easy to implement.

Originally, our primary way of transferring code between all environments was done via XPO files. There were some issues with this, mostly streaming from having multiple AOS instances, but we were able to overcome that by scheduling our code updates to work with an AOS restart schedule. Since we are publically traded, this also helped separate those that develop (me) from those who administer the production environment (my boss).

Over the course of time, I began to learn some of the Best Practices used in an AX development environment - multiple environments dedicated to specific functions (Dev, UAT, pre-production), as well as effective code management using the binary .aod files.

However, everything really came together at Summit, when I learned that as Best Practice you should do a full system compilation on the destination system. That is, unless you move ALL the layer files from a system that has already been through a full compile. As long as no further code changes are made, you can use those files through the entire deployment process, meaning (assuming you follow Best Practice) you save time on every step of the process.

Comment and share

So, I’m in Tampa at the 2013 AXUG Summit. Even after just the first day I’ve gotten a lot of good information about how to set up a couple of things I’ve had my eye on with regards to our deployment and even had a few ideas on new posts.

I’ve also met several truly awesome people who have some incredible tales for what to do and what not to do. And the biggest surprise is that I am giving others advice based on my own experience – something that given how long I (haven’t) been doing this for encourages me.

Once I get back I’m sure I’ll be summarizing my experiences and expanding with more details. Meanwhile, talking with others who are in the same situation as I am for certain things gives me ideas on how I can make the AX community a better place. To that end, I have decided that I will eventually publish the security tools I have written (both for an administrator and as an auditor contact). Before I do so I will need to clean them up and make sure everything is in order, including the accompanying X++ code. Since it was originally written just for my own internal purposes, it’s not as good as it could be. I’ll be working on that in my “free time”, and hopefully will have something publishable by the end of the year.

In addition, sitting in a session about code deployment and maintenance has me inspired to implement an automated code deployment system which follows best practices such as deployment of layer files and version control (in this case using MorphX VC). I know where I want to go with this, but I’m not entirely sure how to go about the actual implementation. I will also be working on this in my “free time”, but we’ll see when I finally get a nice polished system in place. In the meantime, I’ll likely post an occasional update when I find something new or interesting.

Comment and share

We have recently seen an issue with the Export to Excel feature of AX 2009, where a stray double quotation mark in the grid will cause all subsequent fields to be offset. Instead of getting nicely formatted rows and columns, we had a few well-formatted rows, and some other rows that weren’t so nicely formatted. This is also shown in one or two other places around there internet (such as http://community.dynamics.com/ax/f/33/t/102643.aspx), but as much as I looked I could not find a solution. We had looked at this problem earlier, as many of our part number include double quotes to represent inches. Previously, we modified the itemName method on the InventTable to replace double quotes with single quotes, as that would not break Excel and was an easy fix. However, we recently discovered that many other user fields were starting to have double quotes in them, and we needed a way to address all of them.

Taking a lead from the MSDN post How does the Export to Excel feature work under the hood, I looked at the SysGridExportToExcel class, specifically the performPushAndFormatting method. I also began to monitor the Windows clipboard, since as that posts explains, the Export to Excel feature relies heavily on the clipboard.

I figured there are three ways I can attack this issue:

• Create an edit method for every field that would hold a double quotation mark, and reference that method instead of directly referencing the field on the form. This would cause the form filter to not work properly, plus the thought of doing this for every field seemed daunting.
• Modify the system so that when the Export to Excel process begins (before the clipboard is populated) all the incoming fields have their double quotes replaced to two single quotes. This is the ideal solution, since there would not be any reprocessing costs like there would be later in the process (after the clipboard has been populated)
• Modify the system so that after the clipboard is populated but before the information is pasted into Excel, all double quotes are replaced to single quotes. Looking at the information that was being sent to the clipboard showed that the information was formatted as Tab separated values, with most test field surrounded by double quotes, which would need to be preserved.

Since the first option would be a last resort, I began to look into the second option: modify the system to change how it generates the information to be sent to the clipboard. However, even searching online I could not find where the system did this. The only clue I had was the stack trace after hitting a breakpoint early in the performPushAndFormatting method, which seems to indicate it was built into the FormRun base class. Because it is a system base class, I cannot modify it (though it would be the appropriate place to do so). My only other option would be to create my own class that inherits from FormRun, override the Task to build in my own functionality, and proceed to update every form in the system to inherit from this new class. However, since I have no idea what is actually happening in this method AND I would have to do it on every form, this also seemed like a dead end.

The last option, to modify the clipboard data after it has already been generated seemed to be my only option. I discovered the TextBuffer class in AX has a handy fromClipboard and toClipboard method, so I would use that.

Within the performPushAndFormatting method, before any of the Excel work begins, I added the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

TextBuffer buffer = new TextBuffer();
System.Text.RegularExpressions.Regex regex;
str cleanedText;
;

if (buffer.fromClipboard())
{
    regex = new System.Text.RegularExpressions.Regex("(?<=[^\\t\\r\\n])\"(?=[^\\t\\r\\n])");

    cleanedText = regex.Replace(buffer.getText(), "\"\"");

    buffer.setText(cleanedText);
    buffer.toClipboard();
}

This replaces all double quotes that are inside the field with two double quotes, which Excel interprets as an escaped double quote. String type fields, when copied from the clipboard, are surrounded by double quotes; the regular expression above excludes those and replaces everything else.

We attempted several ways of accomplishing this goal, from using a series of strReplace commands, to manually parsing the clipboard string character by character, but both of these options were slow when dealing with a large export set.

Comment and share