It would be very nice to be able to take advantage of distributed transactions.
I saw a lot of intefaces written for AX and all of them were unnecessarily complicated to make sure no double processing takes place nor nothing is lost in the middle. All that complication can be avoided if we make use of Microsoft Distributed Transaction Coodinator. Easy said, but unfortunatelly Axapta does not provide such functionality 'out of box'. But not everything is lost, and with some luck it seems to be possible.
MSDN says: In the first step application must call DtcGetTransactionManager from xoleHlp.dll. Piece of cake.
Short script with DLL and DLLFunction and... Oops. "Called dll returned wrong value in BP register". A first obstacle is here: DtcGetTransactionManager is compiled with __cdecl directive, but AX calls it as it were __stdcall, thus stack is not cleaned, and BP mismatched.
To pass this problem I wrote a xolehlp.dll wrapper, which has functions declared in the way AX has no problem to call it.
Now I can call DtcGetTransactionManager and get the object with IID_TransactionDispenser interface. I can even start distributed transaction now.
[to be continued]
Thursday, 16 August 2007
Tuesday, 7 August 2007
Real world processing: TTS and exceptions
Hi everyone,
This is my first post in my blog, so I will start with something which bugs me right from the start of my work with Axapta.
What I find the major flaw in the X++ design is the fact that when exception is thrown, the main, outermost transaction is automatically rolled back, and there is no support for nested transactions. Automatic rollback is even advertised as a 'feature'.
That simple thing is preventing code in AX from doing the real world mass processing, as any exception that will be generated (from the code you have no control over) will destroy all work done so far, even if in particular situation your code is perfectly capable of handling the problem. In fact it should be your, designer's decision about the scale of the problem. Your code has to decide about scale of the problem: it's local, and there's special path to restore from that error- let's go with backup scenario. Outgrows foreseen options? Let's escalate.
Auto-rollback executed as a part of exception is simply taking that decision away from your code and that substantially cripples the number of ways processing can be designed.
Next time I will try to highlight possible solutions to that fundamental issue.
Please do not hesitate to scribble me a comment with your view.
This is my first post in my blog, so I will start with something which bugs me right from the start of my work with Axapta.
What I find the major flaw in the X++ design is the fact that when exception is thrown, the main, outermost transaction is automatically rolled back, and there is no support for nested transactions. Automatic rollback is even advertised as a 'feature'.
That simple thing is preventing code in AX from doing the real world mass processing, as any exception that will be generated (from the code you have no control over) will destroy all work done so far, even if in particular situation your code is perfectly capable of handling the problem. In fact it should be your, designer's decision about the scale of the problem. Your code has to decide about scale of the problem: it's local, and there's special path to restore from that error- let's go with backup scenario. Outgrows foreseen options? Let's escalate.
Auto-rollback executed as a part of exception is simply taking that decision away from your code and that substantially cripples the number of ways processing can be designed.
Next time I will try to highlight possible solutions to that fundamental issue.
Please do not hesitate to scribble me a comment with your view.
Subscribe to:
Posts (Atom)