MSDN Webcast: Project Server Events and Workflows, Demos & Q&A

Hi All,

Thank you for attending my MSDN webcast Project Server Events and Workflows. Don’t forget about next weeks webcast on Project Client programmability. Below is some of the Q&A I got during the webcast. Attached is the demos from the webcast.

Question	Answer
Will you chat at all about Project Server 2010? Are there any plans for changes in the new version?	Still too early to talk about Project Server 2010 other than to to say I’m looking forward to it. We’re a few months away from announcing the features. What should you be thinking about as a developer? Project is committed to the PSI and designed it to be extensible. The new functionality will be extensions to existing functionality. This means your work today should be backward compatible. I did say should so please don’t shoot me if there are a couple “gotchas.”
Is the command (i.e save project) already queued, when an event is raised?	The event will be raised when the call executes from the queue.
Based on your description of pre and post, the "project published" event is raised after save to the db. Would you say its best to eval business rules afterward, log violations, notify user and delete from db? is there an ability to only delete from PDB and leave in DDB so user can correct and attempt re-publish?	I hate to waffle in my answers, but in this case it depends on the context. I put together a little matrix below to help with this question.
Is it microsoft.office.project.schema.dll or microsoft.office.project.server.schema.dll?	microsoft.office.project.schema.dll is the correct DLL.
Is there anything to pay special attention for (i.e. concurrency, locking, etc.) with events on heavy loaded systems or is this solved by "serialized" execution through the project server queue?	The queue helps to solve issues with heavily loaded systems. Specifically with events you need to pay attention to the length of processing in pre-events. In a pre-event you are disrupting the flow of Project Server, you should keep your processing to a minimum.

Using events to enforce business rules

	Easy Rollback	Difficult Rollback
Short Business Rule Evaluation	Evaluate in pre-event, rollback unnecessary.	Evaluate in pre-event, rollback unnecessary.
Long Business Rule Evaluation	Consider using a post event.	This is the hardest case. You’ll really need to evaluate the complexity of the rollback. Maybe you could break the business rule evaluation in phases?