Why not to touch AX DB directly

I’ve been asked to reiterate some arguments against direct access to AX business data. (As you all know, the recommended approach is always going through AOS, such us calling web services.)

Here are some of the arguments:

  • You would bypass all business logic. It often means that you would have to re-implement some AX logic (and risking getting out of sync with later changes in AX), or you could miss some important logic completely.
  • You would have to deal with many AX concepts normally handled by AX kernel – partitions, virtual companies, table inheritance, date-effective data and so on.
  • Lots of AX metadata is in AX application, most importantly table relations.
  • You would bypass all AX security.
  • If you wanted to write data into AX database, you would have to deal with record IDs and potentially other system fields.
  • You would bypass data caching and AOS servers could ignore your changes, because nothing told them to invalidate their cache.
  • The exact schema in database is considered an implementation detail (because nobody should touch it) and can change without warning (for example, remember the change in implementation of table inheritance between AX 2012 R1 and R2).
  • It’s not a supported use of Dynamics AX and therefore Microsoft wouldn’t help you if you got into troubles with your database.
  • And so on…

My advice is: if you decide to read data directly from database (likely because of performance reasons), you see you have many things to think about. Be careful, especially regarding security.

If you want to write into AX database, just don’t it. Use AIF, put the data into another database and let AX read them or something. Changing the AX database is simply too risky.

List AOS services with colors

Here I have a little Powershell script, written mainly for demonstration purposes, nevertheless it does its job and may be useful to somebody.

It connects to any number of servers, finds Dynamics AX AOS services there and shows them in green or red, depending on whether they’re running or not.

$listOfComputers = 'Server1','Server2'
 
$listOfComputers `
    | % {gsv aos* -comp $_ `
        | % {Write-Host $_.DisplayName -f @('Green', 'Red')[$_.Status -ne 'Running']}}

Output:

AOS service colors

Hail Powershell!

VSO process customization

As you all know, you can either install Team Foundation Server (TFS) on promise, or use the cloud-hosted service called Visual Studio Online (VSO). They both offer very similar, but not exactly identical capabilities. Some features of TFS are not supported by VSO; on the other hand, VSO gets new features more rapidly than TFS and it also have a few unique abilities.

One major advantage or TFS over VSO is the ability to modify process templates – adding new fields, hiding unused ones, creating work item types, modifying states and workflows and so on. VSO came with some features to mitigate this limitation (such as you can use tags as a replacement of custom fields), but many teams really need customized process templates.

But that’s going to change. I’m sure it’s taken major engineering effort, but finally Visual Studio Online is going to offer many of the process customizations you may hunger for: new fields, new work item types, you name it. It also comes with some features, such as inheritance of process templates (customized templates will inherit changes in the original template).

If you want more details, the following blog post may be the best starting point: MSDN ALM blog: Visual Studio Online Process Customization – Update.

I think it’s a really major step for adoption of VSO. There are still less and less things that you can do in TFS and not in VSO.