recurring appointment system-Design Guidance

Question

Hi, We got a scenario where user can create recurring tasks. The recurring task can be of any type, like periodically send reports to this customer on 1st of everymonth, process invoice on every Monday. All these tasks are application specific(not user specific) and can be seen my other users as well. To cater this need, we are creating appointments for each task in the outlook, this enables us to find the next appointment execution date. We got a Service running on the server and all the appointments are created on the outlook client installed in the server. Now I got few doubts about this implementation.

1) Will the outlook client will support multi-threading? Coz several threads from thread pool can access the client?

2) The sole reason for going with outlook client is to find the next execution date. We thought of solving this problem on our own, but there were plenty of end cases to address. Are there any third party tool or component which will address our need. Our server component is written in c#.

Answer 1

I do not think Outlook will support your multithreaded scenario.

iCalendar is a standardized specification (RFC 2445) for creating, persisting, and transferring calendaring information. Many calendar applications use this standard for importing and exporting among other clients (including an implementation in Outlook).

I use an open source .NET implementation created by Douglas Day, which is available here to manage recurring events in my applications. It sounds like you'll need only a very small subset of the functionality, but all the work has been done in terms of handling the full gamut of complex recurrence patterns, and finding the next occurrence is trivial. Event data is fully serializable, so you can persist them in flat files or a relational database, and you get the added benefit of being able to import events into Outlook or other applications if you ever wanted to provide that.

The hardest part is familiarizing yourself with the object model, but given a short spike you'll soon be off and running and won't have to do any of that nasty Office interop on the server.

That is just one option that I've used in the past; there are undoubtedly other ways to go, but in any event I'd stay away from keeping the application events in a running instance of Outlook on the server, particularly with asynchronous access.