About the standard batch jobs in AX2012
When you install Microsoft Dynamics AX and complete the initialization checklist a lot of information is build up in the system. Also two batch jobs are created and scheduled to run periodically. This post informs you about these jobs and how to deal with problems you can encounter.
Batch jobs?
Not everyone is aware that two batch jobs are created out of the box by AX. Some people think they don’t need these jobs and delete them. The two batch jobs mentioned in the introduction are displayed in the next picture.
The Automatic role assignment batch job will periodically add Roles to users or revoke these rights. This batch job is standard scheduled to run every hour. This is based on the setup in the form Add users to roles. Per role you can define rules for automatically assigning users. You can make life easier for the security administrators if you can define your rules, so you don’t have to update every single change in the security manually. I have used this feature already with some nice samples which will be a topic for a future blog post.
The Named user license count reports processing batch job will run standard once a week. This job will collect user counts per License type. This data is used on the report Named User License Counts which is accessible from menu System administration. It will determine per run which roles are typed as Enterprise, Functional, Task, etc. Then it will count the users per license type. Note that this batch job collects data from all partitions. Users used in two partitions or more are counted once. When a user has more than one role assigned, the job will find the maximum level per user.
Problems experienced
Now that we know a bit more of these two tasks, we can discuss some problems which can occur. Let`s see how to deal with them or solve them:
Missing batch tasks
When you are missing these batch jobs, there can be multiple reasons.
The first reason is that the batch job Named user license count reports processing is running partition independent. But there is a partition field in the Batch job table. The form Batch job is filtered to show only the batch jobs for the current partition. So check your other partitions first. Normally this job is created in the Initial partition.
The batch job Automatic role assignment is created in the Initial partition, but when you add partitions, this batch job will not be created to run periodically after completing the Partition Initialization checklist.
A last reason is that the jobs might have been deleted.
It is not possible to add these jobs manually in the Batch job form. The class names are not an option in the tasks. So we did not figure out how these tasks were created during the initialization. I did a search on the class name SysSecurityDynamicRoleAssignment and found the following results:
The method createBatchJob from the class SysSecurityDynamicRoleAssignment takes care of inserting a record in the Batch table. This method is called from some classes. We will take a look into the class SysCheckListItem_Synchronize.
The two batch jobs are created when the synchronization task has been completed successfully. To recreate the batch jobs you could run a checklist again and start the Synchronize task, but this will be time consuming. You can also copy the marked lines in the code above and paste them in a new job. Compile the job and run it. Then you will have these batch jobs activated again.
This procedure is not valid in case you miss the Automatic role assignment job in a new partition. The reason is that the method for creating the related batch job contains an incorrect search method for checking if this batch job already exists. Let’s have a look into this method as well:
The highlighted section is the statement which is used to see if already a records exists. If you have a user name Admin in all your partitions, this call will always retrieve a record as the Batch table has the property SaveDataPerPartition set to No. So this table is partition independent, but does have an additional field called DataPartition. This field caters for the filtering per partition. To have the batch job activated in another partition as well, we have to extend the where clause on the DataPartition field.
I created feedback on connect and waiting for an answer.
Note that when you run the job as suggested above with another user than the batch job already was created, it will create a duplicate.
Conclusion
The two batch jobs mentioned in this post are needed in your environment. Make sure these batches are running correctly. I will create another blog soon to give some additional insights in the automatic role assignment. This task can make life of maintaining the assignment of security roles more easy.
The job Named user license count reports processing is mandatory to run. You have to check and provide details about named user license count. This batch job will collect the details weekly and will be used on a report.
Do you have any questions? don`t hesitate to contact us. Also if you found this blog useful please share it.
I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.
That’s all for now. Till next time!
