I am contemplating placing AOSes on SSD drives due to the following considerations: Dynamics AX 2009 AOS puts cache that is greater than 128k per table to a hard disk. If it is an awesomely fast SSD, then the cache update is insanely fast.
The things to consider would be is the speed of update of other AOSes, since for some types of cache, AOS must update the other AOSes too.
So the consideration needs additional planning.
Also, an enterprise-grade or an SLC drive should be considered due to high reliability.
Monday, March 12, 2012
Tuesday, March 6, 2012
Report performance of Dynamics AX
Today i've got a task to take a look at a long-running report. I came across the following useful checklist:
Include a try catch around all transactions that could result in deadlock.
Make sure the try for a deadlock is idempotent meaning no matter how many times the try is attempted, it will yield the same result.
Consider the clarity when deciding the number of return statements in a method.
Use throw instead of ttsAbort.
Avoid display methods where possible.
Set Optimistic Concurrency Control (OccEnabled) to Yes for most tables.
Do not include user interaction inside a database transaction.
Keep database transactions as short as possible.
Run code on the Application Object Server (AOS) whenever possible.
Use where clauses in select statements and in queries that align with indexes.
If method calls are used to test conditions, put the method calls after the other conditions. If the other conditions fail, then you will not incur the cost of running the method.
Minimize the size of database transactions.
Consider specifying a field list in select statements to increase performance.
Use firstonly where applicable to increase performance.
Use aggregates in the selection criteria instead of having the code do the aggregation. If aggregations are issued in the select statement rather than in code, the processing is done at the database server which is much more efficient.
Use table joins instead of nested while loops. Whenever possible use a join in the select statement rather than using a while loop and then an inner while loop on the related table. This reduces the amount of communication between the AOS and the database.
Do not include any sort of user interaction in a transaction.
Include a try catch around all transactions that could result in deadlock.
Make sure the try for a deadlock is idempotent meaning no matter how many times the try is attempted, it will yield the same result.
Consider the clarity when deciding the number of return statements in a method.
Use throw instead of ttsAbort.
Avoid display methods where possible.
Set Optimistic Concurrency Control (OccEnabled) to Yes for most tables.
Do not include user interaction inside a database transaction.
Keep database transactions as short as possible.
Run code on the Application Object Server (AOS) whenever possible.
Use where clauses in select statements and in queries that align with indexes.
If method calls are used to test conditions, put the method calls after the other conditions. If the other conditions fail, then you will not incur the cost of running the method.
Minimize the size of database transactions.
Consider specifying a field list in select statements to increase performance.
Use firstonly where applicable to increase performance.
Use aggregates in the selection criteria instead of having the code do the aggregation. If aggregations are issued in the select statement rather than in code, the processing is done at the database server which is much more efficient.
Use table joins instead of nested while loops. Whenever possible use a join in the select statement rather than using a while loop and then an inner while loop on the related table. This reduces the amount of communication between the AOS and the database.
Do not include any sort of user interaction in a transaction.
Monday, March 5, 2012
Dynamics AX: it is recommended that you cancel the recalculation
This error is caused by a situation, where either:
- Inventory closing was performed later than this recalc
- The recalculation date equals the inventory closing date and the time of the recalculation start is LESS than closing inventory start.
So what could have happened is that the inventory recalc was was launched with date to update up to a date earlier than the last inventory close. Inventory recalc gave an error, saying that it does not make sense to make this recalc, since that inventory has already been closed. Cancel the last recalc, or change the date to run up to.
Friday, February 10, 2012
On the importance of EventInbox cleanup
Today I have been investigating a myriad of requests to the table, since it looks like SQL being bombarded with queries to EventInbox table.
This table stores actual alerts. In existing implementations nobody bothers to clean up the old alerts. Moreover, the deleted alerts physically stay in the table and are merely marked as "deleted".
The table has caching setup and will hit troubles as soon as it is bigger than AX's 2009 cache of 2000 records. Every time the user starts a client and the homepage is displayed, the client fires at least 18 SQL queries (tested on a cold cache) that do multiple selects to display the list of alerts in the Work List web part. In case there are more then 10 alerts, it also builds the list of "pages" for navigation between the alerts.
The SQL queries traverse through all existing alert records for the user for the company. So if the job has not been launched, there will be gradual decrease in performance stipulated by the volume of the data and the fact that the cache of 2000 records will have to be refreshed approximately every 100-150 alerts, which also is possible within the same loop.
So to help your users see the appreciable boost in load times, try to keep the EventInbox under 2000 records. To do this run Administration > Periodic > Notifications cleanup with the parameters, suggested by Czesława.
This table stores actual alerts. In existing implementations nobody bothers to clean up the old alerts. Moreover, the deleted alerts physically stay in the table and are merely marked as "deleted".
The table has caching setup and will hit troubles as soon as it is bigger than AX's 2009 cache of 2000 records. Every time the user starts a client and the homepage is displayed, the client fires at least 18 SQL queries (tested on a cold cache) that do multiple selects to display the list of alerts in the Work List web part. In case there are more then 10 alerts, it also builds the list of "pages" for navigation between the alerts.
The SQL queries traverse through all existing alert records for the user for the company. So if the job has not been launched, there will be gradual decrease in performance stipulated by the volume of the data and the fact that the cache of 2000 records will have to be refreshed approximately every 100-150 alerts, which also is possible within the same loop.
So to help your users see the appreciable boost in load times, try to keep the EventInbox under 2000 records. To do this run Administration > Periodic > Notifications cleanup with the parameters, suggested by Czesława.
Monday, February 6, 2012
how to create the balcesheet in the axapta 2009
First of all, one needs to understand the building blocks of Financial statement report builder:
a. Dimension focus - list of what on type of entity you want to report, e.g. accounts, dimensions, departments...
b. Row definition - lists of entities you want to report on, e.g. list of Balance accounts
c. Date intervals definitions - are helpful rules that define what "current quarter" means to AX
d. Financial statement - The combination of the above.
So, the steps to build the simplest balance sheet in Dynamics AX would be:
1. Create a dimension focus for GL accounts:
a) Go to GL > Setup > Financial Statement > Dimension focuses
b) Create a new record and on Dimension tab add Ledger account to the Dimension focus. Save.
2. Go to GL > Setup > Financial Statement > Row definition
a) Create a new Row definition. Set field Focus to the Dimension focus you've created in step 1.
b) Click button Structure designer
c) Double-click on the ledger accounts you want to see in the report. You can also use drag and drop
3. Close the structure designer. Go to: GL > Setup > Financial Statement > Financial Statement
4. Create a new financial statement record (CTRL+N).
5. Set field Main focus = [The dimension focus you've created in step 1]
6.In the lower grid, in the Overview tab, Create the following lines for the GL account and its amount.
7. On the Setup Tab in the upper part of the form, select Row definition for main focus you've created in step 2.
8. Now lets run the report: GL > Reports > Transactions > Periodic > Financial statement
9. Select the financial statement that you've defined in step 4.
10. Click OK.
Here is how your simple balance sheet would look like:
Financial statement report builder is a flexible tool. You can further define periods, compare them one to another, make breakdowns per financial dimensions and many more exiting things.
Of course you may try to implement Management Reporter or FRx, BI 360 or AtlasXL, however this is a free and standard tool, which is robust for most application, given the proper setup.
a. Dimension focus - list of what on type of entity you want to report, e.g. accounts, dimensions, departments...
b. Row definition - lists of entities you want to report on, e.g. list of Balance accounts
c. Date intervals definitions - are helpful rules that define what "current quarter" means to AX
d. Financial statement - The combination of the above.
So, the steps to build the simplest balance sheet in Dynamics AX would be:
1. Create a dimension focus for GL accounts:
a) Go to GL > Setup > Financial Statement > Dimension focuses
b) Create a new record and on Dimension tab add Ledger account to the Dimension focus. Save.
 |
| Dimension focus in Dynamics AX |
a) Create a new Row definition. Set field Focus to the Dimension focus you've created in step 1.
b) Click button Structure designer
c) Double-click on the ledger accounts you want to see in the report. You can also use drag and drop
 |
| Row definition in Dynamics AX |
4. Create a new financial statement record (CTRL+N).
5. Set field Main focus = [The dimension focus you've created in step 1]
 |
| Creating a financial statement |
7. On the Setup Tab in the upper part of the form, select Row definition for main focus you've created in step 2.
8. Now lets run the report: GL > Reports > Transactions > Periodic > Financial statement
 |
| Selecting the financial statement defaults main focus and row definition |
10. Click OK.
Here is how your simple balance sheet would look like:
Financial statement report builder is a flexible tool. You can further define periods, compare them one to another, make breakdowns per financial dimensions and many more exiting things.
Of course you may try to implement Management Reporter or FRx, BI 360 or AtlasXL, however this is a free and standard tool, which is robust for most application, given the proper setup.
Too long form name: PBAFrontEndWebApprove_PBN
This error happens in AX 2009 product builder due to incorrectly set up number sequence. To fix it:
1. Go to Product builder > Setup > Parameters
2. To to tab Number sequences
3. Highlight record where Reference field = Product model number
4. Right-click in the Number sequence code field
5. Click Go to Main Table Form. That brings you to the Number sequences - the form that lists all AX counters and numbers, their formats, used in various areas of the application.
6. Set field Largest to 99999
7. Set field Format to PBN_#####. That will make sure that when PB needs to generate a form, the Object name will fit into the length of the object. Alternatively, you can shorten or cut off the PBN_ prefix to allow for more than 99999 product models.
8.
9. Now for NEW product models you'll be able to generate web-forms. If you have already created long product numbers, you can copy them to new, shorter ones, by creating a new product model with a shorter ID and using Functions > Copy from product model.
Enjoy!
Subscribe to:
Posts (Atom)