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.

2 Comments

  1. Martin,

    What are your thoughts about merely “SELECTING” data from the database using t-sql stored procedures, views, etc. What if the client has legacy systems that can’t consume web services; what if the only option is to provide a t-sql view that the legacy apps can utilize? Also, thinking of Data Warehouse and ETL, what about extracting all the data in AX as-is and then making it available via reports for analytics, etc. In full disclosure, this is what I’m personally involved with at the moment, so I’m curious of your thoughts. Generally speaking I agree completely with the principles you laid out; but feel like there are exceptions to the rule and also if you go in with your eyes open, you can hopefully avoid any pitfalls. I also like the idea of having a loosely coupled “staging database” that uses views/procs to access AX data; but yet it’s a standalone database that isn’t impacted when AX gets upgraded, goes down, etc. I like having a system not entirely dependent on the AX system. I’ll readily acknowledge the risk of bypassing AOT, AX classes/bus logic.

    Kris

Leave a Reply

Your email address will not be published.