If you would like to get the userId associated with a specific worker id the DirPersonUser table provides a useful method for this “worker2UserId” E.G.
userId = DirPersonUser::worker2UserId(MyHCMWorkerRecId);
Today’s topic is the EVENTCUD table, I have tried to explain some of the workings of the table and processes around it.
We had a situation where the EVENTCUD table in AX had over 2 million records and just kept on growing on a weekly basis.
After much analysis and trying to understand some very busy and in some places rather inefficient code, the cause was found. Before I get straight to the cause and solution, here is a little brief diatribe about how the EVENTCUD table works.
AX is setup to generate alerts for users, when the alert gets triggered a record is inserted into the EVENTCUD. This record will have a empty (null GUID) for a batchid value. When the change based alert job runs (manual / scheduled), it will then get the users per company from the EVENTCOMPANYRULE table and create new records in the EVENTCUD for the triggered event & then delete the original inserted line. (yip, 1 event = 1 EVENTCUD record x # of users per company (from EVENTCOMPANYRULE) = n EVENTCUD entries). Now these records in the EVENTCUD are process and tasks are created, in AX 2012 the task size is set to 100 events & a batchid is created & assigned to the records in the EVENTCUD table. When the change based alerts job is finished it will delete the EVENTCUD records and there will be new records in the EVENTINBOX where the user has been notified.
Worst case scenario:
i.e. 1 event = 1 EVENTCUD record => 1 EVENTCUD record x # of users/company (10) = 10 new EVENTCUD records & 1 delete original EVENTCUD record => 1 EVENTINBOX record is created
Now for the fun part!!!
When the changed based alerts job is ended unexpectedly, the records with assigned batchid are left behind in the EVENTCUD table. The batchid value is not reverted back to null GUID!, thus when the job runs again these records are not considered for processing, however these records will be looped over (while select statement – one of the inefficiencies) to find the records where the batchid = ‘00000000-0000-0000-0000-000000000000’ so that it can assign them a new GUID and start generating the alerts for the users (EVENTINBOX).
Even though we tried what is called a graceful shutdown of the AOS’s, if the changed based alerts batch job is running the situation above can happen. So double check that the job is either in status “withhold / ended“. We ended up truncating our table to resume BAU functionality in regards to alerts being generated & sent out of AX.
Partner based improvement to code:
- Resolve some of the inefficient code to make sure that some of the while statements are accurate and optimal
- Create some form of clean up job / task to delete old entries in the EVENTCUD table that have batchid’s with a createddatetime greater than our threshold (7 days)
- Update EVENTCUD records to have a null GUID for a batchid value where the records fall in the threshold (7 days)
Hope you have found the above informative.
I have been rather busy in managing environments lately, moving databases backwards from PROD to UAT etc. Due to using different service accounts for the different environments I have started to find that it can be rather cumbersome trying to update everything that needs updating.
From Microsoft AX Support blog , I found a guide & sql script to help out with the task of changing the AOS service account on a DB / Environment .
NOTE: read the guide carefully, you might not need to do everything that has been outlined.
Hello World🙂 , Happy New Year!….
yip, it is 2013.
Here is wishing all of you a wonderful year.
Thank you for reading our posts through 2012.
I’ve been trying to create a help page similar to the landing page that you get when you press F1 from the Purchase Requisitions Details form. This page has two links on it, one to the PurchReq Line Form help page and the second to the Purch Req Header Form.
Initially (for my form) I tried to create this contents page manually, but after some investigation into how the Purch Req Help page works I discovered that if you simply specify the same Microsoft.Help.F1 id for multiple pages, the system will automatically create this contents page for you.
e.g. Header HelpPage <meta name=”Microsoft.Help.F1″ content=”Forms.MyForm” />
Line HelpPage <meta name=”Microsoft.Help.F1″ content=”Forms.MyForm” />
I’m currently working through best practice checks required for Product certification and will be posting fixes / suggestions on how to resolve some of these checks as I come across them.
The first one is the error: No control was found matching the expected node ‘LineDetailsTabs’.
Although I don’t have an exact resolution to this issue, the root cause is the Design Style that you are using for your form. One can find the style used by navigating to your form in the AOT, then selecting the Designs -> Design Node, right click, click properties and view the ‘Style’ property.
I had mine mistakenly set to ‘DetailsFormTransaction’ instead of ‘DetailsFormMaster’. Changing this fixed a number of my Best practice errors.
You can view the Templates for Form styles under the Forms Node in the AOT, they are the forms that start with SysBPStyle_*
The number sequence wizard lack some imagination when it comes to assigning a description to number sequences. Here is some code to help you get more meaningful descriptions.