Whenever Possible, USE APIs!

I surprised myself last week in writing a customer interface for AX 2009 in only a few hours.  Why is this surprising?  When AX 2009 first came out, most AX consultants (myself included) were a bit distressed by the Global Address Book (GAB) framework and the complexities it added to the customer and vendor import process.  Instead of importing data into one table, you have to hit 4 or 5 tables, some of which are just serving as a junction (N:N) table.  In case you're wondering, yes, it is even more complicated in AX 2012 with the introduction of table inheritance.

The reason I bring this up is to bring home a very important point:  whenever possible, USE APIs!  The only reason I was able to build an interface so quickly is because a simple static method call removed all of the complexity of the GAB framework.  As outlined in the Dynamics AX 2009 Global Address Book whitepaper (there's an equally simple approach for 2012), I used the following line of code to build all GAB data for me and assign a new Party ID to each customer:

custTable.PartyId = DirParty::createPartyFromCommon(custTable).PartyId;

APIs are your friends, and they exist to make your life a lot easier.  When you don't use APIs you are effectively:

• Wasting brain power trying to understand a black box that doesn't necessarily need to be understood
• Making more work for yourself both in building the solution and supporting it over its useful life
• Creating more potential for error in terms of bugs and data consistency
• Wasting client resources and/or project budget

So prior to diving in and building a solution, see if you can leverage existing APIs to address the problem you're trying to solve.  This principle applies not only to AX, but also to any mature language or enterprise software system.