While performing Workflow Infrastructure Configuration, you might face the following exception:
The user account entered for the workflow execution account is not valid. Confirm that the account exists and is enabled.
Please perform the following steps to resolve the issue:
1. Click System administration > Setup > System > System service accounts.
2. Specify the Workflow execution account in the form.
3. Click OK.
Once you have specified the workflow execution account then you should be able to perform the Workflow infrastructure configuration using the wizard.
Open command prompt and run the following command to get the SID of the current logged-in user:
Recently I came across the following exception while executing a batch job via a menu item. The batch job has been written using the SysOperation Framework.
To fix this, please follow the steps below:
- Create Code Permission
- Link it with the menu item
Create a new code permission under AOT > Security > Code Permissions. Add a server method for the newly created code permission. Specify the following properties for the server method added:
- Class: Your SysOperation service class
- Method: Method name to invoke
- EffectiveAccess: Invoke
- ManagedBy: Manual
Now link your code permission with the menu item which is used to trigger the batch job. Use LinkedPermissionType and LinkedPermissionObject properties to achieve it! This should be resolving the exception.
All the batch jobs and service operations now run in the managed code (IL) and therefore breakpoints set in x++ do not get hit as expected! Instead you should be setting breakpoints in the IL code in Visual Studio. Here are the steps you would be following to do so:
1. Open Visual Studio as an Administrator and go to Tools > Options > Debugging > General. Make sure “Enable Just My Code (Managed Only)” is unchecked.
2. Go to Debug > Attach to Process. Click “Select…” and check the appropriate version of the managed code in your case.
3. Check both options at the bottom of “Attach to Process” form. Select Ax32Serv.exe from the list of processes.
4. Load the XppIL source file in Visual Studio now. Make sure you have enabled breakpoints to debug x++ code in the AX Server Configuration Utility. You can find these files under a location similar to the following:
C:\Program Files\Microsoft Dynamics AX\6.3\Server\AxaptaDev\bin\XppIL\source
5. Now set the breakpoint at any of the desired statement.
6. Finally, trigger the batch job or service operation to debug in the AX Client. The breakpoint set in Visual Studio should be hitting now! Make sure to generate IL to reflect the changes in the XppIL source files after updating the x++ code.
If you are working on objects (Tables or Classes) you haven’t designed then it is quite possible you could have an insight about these objects by reverse engineering them to either data model or object model. I came to know about an excellent reverse engineering tool in AX 2012, that’s why sharing here for others.
First of all create an empty project and add the tables or classes to this project you want to reverse engineer.
Then right click the project node, click Add-Ins then click Reverse Engineer.
Select Visio UML data model or object model depending on the elements you have added to the project (Tables or Classes). Give appropriate path to save the Visio file to.
Reverse engineering starts. After the processing complets Visio open up automatically.
In Visio under Model Explorer you can find your project node under Top Package. You can find your tables in the relevant table group node. AX categories each table created. The default value of table group property is “Miscellaneous”. In my case all the tables can be found under Miscellaneous node.
Drag the tables to the drawing pane one by one and see how Visio renders table fields and relationships automatically.
Often AX tables contain more than 100 columns which results in a tedious data model in which relationships are hard to view. To only view the relationships and hide the columns, you can suppress table columns (attributes). Right click on the table, click Shape Display Options.
Check attributes under Suppress section to hide the attributes. In this way you can view the relationships easily!
If you are not hitting the breakpoints you set in X++ code as expected then make sure that your code isn’t executed by the SysOperation Framework (formerly known as Business Operations Framework – BOF). If this is the case then you can force the AOS to debug your code in Dynamics AX Debugger by CLEARING the following check in Dynamics AX Development Workspace:
Tools >> Options >> Development >> Execute Business Operations in CIL
Moreover, make sure that Debug mode is set to:
Actually AX 2012 executes business logic as compiled .NET CIL to run faster. You can also debug your X++ code in Visual Studio Debugger by opening your method’s xpp file in Visual Studio then attaching to Ax32.exe process (Tools >> Attach to Process). In this way you will be debugging your X++ code in compiled .NET CIL mode. You can find your method’s xpp file under the following location:
C:\Program Files\Microsoft Dynamics AX\6.3\Server\AxaptaDev\bin\XppIL\source\<TableName\ClassName>.<MethodName>.xpp
Now if your X++ code runs under SysOperations Framework, then it will be invoked by any of the following methods: