asynchronous operation

If the code doesn’t work, carefully explain the problem to your cardboard developer sitting next to you, more often than not you will realise what is wrong – Hosk

I wanted to know if my plugin had run correctly, I wasn’t sure it had run successfully. I was looking at the records to trying to work out if the values had been modified by my plugin. it should have changed but I still wasn’t sure.

A CRM developer – Big D suggested I check the SystemJob table and boom there it was the plugin that had run and the next plugin it had triggered. In fact the SystemJob has a wealth of information about Async plugins, async workflows, system jobs. You can see if they have run, if they were successful.

I had never looked at the SystemJob table before and certainly never realised that plugins created records on the SystemJob, what is this are these SystemJob.

What is a SystemJob

As always CRM developers should start with the CRM SDK and there is a great article on the subject

AsyncOperation (system job) entity

A system job, also known as an asynchronous operation, is used to define and track the execution of an asynchronous operation, for example an asynchronous registered plug-in, workflow, or other background system operation.

So the SystemJob record is created for AsyncOperation, this means synchronous plugins will not create SystemJobs records.

If you don’t know the difference between Synchronous and Asynchronous plugins/custom workflows.

Synchronous plugins are triggered straight away. So if your plugin is triggered on the Create message, it will run directly either before (validate or Pre) the database transaction or after (post) the database transaction. The CRM form will wait until the Synchronous plugin has finished processing before the form reloads.

Asynchronous plugins/workflows will be triggered some time later when the CRM service has enough resources. You don’t know when this will be triggered (usually it’s done quite quickly). Async plugins do not slow the form reloading because it doesn’t have to wait.

I believe because the sync plugins fire straight away the developer can get feedback it has run but async plugins run in their own sweet time, it’s difficult to know if they have been triggered. So Microsoft creates a SystemJob record.

It is only plugins/custom workflows which get SystemJob records created by

Async Plugins
Async Custom workflows
GUI Workflows
Bulk Delight

Do you have to create a SystemJob record

No CRM will create the SystemJob automatically. This means it’s a useful tool for to report if you CRM async operations are running successfully or erroring.

Plugins are of type System Event

The name of the SystemJob is the name of the plugin

When would you use looking at systemJob

I used it today, I was looking at a plugin called updateBirthdayReminder, it was triggered when the birthday is updated on a contact. It didn’t seem to be working or doing what it should be doing, so my first question was

is the plugin running?

The Delete AsyncOperation if StatusCode = Successful was ticked, so I un ticked this and updated the birthday. I then and saw the plugin was running.

I turned on the profiler because I wanted to step through the code but because the plugin was async, it didn’t throw an error. I looked at the systemJob and saw it had run but was waiting and in the systemJob

I could see it had profiler in brackets and the contents is the error for the profiler. For those of you who don’t know the profiler works by throwing an error at the end of the plugin, this stops the plugin code completing and the error code is serialized objects, records etc and all the data which was being being passed from the CRM Form to the plugin. When you debug in the plugin profiler, it deserializes the information and passed it to your plugin. Read more about the plugin profiler this blog post – CRM 2015 – Understanding the plugin profiler and a puzzling error

I copied the error and put it into a text file and selected it in the plugin profiler and I was then able to step through the code.

This was interesting because it means I could debug and step through the code despite the code being an async plugin.

You Don’t have to create SystemJob records

You can not create SystemJob records if you tick the Delete AsyncOperation if StatusCode = successful. This setting doesn’t create SystemJobs for async jobs which run successfully.

I found some information about the Delete AsyncOperation on this page

Delete AsyncOperation if StatusCode = Successful

you can set it

Delete AsyncOperation if StatusCode = Successful

When any asynchronous operation completes, a System Job entity is created to record the completion status. You can view these system jobs in the Web application by selecting Settings, and then click System Job. Check this option if you want plug-in related system jobs automatically deleted when the status is successful.