système de rendez-vous récurrents-Design Guidance

Question

Nous avons un scénario dans lequel l'utilisateur peut créer des tâches récurrentes. La tâche récurrente peut être de n'importe quel type, comme envoyer périodiquement des rapports à ce client le 1er de chaque mois, traiter la facture tous les lundis. Toutes ces tâches sont spécifiques à l'application (pas spécifique à l'utilisateur) et peuvent également être consultées par mes autres utilisateurs. Pour répondre à ce besoin, nous créons des rendez-vous pour chaque tâche dans les perspectives, ce qui nous permet de trouver la prochaine date d'exécution du rendez-vous. Nous avons un Service en cours d'exécution sur le serveur et tous les rendez-vous sont créés sur le client Outlook installé sur le serveur. Maintenant j'ai quelques doutes sur cette implémentation.

1) Le client Outlook supportera-t-il le multi-threading? Coz plusieurs threads du pool de threads peuvent accéder au client?

2) La seule raison d'aller avec le client Outlook est de trouver la prochaine date d'exécution. Nous avons pensé à résoudre ce problème par nous-mêmes, mais il y avait beaucoup de cas à traiter. Existe-t-il un outil ou un composant tiers qui répondra à nos besoins? Notre composant serveur est écrit en C#.

Answer 1

Je ne pense pas que Outlook supportera votre scénario multithread.

iCalendar est une spécification normalisée (RFC 2445) pour la création, la persistance et le transfert d'informations de calendrier. De nombreuses applications de calendrier utilisent cette norme pour l'importation et l'exportation entre d'autres clients (y compris une implémentation dans Outlook).

J'utilise une implémentation .NET open source créée par Douglas Day, qui est available here pour gérer les événements récurrents dans mes applications. Il semble que vous n'ayez besoin que d'un très petit sous-ensemble de la fonctionnalité, mais tout le travail a été fait en termes de gestion de la gamme complète des modèles de récurrence complexes, et trouver la prochaine occurrence est trivial. Les données d'événement sont entièrement sérialisables, ce qui vous permet de les conserver dans des fichiers plats ou dans une base de données relationnelle. Vous pouvez également importer des événements dans Outlook ou dans d'autres applications si vous le souhaitez. La partie la plus difficile est de vous familiariser avec le modèle d'objet, mais compte tenu d'un pic court, vous serez bientôt opérationnel et vous n'aurez plus à faire quoi que ce soit d'interopérable Office sur le serveur.

C'est juste une option que j'ai utilisée dans le passé; il y a sans aucun doute d'autres façons d'y aller, mais dans tous les cas, je resterais loin de garder les événements d'application dans une instance en cours d'exécution d'Outlook sur le serveur, en particulier avec un accès asynchrone.

Answer 2

La meilleure solution que j'ai trouvée jusqu'à présent est d'utiliser l'expression de Cron. Il existe deux composants disponibles pour NET Framework

• Ncron
• Cron Expression Descriptor