Thursday, June 30, 2011

AX 2012 Documentation Round-up (June 2011)

With the launch date of AX 2012 coming closer and closer, your organization should be preparing for this major release. There are lots of resources being made available almost on a daily basis. It's hard to keep up with documentation being released every day, but here's the list I have so far. Feel free to leave any additional links you may know of in the comments.

Major Sources for AX 2012 documentation:
Microsoft's Download Center (search for "AX 2012")
MSDN AX 2012 Beta Page
PartnerSource US Launch Page (requires MBS Partner access)
PartnerSource Global Launch Page (requires MBS Partner access)
PartnerSource Getting Ready for Microsoft Dynamics AX 2012
This "Getting Ready" page on PartnerSource is extremely valuable. It contains the "What's New" training material (including functional), it contains the Convergence Hands-on labs, the Technical Conference 2011 session videos, etc!



The list below contains all the publicly available documentation (all outside of PartnerSource).

Documentation:
Upgrade Guide
Installation Guide
Deploying Customizations Across Environments
AX 2012 System Requirements
New, Changed and Deprecated Features in AX 2012
What's new in AX 2012 for Developers
AX 2012 Implementation Planning Guide
Selecting the Best Development Technology for your Development Scenario (White Paper)
Updating the Uses of the Ledger Posting Framework (White Paper)
Services (White Paper)
Lean Manufacturing - Production Flows and Activities (White Paper)
Microsoft Project Server 2010 Integration (White Paper)
How to Write Data Upgrade Scripts for AX 2012
Code Upgrade (Multiple White Papers)

This contains the following White Papers:
Code_Upgrade_Overview_AX2012.pdf
Developing_with_Table_Inheritance.pdf
Eventing_AX2012.pdf
Implementing_and_extending_the_organization_model_in_Microsoft_Dynamics_AX_2012.pdf
Implementing_and_Updating_the_Human_Resources_Framework_AX2012.pdf
Implementing_Budgeting_for_Microsoft_Dynamics_AX_2012_Applications_AX 2012.pdf
Implementing_InventTrans_refactoring_for_Microsoft_Dynamics_AX_Applications_AX2012.pdf
Implementing_Item-Product_data_management_framework_for_Microsoft_Dynamics_AX_2012_Applications_AX2012.pdf
Implementing_the_Account_and_Financial_Dimensions_Framework_AX2012.pdf
Implementing_the_Address_Book_Framework_for_Microsoft_Dynamics_AX_Applications_AX2012.pdf
Implementing_the_Budget_Control_Framework_for_Microsoft_Dynamics_AX_2012_Applications_AX_2012.pdf
Implementing_the_Operations_Resource_Model_AX2012.pdf
Mapping_the_LedgerTrans_table_to_General_Journal_tables_AX2012.pdf
Migrating_EDT_Relations_in_Microsoft_Dynamics_AX2012.pdf
Shared_Currencies_and_Exchange_Rates_AX2012.pdf
Using_the_Enhanced_Number_Sequence_Framework_in_Microsoft_Dynamics_AX_2012.pdf
Using_the_Policy_Framework_in_Microsoft_Dynamics_AX_2012.pdf
Using_the_refactored_Formletter_framework_AX2012.pdf

Upgrade Script Reference
Reference: Tables and Table Groups
Developing Extensible Data Security Policies (White Paper)
Implementing the Tax Framework (White Paper)

Wednesday, June 29, 2011

AX & TFS FAQ

This is my first post containing an FAQ on the AX and TFS integration. I get a lot of the same questions, and below are the most commonly asked ones. This is a lengthy post so I apologize to the RSS subscribers.

Feel free to leave your questions in the comments, and I will keep this FAQ updated.



AX & TFS FAQ

Q: How to move one X++ project at a time, and what if it contains objects that have been modified for other X++ project as well?
A: This is where TFS' intelligent branching/merging process comes into play. The prerequisite is that you check in code for one X++ project at a time. That way, TFS knows which changes are "bundled" together. Obviously you can multiple changes over multiple days, but it is imperative that you never check in changes you made for different projects.
When you merge a change set to another branch, which contains objects also modified by other projects that you are not moving, TFS will raise a flag. It will allow you to make a decision (on the XPO text) whether you wish to move the whole thing anyway, whether you want to move just the change associated with the change set you're moving, or whether you wish to manually modify the change to make it work. This works well for code in general but I always manually check to make sure anyway.


Q: How to build one project or one object or one changeset?
A: Although I understand the question in certain situations, I feel like there is never a good enough reason not to build the whole thing (except time perhaps). In any case, this basically boils down to creating a custom build workflow. When building just one object or one changeset, I'm fairly certain that can be done with the workflow. To build just one project, that is more tricky since TFS is not "aware" of projects, for what it's concerned, all it has is a text file (xpo) dubbed the "project definition". That being said, consider what we're doing with builds today: we are taking all XPOs and combining them into one giant XPO to import. What can be done of course it instead of combining all XPOs, first read a project definition, then combine only the objects described in that. Then follow the normal process for the build.


Q: How can we build a patch/hotfix layer?
A: This relates to the previous question. If you have a project containing the objects touched for your patch, you can use the combine-xpo approach I described above. If you want to build certain changesets only, either build a custom workflow, or consider perhaps a different branch, which can then be completely built in a patch layer…


Q: How can we have multiple developers work on the same AOS using TFS?
A: Due to the way the standard AX integration is designed, this is not possible. Of course in reality, this is a VERY common scenario, and Microsoft has asked a lot of questions and asked for lots of feedback from me and other in the community to try and solve this issue in AX2012. The solution unfortunately, has not worked it's way into the product. Instead, we will get more access to the integration code with TFS (the .NET "proxy" assembly is now a visual studio project in the AOT) so we can make any changes we need to ourselves.

A: That being said, in our AX2009 environments we do have multiple developers on one AOS. This is done through some customizations to AX, and some NTFS (windows filesystem) tricks. Bottom line:
- We modify the AX integration to append the AX username to the local repository folder, this satisfies TFS that all users are using a different repository "working folder"
- We add NTFS "junctions" so that although each user has its own folder, they are physically all the same folder (think sym links in unix/linux). This satisfies some issues with AX (namely if you have outdated XPOs there's a danger of updating the AOT with old code when you undo a chance for example).


Q: Can AX2009 support branching in the source tree? IE can I point AX 2009 to use a SUB-folder in my source tree rather than the root?
A: Standard AX 2009 will always put all the files starting at the root. Please note that this has been fixed in AX 2012 and you can specify a branch folder there.

A: For AX 2009, we have branching working at our offices at Streamline Systems. The only thing you really need to do is, after AX sets up your workspace, is changing that workspace (using visual studio) so that the working folder on the server points to your sub-folder. Of course, it only takes one user to not do this properly to mess up your source tree. To that end, we have automated this "fix" on the workspace by adding some .NET code in AX that gets executed when you log into AX, and changes your server working folder.


Q: In ISV scenarios, how can we maintain multiple components, and create unique builds for clients containing a unique combination of our components?
A: To be honest, I do not have a good answer to this. For big components, it makes sense to develop them in separate AX environments. For small ones, that sounds like overkill. In any case you can hook them up to the same ID server to avoid object ID collisions.

A: As far as branching is concerned, this would require a branch for each unique combination where you merge in the components you need. That is technically not unrealistic, but may be too much work for your scenario. Especially if you then need to branch for each release off of that…

A: I believe the AX developer community needs to start thinking more in lines of general software development practices, which in the past has never been the case. There are issues due to features and architectural challenges that are unique to AX, but most of the time those can be overcome. In this case, think of each component as a DLL or software product you would sell to a client. The uniqueness in AX is that they will all go in the same layer. But honestly, that's an installation detail, and it should not prevent you from considering each component as a unique product in your development cycle.

A: With the coming of AX 2012, the introduction of models, AxModel deployments and installations, I believe it will become easier to do these sorts of things.


Q: In client scenarios, clients may be doing their own development in a higher layer, how does that work?
A: When clients do development of their own, it should go in a higher layer than your delivered solution. This makes sense from a maintenance/support and liability point of view. We usually deliver our builds in a VAR layer and recommend customers use the CUS layer for their customizations.

A: In situations where you do off-site development and move layers into client environments (are current setup at Streamline Systems), it is true clients may be over-layering your objects so that any changes you make are not reflected in the final code layer "combination". To that end, you have a build log from TFS that can tell you what objects have been modified since the last release, and you have a layer compare in AX to detect layer conflicts. This sounds like a lot of work, but it isn't really. The point of source control is that you know exactly what has changed, so unless you have a ton of changes every release, the layer merge effort should be minimal.

A: In situations where there is development in multiple layers at the same time (such as traditional client projects where all development is done on-site), there are unique challenges. Even though for example fields on a table can be in different layers (ie not the whole table is in a layer at the time, like reports or forms in AX 2009), from a source control point of view the whole objects is moved into the higher layer. This prevents you from making ANY changes to the object in a lower layer as soon as it's over-layered. I have had numerous discussions with Microsoft on this subject, but there is no good way of resolving this.


Q: Why do we want to move layers and not XPOs as we've always done?
A: My favorite topic. Moving XPOs is literally moving source code (the XPO is a plain text file containing the source code). There are several issues with that approach:
1) the person importing the XPO can make mistakes (merge issues, object IDs, "delete tables and class members", etc). An XPO also implies someone took an export somewhere, which is the same issue, mistakes could have been made in the exporting.
2) from an auditing perspective this "should" be unacceptable: whomever imports this into production can modify the code, which is a segregation of duties issue, and a liability since after import the code cannot be guaranteed to be exactly the same as the test environment (export/import could introduce changes, merge issues, etc)

A: Usual complaints are one needs to take down the AOS to move in a new layer. My response to that is taking down the AOS, moving in the layer and starting it up again is a matter of minutes. Proper procedure when moving XPOs would be that all users are out of the system anyway, and that you do a full compile afterwards to make sure there are no issues. The difference is minimal, and not an excuse to keep doing XPO exports.

A: Moving compiled, binary code is the approach anyone should take. You do not receive hotfixes for Windows from Microsoft in source code form, you receive binary updates (new DLLs, EXEs, etc). This is also where Microsoft is going in AX 2012. There are models, and model exports (.AxModel). XPOs in AX 2012 are not the recommended way of moving code.

A: By moving code in layers, they can be versioned easily as "releases", which makes it easy to keep track of what version of the code is deployed where. XPO moves (unless extremely strictly controlled) have the potential of having different versions of different objects. Layers are the only guaranteed way of having two environments use the same code.

Tuesday, June 28, 2011

Unit Tests - Revisited

As I have posted on this blog previously, we at Streamline Systems have done some minor testing and created a small framework to be able to run unit tests during our TFS builds. The reason I have not put this up on the CodePlex AX build project yet is that the solution is not entirely elegant... it requires a C# unit test project be created, and a wrapper method for each test method in AX.
However, after talking with Dave Froslie at Microsoft and some investigation (my Visual Studio skills are still a work-in-progress), there exists such a thing as a "generic" unit test in Visual Studio. Basically, this is a one-time unit test project, which wraps a command line process and takes an output file from that (.trx file).
I've not created an actual test on this, but the .trx file is basically an XML file, so the only thing required would be an XSL transformation. And as far as that goes, one could extend the standard AX unit test XML output class and transform the output before writing to file.

Since we'll be working on converting our build processes to AX2012 soon, I'm expecting us to implement this for AX2012 (which I think last beta build I looked at, it was still the same code for XML output of unit tests).

Thursday, June 16, 2011

AX2012 .NET Proxies for Kernel Objects

For those who've played around with Visual Studio and AX2012, the proxies are a great way to most of your logic on the .NET side, without too much hassle. One thing is apparent after a while though: how do we create proxies for kernel classes and tables? For some classes, there is a Sys* version (eg SysQueryRun, SysDictTable, etc), but first of all, you don't get the static methods of the original kernel class, and as for queries, there is no Sys* equivalent of QueryBuildRange and so on.

So how do we get the proxy? Turns out, this is all handled by the .axproxy file extension. Just create a new file (mind the case! remember .NET is case-sensitive!) in the format ObjectType.ObjectName.axproxy. For example, to get QueryRun, create a file:

Class.QueryRun.axproxy


The standard Visual Studio AX tools just put a plain text message in this file:

This is a Microsoft Dynamics AX proxy file that generates classes for the element that it represents in the project to which it is added.


With the file created, you can drag and drop the .axproxy file onto your Visual Studio project, and the build will generate the proxy for you. (again, watch the case... for example the class QueryBuildDataSource has a capital S in datasource!)

Obviously this is not the recommended way to create proxies, but I have yet to hear a more official way to do this from Microsoft. As for built-in X++ functions in AX, the official word is there is no way to get those, except creating a wrapper class in X++ and generating a proxy for that.