Sunday, November 14, 2010

Dynamics Ax 6.0 Technical Conference

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.

Wednesday, October 13, 2010

Dynamics Ax 2009 and TFS 2010 (part 2)

I'm happy to report our TFS implementation is taking shape.
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.

Our current setup involves a TFS server, which also hosts the unfortunately named "Team Server" for Ax which manages the object IDs.
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.
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).
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).
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).
Our drop folder now contains labels and layer to be shipped to the client.

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.

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.
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.
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.
Secondly, there is just no way to specify different folders for different users in the Ax source control setup.

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.

Tuesday, August 24, 2010

Dynamics Ax 2009 and Team Foundation Server (TFS)

We have been trying to push clients to use VSS (Visual SourceSafe) as much as we can on new projects, with minor success. For a client not used to development it is hard to convince them of the benefits.
It would be even harder to convince them on using TFS, since it requires even more setup. It is also a known fact that setting up TFS 2005/2008 is not something you want to do for your weekend amusement.

That changes with TFS 2010. The setup is (pretty much) a breeze and in my testing I got TFS up and running in no time at all. I'm not convinced TFS is a good product for your average implementation, but for internal use or bigger projects, it is a pretty cool product.

TFS 2010 may now be easy to setup, but the integration with Ax 2009 has some undocumented features.

Here's some unsolicited advice on things that took me forever to find.

1. Despite what the "Using Ax 2009 with TFS" whitepaper may imply, there actually IS a way to get Ax to put its stuff in a sub-folder of your team project, namely by using workspaces. I found this clue in the whitepaper "Migration from VSS to TFS"... Unfortunately Ax uses the VS2008 client which means it does not support public workspaces (so you'll have to set it up for each user separately).
2. Since Ax 2009 is "not certified" for TFS 2010 yet, it does not hook up to it out of the box. What you'll need to do is install VS2008 with SP1, then install the hotfix from KB974558 (Visual Studio 2008 "forward compatibility") which will allow VS2008 clients to connect to a TFS 2010 back-end.
3. Yes you can get the build to do the "combineXPO" trick. I duplicated the default build template, and in that workflow found the step where it calls msbuild. Delete the msbuild node, and replace with your own scripts. Removing msbuild saves you some serious headaches (errors on missing source files, trying to copy the final executable, etc). Also, the older tricks you will find by searching the web will not work anymore in TFS2010, you can no longer add xml commands into your csproj file, since most of the TFS properties (build number, droplocation, etc) are totally out of scope in 2010. In other news, I decided not to use the combineXPO executable linked to above, but made my own small VBScript (technically all you need to do is avoid duplicating header/footer information that is contained within each of the XPOs).

There is some other (outdated) information on doing cool things with scripts, namely on MSDN, in the Ax4.0 section. I could not find this information in the Ax 2009 SDK at all.

I'm currently looking into hooking up ax unit tests into the build process and getting detailed testing information reported.

Wednesday, July 7, 2010

Ax Security (Part 1)

Security has always been and continues to be a bit of a hassle in current Ax versions. In anticipation of the new role/task based security in Ax6, I will talk a bit on how the current security works.

Upto version 2009, Ax' security is based on security keys. Security keys are a hierarchy of nodes in the security tree, as you can see on the user group permissions screen. Objects in the AOT get assigned security keys in their properties, which makes them show up in the hierarchy on the permissions screen. This is where the confusion begins.

Security "inheritance".

Security keys can have a parent security key, which on its turn may have a parent security key, etc. This is what makes the hierarchy. If a parent security key has a certain permission granted, it will trickle down to every security key underneath it, and down to every object at the lowest level. Of course, at any level the permission level may be overridden, which then changes the permissions for the security keys and objects underneath, etc.

So technically, setting permissions on the highest level key will grant that permission implicitly to everything underneath.

Forms (screens)

Forms are usually a bit of a challenge. First of all, although it appears that way, a form does not have security directly attached to it. The security is set on a menu item (an entry in the menu used to open the form) which in its turn links to a form. Technically, you can have multiple menu items linked to the same form, with different security.

Additionally, the access to the form is not only controlled by the access given to the menu item, but also by the security given to the tables used on the form. If security is set on both, the user will experience the lowest security settings (if full control set to menu item and read-only on table, the user will get read-only… the same read-only result when read-only on menu-item and full control on table).

Another issue with forms is the buttons (which technically are menu items) that appear on the screen. They have separate security, which can be set on the form security in the security tree, or on the menu item itself (if you know where it appears in the tree).

Here's the caveat. If you give access to a menu item button on a screen, the user will get access to that menu item from anywhere else it is available (other screens, on the menu, etc).

It is VERY tempting to click the "cascade" button. I've always strongly recommended people never ever to click that button. First of all, you are giving access to all these menu items available on the forms. You will also cascade your security down to the tables. Which means, if you need full control to a table somewhere else, setting view permissions and cascading it down will result in changing your table's security to view everywhere else in the system!

And of course if will also require you to explicitly remove security, to make some of the menu items "inherit" from their parents. If you set no security and cascade that down, you are removing access rather than removing the security. It is very confusing.

Deny permission

Ax does not have a "deny" permission. When users are in multiple groups, they will get the union (maximum) permissions of all the groups they are in. There's no way to have a group that denies permission which overrides any other permissions coming from other groups.

Security is a big topic and there's lots more to talk about. There are some tools one can build and will talk about that in an upcoming post. Missing tools/reports are for example: where's the security in the security setup tree for object X, who has what access to object Y, etc.

To put the above in technical perspective, we need to know how the security is stored. We can build on that to create some tools. Stay tuned.

Thursday, July 1, 2010

Secrets of SysLastValue

Over the years I have had quite a few customers ask me how to use the user setup and form queries. It's not so much the initial setup that is the issue, but how to distribute changes and setup to other users? And how can we move our changes from our development or test environment to production?

The answers lie in the secrets of the SysLastValue table.

SysLastValue is a kernel-level table that does not show up in the AOT data dictionary. There is however a form called "Usage Data" that can be accessed (check tools / development tools / application objects / usage data). The form itself is called "SysLastValue" (yeah, really) in the AOT. We can use the datasource on the form to right/click and table browse this mysterious table.

SysLastValue stores many different things. The majority of records you will find in there pertain to caching, or "last use" type of data, which will remember the last values you've entered on a dialog, the last printer selection you made for a report, etc. But, which is why we're interested, it will also store any user setup you make on a form, and any and all queries being stored. The field "recordtype" will indicate exactly the type of values stored.
We are interested in type "UserSetup" with the "isKernel" flag set to no, these are the user setups on forms, and the "elementName" field will tell you what form name.
Type "UserSetupQuery" contains the queries saved for a form. You will notice the "designname" contains the form's name, and the "elementname" field contains "f:formname".

So there we are. All the building blocks to build a little tool to distribute user setup and form queries among users, and even migrate between environments, or take backups before clicking "usage data" on the user options.

We have build our own little tool for this and actually taken it a step further. For more information on our IntelliMorph tool called "Personalization Center", check our company website at