Thirteen years with Axapta and finally got it today!
Showing posts with label debug. Show all posts
Showing posts with label debug. Show all posts
Friday, May 7, 2021
Saturday, November 30, 2019
Thursday, August 15, 2019
How to debug Workflow in D365 without access to Batch.exe
Correct me if I am wrong, but there is no specific article https://docs.microsoft.com about debugging custom Workflow in D365.
So, once I bumped into necessity to test my custom Workflow classes, I found myself unlucky not having admin rights fot Batch.exe (as described here https://ax.docentric.com/debug-workflows-in-dynamics-365-for-finance-and-operations/)
Next search results (in particular this one https://thwidmer.wordpress.com/category/dynamics-ax-2012/page/2/) brought me to the following steps.
I stopped DynamicsAxBatch, which execute actual batch processing in D365.
I added the following simple class and and a menu item button to a form.
Now I run it by the button to execute batch processing in step-by-step mode, and it perfectly hits my breakpoints inside of Workflow handlers once I attached to the standard IIS process.
So, once I bumped into necessity to test my custom Workflow classes, I found myself unlucky not having admin rights fot Batch.exe (as described here https://ax.docentric.com/debug-workflows-in-dynamics-365-for-finance-and-operations/)
Next search results (in particular this one https://thwidmer.wordpress.com/category/dynamics-ax-2012/page/2/) brought me to the following steps.
I stopped DynamicsAxBatch, which execute actual batch processing in D365.
I added the following simple class and and a menu item button to a form.
class CDPWFDebuggerActive { static public void main(Args _args) { SysWorkflowMessageQueueManager::runStatic(conNull()); } }
Now I run it by the button to execute batch processing in step-by-step mode, and it perfectly hits my breakpoints inside of Workflow handlers once I attached to the standard IIS process.
Friday, January 23, 2015
Breakpoint; in CIL code
I needed to debug batch processing in BatchRun.ServerGetTask() method.

It was a wrong idea to add breakpoint; instruction into a managed code. Of course, after stopping my AOS did not start anymore because of the error:
Just-In-Time debugging this exception failed with the following error: The operation attempted is not supported
The easiest way to recover this problem is to delete the forementioned instruction and recompile CIL, but I have not access to AOT X++ editor anymore.
Alternatevily, as described in How-To-Debug-Managed-Code-In-AX2012, I did catch this breakpoint in Visual Studio during the short period between Starting and Stopped statutes of AOS service.
Launch Visual Studio as administrator.

Open the class method in question directly frpm xppCIL\Source folder.


Start the AOS service.

Switch back to Visual Studio and attach to the process. It appeared in a few seconds.

Then it stopped at the problematic breakpoint.

Pressing F5 each time it stopped there (actually every minute, as it supposed to be for batch processing), I changed my code back and run full CIL.

Please, do not place breakpoint; in managed code like I did.
Full MSDN article about debugging in AX 2012.

It was a wrong idea to add breakpoint; instruction into a managed code. Of course, after stopping my AOS did not start anymore because of the error:
Just-In-Time debugging this exception failed with the following error: The operation attempted is not supported
The easiest way to recover this problem is to delete the forementioned instruction and recompile CIL, but I have not access to AOT X++ editor anymore.
Alternatevily, as described in How-To-Debug-Managed-Code-In-AX2012, I did catch this breakpoint in Visual Studio during the short period between Starting and Stopped statutes of AOS service.
Launch Visual Studio as administrator.

Open the class method in question directly frpm xppCIL\Source folder.


Start the AOS service.
Switch back to Visual Studio and attach to the process. It appeared in a few seconds.

Then it stopped at the problematic breakpoint.

Pressing F5 each time it stopped there (actually every minute, as it supposed to be for batch processing), I changed my code back and run full CIL.

Please, do not place breakpoint; in managed code like I did.
Labels:
aos,
AOT,
AX2012,
batch,
batch processing,
breakpoint,
debug,
Visual Studio
Monday, June 4, 2012
Monday, March 30, 2009
Watching variables of a report
Friday, October 31, 2008
Debugging code on Business Connector
As MSDN our suggests, first, we should enable Debugger on the client, (do not be confused with versions! my previous link is correct for AX 4.0 and AX 2009 too, but this is only for AX 3.0)






Then, we must to enable the same on the Business Connector with Configuration Utility: (in my case I had to check both in order to debug my web service)

Now, you can add a breakpoint in your code.

Finally, you should run an instance of Debugger manually from the client's main menu because it does not start automatically as usually.

In conclusion I need to say that you should log in on your debugged application with the same user account which was used for the client and debugger sessions.

Lucky hunt for bugs!
Thursday, April 17, 2008
Subscribe to:
Posts (Atom)




