This project has moved. For the latest updates, please go here.


Stick some jobs in the service to execute

In order to have all this nice and easy in one solution, you'll have to run the service and demos in the following way :
  • First run the service. Then right click on Demo.CreateJobs and click "Debug > Start new instance". This allows you debug the demo app and have the service running at the same time.
  • The demo app creates some "Callback" jobs (which in turn requires Demo.CallbackTestImp website) - basically the job when executed will call a webservice that you can debug in the same way (start it before the console app though)

Implementing your own jobs

The first step to understanding jobs is to look at the sample projects. If you open "BackgroundWorkerService.Logic.TestJobs" folder, you'll find 3 sample very simple jobs that don't do anything.

A job is simply a class implementing BackgroundWorkerService.Logic.Interfaces.IJob interface. There's only one method

Execute(string jobData, string metaData)

jobData is whatever you passed in when creating the job. It could be anything, from an empty string, a number (stored as string) or for more complex cases a serialized class. You'll usually store something like an ID or record in there for processing, anything that is specific to this INSTANCE of the job.

metaData is more about storing information that you wouldn't exactly call part of the identifying info. For example, your job could count the number of times it has executed and after 5 times give up.
metaData is also different to jobData in that if it is set in your job, it will be persisted to the job store after your job has returned from execution.
If you look at "BackroundWorkerService.Jobs.BasicHttpSoapCallbackJob" (a job implementation that allows remote callbacks), you'll find the metaData field wraps some information about the callback around the actual job's metaData.

Some items of note when implementing jobs :
  • You have to set the ResultStatus before returning
  • You can set the metaData. If it's not the same as before the call ( and not null ), it will be persisted back when your job finishes
  • You have to handle deserialization (if any) of your jobData/metaData yourself. I've found it's not a problem because your process usually does the serialization as well.
  • The dll that your job is located in must be in the path where the BWS is running, or the GAC (Activator.CreateInstance must be able to find it).
  • You should catch any errors and return an error message in the ErrorMessage field. You CAN let exceptions go, you just won't receive detailed enough error messages sometimes

Last edited Jan 12, 2014 at 6:19 PM by dawidpotgieter, version 4


No comments yet.