Code highlighting

Showing posts with label aggregation. Show all posts
Showing posts with label aggregation. Show all posts

Saturday, May 07, 2011

Tutorial: Table Relation properties in AX 2012

As many of you already know, Microsoft has put in a lot of effort into normalizing the tables in AX 2012 and consolidating all the data modeling tools in one place - the table itself. As part of this effort, a number of new properties have been introduced on Tables, and in this post I would like to cover some of them, namely the properties on Table Relations.

The new properties you will find on a Table Relation in AX 2012 are:
  • Cardinality
  • RelatedTableCardinality
  • RelationshipType
  • Role
  • RelatedTableRole
  • UseDefaultRoleNames
  • CreateNavigationPropertyMethods
  • NavigationPropertyMethodNameOverride

Hua Chu from the AX team has written a Guideline document, explaining how these properties should be set for Relations you add to Tables in AX. Note that in AX 2012 most of the above information is not actually used at runtime. This is something that will happen in future releases.
I have modified the document so that it contains the information relevant for partners and customers extending the standard application and have uploaded it to my OneDrive.

The document requires certain knowledge of Entity Relationship Modeling (ERM) and UML notation.

Disclaimer:
This document is intended as a guideline only, and should not be used as a Step-by-Step instruction.
Changes to any of the described functionality might still happen before AX 2012 RTM.


Your feedback and questions are, as always, welcome.

Sunday, February 07, 2010

Performance optimization: Deleting inventory journal lines

Preamble

As a developer, you should always consider performance implications of the code you write. In an ERP application like Microsoft Dynamics AX, the main focus should be on query execution, since it takes up the overwhelming part of the servers' resources.

You should always write queries that would execute the minimum amount of time and use the minimum amount of resources, at the same time producing the expected output in all cases.

Note, that performance is one of those things you cannot really verify on a 1-box install with a small test dataset. Most query problems show up only when tested with many users concurrently loading the AOS on a large-size database.

Code example

Table method
AOT\Data Dictionary\Tables\InventJournalTrans\Methods\delete
contains the following code:

if (this.Voucher)
{
if (this.numOfVoucherLines() == 0)
JournalError::deleteVoucher(tablenum(InventJournalTable),this.JournalId,this.Voucher);
}

The code is logically correct, deleting related records from the JournalError table, which contains error messages generated during validation and posting of journals.
But now let us consider the actual implementation. If we rephrase the conditions under which we delete the error message history, it would sound something like:
If a Voucher number is specified on the line being deleted, and there is no more lines in this journal that use this Voucher number, then we remove the JournalError records.

Deeper code analysis for performance

So, let's go in deeper, and open the code for method numOfVoucherLines:

Integer numOfVoucherLines()
{
return any2int((select count(RecId) from inventJournalTrans
where inventJournalTrans.JournalId == this.JournalId &&
inventJournalTrans.Voucher == this.Voucher).RecId);
}

As you can see, it counts all the journal lines with the specified Voucher number and JournalId.
Does it generate the expected output? Yes.
Is it optimal for the scenario in which it is used? No.

In order to determine if JournalError records can be deleted, we only need to know if at least 1 record with the specified Voucher number exists. So why do we need to search and count all such records? We don't.
Note that this code is being executed for each journal line, magnifying the impact of a non-optimal query N-fold.

Suggested solution

So, if we create a new method like this:

boolean voucherLineExist()
{
return (select firstfast firstonly forceplaceholders recId from inventJournalTrans
index hint VoucherIdx
where inventJournalTrans.journalId == this.journalId &&
inventJournalTrans.voucher == this.voucher).recId != 0;
}

and use it instead of numOfVoucherLines() in delete() method, we will greatly improve the overall performance when deleting journal lines.
It has been measured, that the time it takes to delete a journal with a large number of lines (88000, to be specific) has reduced by 6 times, which is fantastic.

Notes

  • forceplaceholders is used in the query explicitly to make sure a query plan is created and reused for this query, which further improves the performance, since the Voucher number most probably changes from line to line (depends on related journal name setup).
  • It is generally still a best practice to avoid creating inventory journals with such a large number of rows, because the journal is usually processed in 1 database transaction.

See also