Intermediate or not?

Nov 23, 2009 at 11:10 AM
Edited Nov 24, 2009 at 6:18 AM


I spoke to Christophe Fiessinger last week at the Project 2010 Ignite Training in Paris, and he told me that his component supports two scenarios.
Either the eventhandler communicates directly with the API to update the status "synchronously", or via an intermediate datatable which is regularly being checked by a windows service that in turn updates the status.

Based on your project description I assume your project supports the latter scenario, or do you provide the option of a "direct update" as well?
(I'm aware of the fact that you'll be using a Sharepoint Timer Job instead of a windows service).

Could you please elaborate on why you decided to go for the intermediate-table approach?
I guess this has to do with scalability, and how many users you design the solution for...? 

I'm asking because I have to decide whether to use the eventhandler that Chrisfie has developed, or wait for your release.


Dec 3, 2009 at 8:46 PM


I apologize for the delay in responding to your inquiry.

You are correct -- ASP uses an intermediate data table in the Reporting Database as a "queue". However, the interval used for the timer service is configurable -- the default is to execute the job every minute.

I decided on this architecture for two reasons:

  • Scalability
  • Reliability

In terms of scalability, I wanted to provide a solution that was highly scalable. Several of my beta testers are using ASP in environments that support 100-300 users with no reported issues.

As far as reliability goes, I was primarily concerned with ensuring that if something goes wrong during the synchronization process that the data could later be recovered with minimal impact on users. For example, if I were using a pure synchronous architecture, if the status update failed for some reason the user would need to resubmit/approve/save their timesheet in order to trigger the synchronization. With a "queue" architecture, a row is written into the "queue" table when the user submits/approves/saves their timesheet, and this data is picked up by the Timer Job for importation into a Status Update. If for some reason the Status Update fails (e.g., timer job fails to run, bug), the update data is still stored within the database. Once the timer job is able to successfully execute, this data will be picked up and imported.

I hope this answers your question -- if not, please feel free to post a followup!


Dec 16, 2009 at 10:06 AM

Hi Steve!

Thanks for your response - and yes, that answered my question!  :)