Comment commencer à Quartz ASP.NET Core?

TL;DR (réponse complète peut être trouvée ci-dessous)

Supposé de l'outillage: Visual Studio 2017 RTM, .NET de Base 1.1, .NET SDK de Base 1.0, SQL Server Express 2016 LocalDB.

Dans l'application web .csproj:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <!-- .... existing contents .... -->

  <!-- add the following ItemGroup element, it adds required packages -->
  <ItemGroup>
    <PackageReference Include="Quartz" Version="3.0.0-alpha2" />
    <PackageReference Include="Quartz.Serialization.Json" Version="3.0.0-alpha2" />
  </ItemGroup>

</Project>

Dans le Program classe (comme échafaudée par Visual Studio par défaut):

public class Program
{
private static IScheduler _scheduler; //add this field
public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.UseStartup<Startup>()
.UseApplicationInsights()
.Build();
StartScheduler(); //add this line
host.Run();
}
//add this method
private static void StartScheduler()
{
var properties = new NameValueCollection {
//json serialization is the one supported under .NET Core (binary isn't)
["quartz.serializer.type"] = "json",
//the following setup of job store is just for example and it didn't change from v2
//according to your usage scenario though, you definitely need 
//the ADO.NET job store and not the RAMJobStore.
["quartz.jobStore.type"] = "Quartz.Impl.AdoJobStore.JobStoreTX, Quartz",
["quartz.jobStore.useProperties"] = "false",
["quartz.jobStore.dataSource"] = "default",
["quartz.jobStore.tablePrefix"] = "QRTZ_",
["quartz.jobStore.driverDelegateType"] = "Quartz.Impl.AdoJobStore.SqlServerDelegate, Quartz",
["quartz.dataSource.default.provider"] = "SqlServer-41", //SqlServer-41 is the new provider for .NET Core
["quartz.dataSource.default.connectionString"] = @"Server=(localdb)\MSSQLLocalDB;Database=Quartz;Integrated Security=true"
};
var schedulerFactory = new StdSchedulerFactory(properties);
_scheduler = schedulerFactory.GetScheduler().Result;
_scheduler.Start().Wait();
var userEmailsJob = JobBuilder.Create<SendUserEmailsJob>()
.WithIdentity("SendUserEmails")
.Build();
var userEmailsTrigger = TriggerBuilder.Create()
.WithIdentity("UserEmailsCron")
.StartNow()
.WithCronSchedule("0 0 17 ? * MON,TUE,WED")
.Build();
_scheduler.ScheduleJob(userEmailsJob, userEmailsTrigger).Wait();
var adminEmailsJob = JobBuilder.Create<SendAdminEmailsJob>()
.WithIdentity("SendAdminEmails")
.Build();
var adminEmailsTrigger = TriggerBuilder.Create()
.WithIdentity("AdminEmailsCron")
.StartNow()
.WithCronSchedule("0 0 9 ? * THU,FRI")
.Build();
_scheduler.ScheduleJob(adminEmailsJob, adminEmailsTrigger).Wait();
}
}

Un exemple d'une classe d'emploi:

public class SendUserEmailsJob : IJob
{
public Task Execute(IJobExecutionContext context)
{
//an instance of email service can be obtained in different ways, 
//e.g. service locator, constructor injection (requires custom job factory)
IMyEmailService emailService = new MyEmailService();
//delegate the actual work to email service
return emailService.SendUserEmails();
}
}

Réponse complète

De Quartz .NET de Base

Tout d'abord, vous devez utiliser la version 3 de Quartz, qu'il cible .NET de Base, selon cette annonce.

Actuellement, seules les versions alpha de v3 paquets sont disponible sur NuGet. Il ressemble à l'équipe a mis beaucoup d'efforts en libérant des sections 2.5.0, qui ne cible pas .NET de Base. Néanmoins, dans leur dépôt GitHub, le master branche est déjà dédié à la v3, et fondamentalement, questions ouvertes pour la version v3 ne semblent pas être critique, surtout des vieux wishlist éléments, à mon humble avis. Depuis les dernières commettre l'activité est assez faible, je m'attends v3 version dans quelques mois, ou peut-être la moitié de l'année, mais on ne sait pas.

Emplois et IIS recyclage

Si l'application web va être organisé sous IIS, vous devez prendre en considération le recyclage/déchargement de comportement des processus de travail. L'ASP.NET web de Base application s'exécute en tant que régulier .NET de Base du processus, distinct de w3wp.exe - IIS ne sert de proxy inverse. Néanmoins, lorsqu'une instance de w3wp.exe est recyclé ou de déchargement, les .NET de Base app processus est également signalé à la sortie (selon cette).

Application Web peut aussi être auto-hébergé derrière un non-IIS reverse proxy (NGINX par exemple), mais je vais supposer que vous utilisez IIS, étroit et ma réponse en conséquence.

Les problèmes de recyclage/déchargement introduit sont bien expliqués dans le post référencé par @darin-dimitrov:

• Si par exemple, le vendredi de 9:00 le processus est en panne, parce que plusieurs heures plus tôt, il a été déchargé par IIS pour cause d'inactivité - pas admin e-mails seront envoyés jusqu'à ce que le processus est encore en hausse. Pour éviter cela, il faut configurer IIS pour minimiser décharge/recyclings (voir cette réponse).
  • De mon expérience, la configuration ci-dessus ne fonctionne toujours pas garantir à 100% que les services internet (IIS) ne jamais décharger l'application. Pour garantir à 100% que votre processus est en place, vous pouvez configurer une commande qui envoie périodiquement des demandes à votre demande, et donc le garde en vie.
• Lorsque le processus hôte recyclés et/ou de déchargement, les emplois doivent être gracieusement à l'arrêt, pour éviter la corruption des données.

Pourquoi voudriez-vous d'accueil des tâches planifiées dans une application web

Je pense justification de ceux-ci ayant courriel emplois hébergé dans une application web, malgré les problèmes énumérés ci-dessus. C'est la décision d'avoir un seul type de modèle d'application (ASP.NET). Cette approche simplifie la courbe d'apprentissage, la procédure de déploiement, suivi de production, etc.

Si vous ne voulez pas introduire backend microservices (ce qui serait un bon endroit pour déplacer la messagerie emplois), alors il est logique de surmonter IIS recyclage/déchargement des comportements et de l'exécution de Quartz à l'intérieur d'une web app.

Ou peut-être vous avez d'autres raisons.

De travail persistant magasin

Dans votre scénario, l'état de l'exécution du travail doivent être conservées en dehors du processus. Donc, par défaut RAMJobStore ne rentre pas, et vous devez utiliser le ADO.NET de Travail Magasin de.

Puisque vous avez mentionné SQL Server dans la question, je vais vous donner l'exemple de configuration pour SQL Server base de données.

Comment démarrer (et arrêter) le planificateur

Je suppose que vous utilisez Visual Studio 2017 et la dernière version récente de .NET de Base de l'outillage. La mienne l'est .NET de Base d'Exécution 1.1 et .NET SDK de Base 1.0.

Pour DB exemple de configuration, je vais utiliser une base de données nommée Quartz dans SQL Server 2016 Express LocalDB. DB scripts d'installation peut être trouvé ici.

Tout d'abord, ajouter des références de package d'application web .csproj (ou de le faire avec le gestionnaire de package NuGet GUI dans Visual Studio):

<Project Sdk="Microsoft.NET.Sdk.Web">
<!-- .... existing contents .... -->
<!-- the following ItemGroup adds required packages -->
<ItemGroup>
<PackageReference Include="Quartz" Version="3.0.0-alpha2" />
<PackageReference Include="Quartz.Serialization.Json" Version="3.0.0-alpha2" />
</ItemGroup>
</Project>

Avec l'aide de Guide De Migration et la V3 Tutoriel, nous pouvons comprendre comment démarrer et arrêter le planificateur. Je préfère pour encapsuler ce dans une catégorie distincte, soit il QuartzStartup.

using System;
using System.Collections.Specialized;
using System.Threading.Tasks;
using Quartz;
using Quartz.Impl;
namespace WebApplication1
{
//Responsible for starting and gracefully stopping the scheduler.
public class QuartzStartup
{
private IScheduler _scheduler; //after Start, and until shutdown completes, references the scheduler object
//starts the scheduler, defines the jobs and the triggers
public void Start()
{
if (_scheduler != null)
{
throw new InvalidOperationException("Already started.");
}
var properties = new NameValueCollection {
//json serialization is the one supported under .NET Core (binary isn't)
["quartz.serializer.type"] = "json",
//the following setup of job store is just for example and it didn't change from v2
["quartz.jobStore.type"] = "Quartz.Impl.AdoJobStore.JobStoreTX, Quartz",
["quartz.jobStore.useProperties"] = "false",
["quartz.jobStore.dataSource"] = "default",
["quartz.jobStore.tablePrefix"] = "QRTZ_",
["quartz.jobStore.driverDelegateType"] = "Quartz.Impl.AdoJobStore.SqlServerDelegate, Quartz",
["quartz.dataSource.default.provider"] = "SqlServer-41", //SqlServer-41 is the new provider for .NET Core
["quartz.dataSource.default.connectionString"] = @"Server=(localdb)\MSSQLLocalDB;Database=Quartz;Integrated Security=true"
};
var schedulerFactory = new StdSchedulerFactory(properties);
_scheduler = schedulerFactory.GetScheduler().Result;
_scheduler.Start().Wait();
var userEmailsJob = JobBuilder.Create<SendUserEmailsJob>()
.WithIdentity("SendUserEmails")
.Build();
var userEmailsTrigger = TriggerBuilder.Create()
.WithIdentity("UserEmailsCron")
.StartNow()
.WithCronSchedule("0 0 17 ? * MON,TUE,WED")
.Build();
_scheduler.ScheduleJob(userEmailsJob, userEmailsTrigger).Wait();
var adminEmailsJob = JobBuilder.Create<SendAdminEmailsJob>()
.WithIdentity("SendAdminEmails")
.Build();
var adminEmailsTrigger = TriggerBuilder.Create()
.WithIdentity("AdminEmailsCron")
.StartNow()
.WithCronSchedule("0 0 9 ? * THU,FRI")
.Build();
_scheduler.ScheduleJob(adminEmailsJob, adminEmailsTrigger).Wait();
}
//initiates shutdown of the scheduler, and waits until jobs exit gracefully (within allotted timeout)
public void Stop()
{
if (_scheduler == null)
{
return;
}
//give running jobs 30 sec (for example) to stop gracefully
if (_scheduler.Shutdown(waitForJobsToComplete: true).Wait(30000)) 
{
_scheduler = null;
}
else
{
//jobs didn't exit in timely fashion - log a warning...
}
}
}
}

Note 1. Dans l'exemple ci-dessus, SendUserEmailsJob et SendAdminEmailsJob sont des classes qui implémentent IJob. Le IJob interface est légèrement différente de IMyEmailService, parce qu'il renvoie void Task et pas Task<bool>. Les deux catégories d'emplois devrait obtenir IMyEmailService comme une dépendance (probablement constructeur d'injection).

Note 2. Pour un travail de longue durée pour être en mesure de sortir en temps opportun, dans le IJob.Execute méthode, il doit observer l'état de IJobExecutionContext.CancellationToken. Cela peut nécessiter le changement de IMyEmailService l'interface, pour faire ses méthodes recevoir CancellationToken paramètre:

public interface IMyEmailService
{
Task<bool> SendAdminEmails(CancellationToken cancellation);
Task<bool> SendUserEmails(CancellationToken cancellation);
}

Quand et où pour démarrer et arrêter le planificateur

Dans ASP.NET de Base, l'application code de démarrage réside dans la classe Program, un peu comme dans l'application console. Le Main méthode est appelée pour créer hôte web, lancer, et d'attendre jusqu'à la sortie:

public class Program
{
public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.UseStartup<Startup>()
.UseApplicationInsights()
.Build();
host.Run();
}
}

La chose la plus simple à faire est de simplement mettre un appel à QuartzStartup.Start droit dans le Main méthode, un peu comme comme je l'ai fait dans TL;DR Mais depuis que nous avons à traiter correctement l'arrêt de processus ainsi, je préfère le crochet à la fois le démarrage et l'arrêt de code d'une manière plus cohérente.

Cette ligne:

.UseStartup<Startup>()

se réfère à une classe nommée Startup, qui est soutenue lors de la création de nouveaux ASP.NET de Base de l'Application Web projet dans Visual Studio. Le Startup classe ressemble à ceci:

public class Startup
{
public Startup(IHostingEnvironment env)
{
//scaffolded code...
}
public IConfigurationRoot Configuration { get; }
//This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
//scaffolded code...
}
//This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
//scaffolded code...
}
}

Il est clair qu'un appel à QuartzStartup.Start doit être insérée dans une des méthodes de la Startup classe. La question est, où QuartzStartup.Stop doit être accroché.

Dans l'héritage .NET Framework, ASP.NET fourni IRegisteredObject interface. Selon ce post, et la la documentation, dans ASP.NET de Base, il a été remplacé par IApplicationLifetime. Bingo. Une instance de IApplicationLifetime peut être injecté dans Startup.Configure méthode par le biais d'un paramètre.

Pour des raisons de cohérence, je vais accrocher les deux QuartzStartup.Start et QuartzStartup.Stop à IApplicationLifetime:

public class Startup
{
//This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(
IApplicationBuilder app, 
IHostingEnvironment env, 
ILoggerFactory loggerFactory, 
IApplicationLifetime lifetime) //added this parameter
{
//the following 3 lines hook QuartzStartup into web host lifecycle
var quartz = new QuartzStartup();
lifetime.ApplicationStarted.Register(quartz.Start);
lifetime.ApplicationStopping.Register(quartz.Stop);
//.... original scaffolded code here ....
}
//....the rest of the scaffolded members ....
}

Remarque que j'ai étendu la signature de la Configure méthode avec un supplément de IApplicationLifetime paramètre. Selon la documentation, ApplicationStopping bloqué jusqu'à ce qu'rappels enregistrés sont terminés.

Arrêt normal sur IIS Express, et ASP.NET module de Base

J'ai pu observer le comportement attendu des IApplicationLifetime.ApplicationStopping crochet uniquement sur IIS, avec la dernière ASP.NET module de Base est installé. IIS Express (installé avec Visual Studio de la Collectivité en 2017 RTM), et IIS avec une version obsolète de ASP.NET module de Base n'a pas toujours invoquer IApplicationLifetime.ApplicationStopping. Je crois que c'est à cause de ce bug qui a été résolu.

Vous pouvez installer la dernière version de ASP.NET module de Base à partir d'ici. Suivez les instructions dans le "l'Installation de la dernière ASP.NET Module de Base" section.

Quartz vs FluentScheduler

J'ai aussi pris un coup d'oeil à FluentScheduler, comme il a été proposé comme une alternative de la bibliothèque par @Brice Molesti. À ma première impression, FluentScheduler est assez simpliste et immatures solution, par rapport à Quartz. Par exemple, FluentScheduler ne fournit pas ces caractéristiques fondamentales comme l'état de travail de la persistance et de cluster d'exécution.

OriginalL'auteur felix-b

En plus de @felix-b réponse. L'ajout de DI à l'emploi. Aussi QuartzStartup Commencer peut être faite async.

Basé sur cette réponse: https://stackoverflow.com/a/42158004/1235390

public class QuartzStartup 
{
public QuartzStartup(IServiceProvider serviceProvider)
{
_serviceProvider = serviceProvider;
}
public async Task Start()
{
//other code is same
_scheduler = await schedulerFactory.GetScheduler();
_scheduler.JobFactory = new JobFactory(_serviceProvider);
await _scheduler.Start();
var sampleJob = JobBuilder.Create<SampleJob>().Build();
var sampleTrigger = TriggerBuilder.Create().StartNow().WithCronSchedule("0 0/1 * * * ?").Build();
await _scheduler.ScheduleJob(sampleJob, sampleTrigger);
}
}

JobFactory classe

public class JobFactory : IJobFactory
{
private IServiceProvider _serviceProvider;
public JobFactory(IServiceProvider serviceProvider)
{
_serviceProvider = serviceProvider;
}
public IJob NewJob(TriggerFiredBundle bundle, IScheduler scheduler)
{
return _serviceProvider.GetService(bundle.JobDetail.JobType) as IJob;
}
public void ReturnJob(IJob job)
{
(job as IDisposable)?.Dispose();
}
}

Démarrage de classe:

public void ConfigureServices(IServiceCollection services)
{
//other code is removed for brevity
//need to register all JOBS by their class name
services.AddTransient<SampleJob>();
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env, IApplicationLifetime applicationLifetime)
{
var quartz = new QuartzStartup(_services.BuildServiceProvider());
applicationLifetime.ApplicationStarted.Register(() => quartz.Start());
applicationLifetime.ApplicationStopping.Register(quartz.Stop);
//other code removed for brevity
}

SampleJob de la classe avec le constructeur de l'injection de dépendances:

public class SampleJob : IJob
{
private readonly ILogger<SampleJob> _logger;
public SampleJob(ILogger<SampleJob> logger)
{
_logger = logger;
}
public async Task Execute(IJobExecutionContext context)
{
_logger.LogDebug("Execute called");
}
}

OriginalL'auteur aleha