Migrating long running task from MVC Web App to WebJob reference same projects and code reuse

1
votes

I'm new to WebJobs and I need to add one to my existing MVC Web App (hosted in Azure) to process a long running task. The long running task is carrying out an ETL type process where it calls several external web services to retrieve data via SOAP/XML, saves this data to a SQL db and then transforms the data and the loads the saved data back in the database. This process can take 20-30 mins to run end to end.

I originally had the web app responsible for starting and processing the long running task but realised this doesn't work well and have since decided to move this process to a WebJob. Makes sense?

Most of the logic for the long running task exists inside a service layer and the Controller Action inside the web app was responsible for "starting" the task.

The web app is using Autofac for DI.

What's the best way to share/re-use the existing Autofac configuration from the web app without having to duplicate the code within the WebJob application? i.e. can/should the WebJob reference the MVC web app project?

1
c#asp.net-mvcazureautofacazure-webjobs
If you use Autofac, you can create module that can be reused. Put your DI registrations into a separate assembly and reference it from your MVC and your webjob. Saying that, I don't think you should reused DI registration, DI is application configuration. Moreover I am pretty sure that all your registrations will have a different scope so you will not be able to reuse anything or few things. - Thomas
Also Webjob expose a IJobActivator that can do the trick to inject dependencies - Thomas

1 Answers

0
votes

I wonder if you're still actually decoupling the processes - its difficult to tell from your description. When you say the controller "starts" the task - how is this happening? What you might want to do, is have the controller create a new message on a storage queue, and have the webjob trigger on receipt of a new message on the same queue. This is the "standard" way to decouple layers. The webjobs api has built in bindings for storage queues. As for the architecture of the services layer, if you build your apps (web app and web job) so that they use interfaces to call the service layer, and the interfaces and services are implemented in a separate assembly/dll, then it should all work well with any DI container tool like Autofaq - it's not really related to the way in which processes host your services though.

Process 1: Web App -> use IJobService.CreateJob() -> puts message on Storage Queue

Process 2: Web Job [Trigger from Storage queue] -> use IJobService.Process() -> updates sql db