here is a simple job to enable SQL tracing for all your users, this quite handy for optimizing queries. (The macro’s for modifying other fields on the UserInfo table can be found on the ClassDeclaration of the SysUserSetup form.)
Make sure that client tracing is enabled in the server configuration. (Only use this in development and testing environments, tracing may affect the AOS performance.)
Server configuration
The results can be found in the Administration module.
Next post will be a little tutorial on how the RunBaseBatch framework can work multithreaded. For example in the SalesFormLetter class on the method run, the following code will be found before the query iteration:
The SalesFormLetterEndMultiThread that is being created will be called when all threads connected to that bacth are processed, this will call methods like printJournal and endUpdate. Notice that all the variables that are passed in the construct method are also defined in the CurrentList macro for packing and unpacking, this is important to keep in mind when writing custom code.
In the iteration itself, another multithread batch task is created for each line.
So foreach SalesParmTable found an instance of the runtime task FormLetterMultiThread is created, and is a dependency for the SalesFormLetterEndMultiThread to run.
Now let’s create our own simple example.
Start by creating a RunBaseBatch class like you would otherwise do, but make sure that the code witch uses the most load is written in a separate method and called from the run. This method will be called from the threads. (method: updateSalesOrder)
The canMultiThread method is the same as in the FormLetter class.
The second class you need to create is kind of a wrapper class that also extends from RunBaseBatch and will be used to create the subtasks for your batch process. Make sure that the runsImpersonated method returns true.
Remember that you need to keep an instance of the caller class (TSTSalesOrderUpdate) and you need to pack and unpack it.
The run method should call the updateSalesOrder on your TSTSalesOrderUpdate class. This means that all the logic is placed in one place, because it should also work when not running in batch. 😉
In addition you can add an ending multithread class if necessary, like the FormLetterEndMultiThread class. The maximum number of simultaneous batch thread can be defined on the SysServerConfig form.
The example given is only for educational purposes. (It is somewhat sloppy 🙂 )
Here is a simple code snippet to create Batch jobs from code. This convenient when starting a heavy load job from a user interface and still keep the client responsive.
Many projects use an interface to import their sales orders, because of this a SalesAutoCreate class was created. This class is easily extendable and customizable.The first thing to do is designing a buffer table, like this one for example:
Sales order import table
After this we can start extending a new class from the SalesAutoCreate class and modifying the construct on the SalesAutoCreateClass .
class TSTSalesAutoCreate extends SalesAutoCreate
{
TSTSalesImport TSTSalesImport;
}
When extending from the SalesAutoCreate class some methods must be implemented:
setCust
salesType
recordExist
nextRecord
invoiceAccount
In my example I’ve implemented them like this:
protectedvoid setCust(){;
custTable = CustTable::find(TSTSalesImport.CustAccount);
if(!custTable){throw error("Custtable not found!");
}}protected SalesType salesType(){;
return SalesType::Sales;
}protectedboolean recordExist(){;
return TSTSalesImport.RecId!=0;
}protectedvoid nextRecord(){;
next TSTSalesImport;
}protected CustInvoiceAccount invoiceAccount(){
CustInvoiceAccount ret = custTable.InvoiceAccount;
;
if(!ret){
ret = custTable.AccountNum;
}return ret;
}
The next step is setting our table and line fields by overriding the setSalesTable and setSalesLine methods and make sure that you always call the super first. Notice that you need to call the createSalesTable and createSalesLine to do the insert.
the final step is to call the logic from a job or a RunBaseBatch class, make sure that you select records on the same tier as the nextRecord will run or else it will fail. Preferably on the server tier. 🙂
This example lacks some validation whether the record has already been processed or not, so it will created the same records every time it is called. You could implement your own method on the SalesAutoCreate class, call it from the create method and override it on your custom class, like this.
While doing a small AIF project I wrote a small batch class to cleanup the AIF document log because the button on the AifDocumentHistory form can take up a huge amount of time. The first thing I did to write this class is checking out the standard Ax code in the following method ClassesAifMessageManagerclearAllProcessedAndError. This method uses a progress bar and deletes records in batches of 3000 records, this is something we don’t need when running in batch.
The first thing our method needs to do is check if we have access rights to delete.
The next step is calling all the skip methods, Microsoft does this to make sure that a delete_from doesn’t fall back to row by row deletes.
skipAosValidation : Skips all validation methods (validateWrite, validateDelete, validateField)
skipDatabaseLog : Prevents SQL from making transactions logs.
skipDataMethods : Forces doInsert, doUpdate instead of insert, update.
skipDeleteActions : Skips all actions defined under DeleteActions ( For example: Deleting a SalesTable also deletes all referencing MarkupTrans records. )
skipDeleteMethod : Forces doDelete instead of delete.
skipEvents : Disables a lot of kernel events to increase performance.
Since i’m getting a lot of google hits on my Dynamics Ax – workdays to days post, i’ve decided to blog some more about it. The DateTimeUtil class is actually a wrapper of the .NET DateTime class.
A first thing to remember when using UtcDateTime EDT’s is that it is stored like the name says as Coordinated Universal Time.
The controls on the form will translate the DateTime to the timezone of the client. Now keeping this in mind is very important when mixing date, time and datetime controls. The following example will make it more clear.
The first field is a UtcDateTimeEdit control with a data method that returns DateTimeUtil::UtcNow().
As you can see the time is 08:58, but the first control on the form shows 10:58. This is correct because my client timezone is (GMT+01:00) Brussel, Kopenhagen, Madrid, Parijs and it’s summer time.
The second field is a TimeEdit control with a data method that returns DateTimeUtil::time(DateTimeUtil::utcNow()), this isn’t correct because it will always return the time in the UTC timezone and the control will not translate it to the correct timezone.
The third field is another TimeEdit control with a data method that returns TimeNow(), this is correct because the TimeNow method will also apply the client/server (depending on the tier) timezone.
this also applies to field in a table.
Datetime example
Another way to use Time controls and the DateTimeUtil is using the applyTimeZoneOffset method.
UtcDateTime ret;
;
ret = DateTimeUtil::applyTimeZoneOffset(DateTimeUtil::utcNow(),TimeZone::GMTPLUS0100BRUSSELS_COPENHAGEN_MADRID);
return DateTimeUtil::time(ret);
but this is a lot of code for a rather more simple thing 🙂
A second thing to remember, when querying with a date on UtcDateTime fields make sure you select the whole day from 00:00:00 to 23:59:59.
For this I like to implement a method on the Global class, it’s keeps you’re queries cleaner 😉 It works the same way as all .NET developers use, Add a with time 0 and subtract a second.
For testing purposes with the MRP we needed to modify the createdDateTime fields in Dynamics Ax 2009. Since these are system fields we needed a workaround.
Since this code is pretty exotic and you don’t want to release this to a production environment we eventually didn’t use this but ran some sql jobs, but this shows that it is possible.
edit
Easy does it 😉
DECLARE@DATAAREAIDnvarchar(4)DECLARE@SALESIDnvarchar(20)DECLARE@DATETIMEdatetime/* EDIT THE FIELDS BELOW */SET@DATAAREAID='CEU'SET@SALESID='00003352_058'SET@DATETIME='01/01/98 00:00:00.000'/* DO NOT EDIT HERE */UPDATE dbo.SALESTABLESET CREATEDDATETIME =@DATETIMEWHERE SALESID =@SALESIDAND DATAAREAID =@DATAAREAID;UPDATE dbo.SALESLINESET CREATEDDATETIME =@DATETIMEWHERE SALESID =@SALESIDAND DATAAREAID =@DATAAREAID;
Today I had to fix a bug in some custom code in Dynamics Ax 2009, we had an error from the JournalTransList class that stated “A key with the name %1 already exists.”
Cause:Â A custom field on the WMSJournalTrans table that was extending from LineNum
Reason: The JournalTransList has methods to check if the primary index on the actual table won’t be violated, therefore it seems to look for all fields that extend from LineNum.
Solution: Create you’re custom EDT that extends from LineNum and add that one to the table, it’s a best practice but who thought this could be so critical :p
Ever had to calculate the number of days starting from a number of workdays and even deal with holidays.
A pretty straightforward example using the DateTimeUtil class and DayOfWk method.
staticvoid WorkDaysToDays(Args _args){int workDays =10;
int days =0;
date startDate =systemDateGet();
CalendarId calendarId = CompanyInfo::find().ShippingCalendarId;
;
if(calendarId){while(workDays >0){if(dayofwk(startDate)!=6&&dayofwk(startdate)!=7&& WorkCalendarDate::isDateOpen(calendarId,startDate)){
workDays--;
days++;
}else{
days++;
}
startDate = DateTimeUtil::date(DateTimeUtil::addDays(DateTimeUtil::newDateTime(startDate,0),1));
}
info(strfmt("Workdays = %1, Days = %2",workDays,days));
}else{
error("No calendarId found");
}}