Dynamics AX 2009 - X++ Thread Development
One of the possible technical tools that exists when developing solutions in Dynamics AX, and inside X++ is Threads. This is actually not a new thing, thread based development has been around for a while.
The whole idea of creating a seperate thread to perform a process is an accepted technique to achieve multi processes at a given time, managed from the given, seperate application thread that the user application is taking up.
With, however Dynamics AX, sometimes it's not that clear of where and why you would use Thread to achieve a given process, or development goal.
I used and use threads a lot in C#, and the Thread development that exists in C# is for robust, and can become complex. And lets face it, Thread development and management of spawned threads from a application can become complex.
So with X++, there does exists the ability to use Threads for development needs. The following is a simple example of a Thread, a Method that the Thread is executed upon, and how to execute the simple thread.
With this we see a simple threaded development approach that can be used in X++. To break this down a little bit, you have a job, class, method etc. that is performing some work. In that is wants to spawn a thread.
The method that will be spawned as a new Thread, must accept a Thread as it's only parameter, and best practice on this says it should be a server static method that is the executed thread method.
You notice that there are input parameters and output parameters. These are containers, and therefore can store a number of different in and out parameters, to and from the threaded method. This is very useful as the thread could be developed in a way that would return some output.
Now this is great and all, but when would this be used?
Since Dynamics AX is an ERP product, that means a lot of process and needed development flows have to take place in a linear approach. However there are some things that do not have to be. Or some process that can be developed, so that threads can be used to improve the performance of a long running process for example.
So, with thinking about Threads, you have to think about divison of a given process into several Threads. Thats the nature of thread development.
This means, that if a given data process is taking hours and hours, can it be devided into smaller chunks of data? If so, but you need the whole thing to process, then a Threaded development approach can be done, where the given data process can be selected, and by the division, say a date or a group, can be used to spawn a thread to import data, doe that given divison unit.
This means, that if you have, say, 100,000 records to import. And that process is taking 3 hours. But you realize, you can break these 100,000 records into 10,000 records a peice, by a Item group.
Then you can take and have a method that loops through the grouped, by Item group, selection, and spawn a thread per 10,000 or by Item Group, and therefore speed up the process x10 fold. This means that the process that was taking 3 hours, can be done in an estimated 18 mins.
This directly ties to what DAXGuy, posted about here.: DAXGuy: SSIS for Bulk insert into Dynamics AX 2009 and this represents another way of inserting a large amount of data. What this approach, using threads, offers is it's X++ based, and therefore X++ busienss logic that might live on a given table in AX can be accessed and used. Note: Thread imports, most likely will not be as fast as a bulk insert process. But when a bulk insert is not possible, think about threaded development.
Now some notes about threaded development now. One, make sure everything that a thread accesses and executes is server tier code, or server context code. This makes sense, the thread executes on the Server tier, and in doing so, can't access client side code. If you try to do so, the thread will error out.
Also, if a thread is actually executed at the Client level, even though it's server side code being executed, for every thread spwaned a worker type user license will be used, and seen in the online users form.
Also, finally, I would like to point out that Microsoft itself uses threads in the MRP process, and other processes like ReqTrans, to try and speed up the processes in these areas. Thread development should be a serious consideration, but there are some limits.
For examples I tried to do a multi-tree thread approach. Meaning I tried to spawn sets of threads in threads. This is not possible. For whatever reason, the first thread in the threaded, thread approach will execute, after that the other spwaned threads are stopped.
If the multi-tree thread approach would work, then you could spawn mutli level threads, really attacking long running processes, by breaking it up into smaller, and smaller chunks. However, as my test have shown, this is not possible.
I hope this helps shed some light on threads in Dynamics AX 2009, and that it helps getting you thinking about how threads can be used in x++ to help with your coding needs.
That's all for now but check back soon!
"Visit the Dynamics AX Community Page today!"
The whole idea of creating a seperate thread to perform a process is an accepted technique to achieve multi processes at a given time, managed from the given, seperate application thread that the user application is taking up.
With, however Dynamics AX, sometimes it's not that clear of where and why you would use Thread to achieve a given process, or development goal.
I used and use threads a lot in C#, and the Thread development that exists in C# is for robust, and can become complex. And lets face it, Thread development and management of spawned threads from a application can become complex.
So with X++, there does exists the ability to use Threads for development needs. The following is a simple example of a Thread, a Method that the Thread is executed upon, and how to execute the simple thread.
With this we see a simple threaded development approach that can be used in X++. To break this down a little bit, you have a job, class, method etc. that is performing some work. In that is wants to spawn a thread.
The method that will be spawned as a new Thread, must accept a Thread as it's only parameter, and best practice on this says it should be a server static method that is the executed thread method.
You notice that there are input parameters and output parameters. These are containers, and therefore can store a number of different in and out parameters, to and from the threaded method. This is very useful as the thread could be developed in a way that would return some output.
Now this is great and all, but when would this be used?
Since Dynamics AX is an ERP product, that means a lot of process and needed development flows have to take place in a linear approach. However there are some things that do not have to be. Or some process that can be developed, so that threads can be used to improve the performance of a long running process for example.
So, with thinking about Threads, you have to think about divison of a given process into several Threads. Thats the nature of thread development.
This means, that if a given data process is taking hours and hours, can it be devided into smaller chunks of data? If so, but you need the whole thing to process, then a Threaded development approach can be done, where the given data process can be selected, and by the division, say a date or a group, can be used to spawn a thread to import data, doe that given divison unit.
This means, that if you have, say, 100,000 records to import. And that process is taking 3 hours. But you realize, you can break these 100,000 records into 10,000 records a peice, by a Item group.
Then you can take and have a method that loops through the grouped, by Item group, selection, and spawn a thread per 10,000 or by Item Group, and therefore speed up the process x10 fold. This means that the process that was taking 3 hours, can be done in an estimated 18 mins.
This directly ties to what DAXGuy, posted about here.: DAXGuy: SSIS for Bulk insert into Dynamics AX 2009 and this represents another way of inserting a large amount of data. What this approach, using threads, offers is it's X++ based, and therefore X++ busienss logic that might live on a given table in AX can be accessed and used. Note: Thread imports, most likely will not be as fast as a bulk insert process. But when a bulk insert is not possible, think about threaded development.
Now some notes about threaded development now. One, make sure everything that a thread accesses and executes is server tier code, or server context code. This makes sense, the thread executes on the Server tier, and in doing so, can't access client side code. If you try to do so, the thread will error out.
Also, if a thread is actually executed at the Client level, even though it's server side code being executed, for every thread spwaned a worker type user license will be used, and seen in the online users form.
Also, finally, I would like to point out that Microsoft itself uses threads in the MRP process, and other processes like ReqTrans, to try and speed up the processes in these areas. Thread development should be a serious consideration, but there are some limits.
For examples I tried to do a multi-tree thread approach. Meaning I tried to spawn sets of threads in threads. This is not possible. For whatever reason, the first thread in the threaded, thread approach will execute, after that the other spwaned threads are stopped.
If the multi-tree thread approach would work, then you could spawn mutli level threads, really attacking long running processes, by breaking it up into smaller, and smaller chunks. However, as my test have shown, this is not possible.
I hope this helps shed some light on threads in Dynamics AX 2009, and that it helps getting you thinking about how threads can be used in x++ to help with your coding needs.
That's all for now but check back soon!
"Visit the Dynamics AX Community Page today!"
Labels: C#, Code Example, Dynamics AX 2009, Microsoft, Performance, Thread Development, Threads, X++
posted by brandon | 5:13 PM
4 Comments:
Magnificent post. I have a bitter sweet relation with threads but never considered using it in X++. You put it forward in a very appealling manner which encourages me to take it up. Thanks for a VERY informative blog.
Very interesting post regarding threading in X++ using the Thread class object in Dynamics AX. This past year we actually implemented thread logic using the Thread class to process sales orders (automatically reserving, picking and packing) in real time, which allows our fulfillment center to pull work on demand and not wait for a batch job to complete. These batch jobs ran multiple times a day for 3-6 hours and now the processed orders go into a picking list queue to be pulled on demand for printing.
The key for this all to work was the thread logic allowing the customer service rep to enter the order and continue on to the next customer without waiting for the order to process and without interruption. This has been a huge success.
Thanks for the post on the subject. When we first starting looking at the Thread class we didn’t find many references on this topic.
Good post. It's worth keeping in mind though that in your example you wouldn't be looking at a 10-fold increase in speed for an import, where the bottle-neck is the database. Threads are better suited to CPU or IO-bound operations, which is why MRP is a good candidate. Also keep in mind some of the more finnicky things like transaction-scope among different threads, and infolog usage which won't work as expected.
Dan,
You are correct in that Threads best address CPU needs / bottlenecks the best.
However I tested out this given process for data import as well. And with data operations, it did increase the speed by the given % I stated. It's because for each worker process / spawned thread, a given different SPID was being used, to access that given section, based on a where clause, fot he given tables.
So it did increase the importing and operation of data by as much as I stated.
There could a possibility where this does not makes sense, actually a lot of times. As I stated most ERP processes have to happen in a linear fashion.
However if you have a good way to split up the data, in some form of where clause, then this can speed up data operation processes as well.
Thanks!
-Brandon
Post a Comment
<< Home