Insight

Insight from Agora Consultants

Project Online Event Receivers

A big change from Project Server on premises installs is that event handlers are no longer DLLs that you register on the app server. For project online, event receivers must call a public facing web service to process requests. We will look at the challenges we faced implementing this approach for a Project Created event.

No Documentation

There is little documentation on Event Receivers and how to set them up. All of the information on Project Server events (in terms of the method names to override and the parameter types expected) were gathered by looking through the Microsoft.ProjectServer.Client dll and finding the appropriate objects. If you recall, an event handler needs to override the targeted event method and accept various parameters.

What we discovered was we needed a reference to Microsoft.ProjectServer.Client in our web service in order to access the parent “ProjectEventReceiver” class and override the “OnCreatingRemote” event.

This was eventually classified as a typical challenge of developing for a new product which is partially true, but a little guidance would have saved some time.

No Registration UI

That’s right. There is no administration UI in Project Online or SharePoint Online Administration by which a user can add/remove event receivers. When we discovered this we were surprised to say the least. We thought that maybe event receivers were not yet working in Project Online, but no documentation seemed to back up our suspicion.

This prompted us to head back into the Microsoft.ProjectServer.Client assembly to figure out how events are actually registered. After some digging, we did find an object “EventHandlerCreationInformation” which seemed to be the object we were looking for. This is how you register an event in Project Online:

Now every time we need to manage event receivers in the cloud we have to run a piece of code, which meant we needed to build a registration UI. So we created a simple windows application which can read/manage events on an online tenant. Consider this as well: almost 90% of the time a call to register/unregister an event fails with a timeout error. BUT, when we read the event status, the event is actually registered! It seems the action to register/unregister is completed in the cloud, the call just never returns.

That leads us to…

Slow Performance

Event receivers are extremely slow. It is common sense to realize that calling an external web service when an event occurs (such as project creation) will slow down the process a bit, but the event receiver times out making the process fail.

We ran a few tests creating projects with our event receiver attached. Our web service logged when it was executed (when the request started and when it finished) to determine if the delay was caused by our code or some other part of the process. 

It wasn’t our code. 

The web service consistently completed the request between 1-3 seconds, but Project online would keep spinning. The system was unusable, and frequently project creation would just stop because it was waiting for the event to complete.

That leads us to…

Error Handling

If an event receiver times out, the action does not complete. If the server on which the web service is hosted is not available, the action does not complete. So in a case of a mysterious timeout (mentioned in the previous section) or a server failure, projects will not be created. A better alternative would be to allow the project creation process to continue regardless of the result of an event receiver. The risk of installing such a feature is too high for any admin to take.

Unreliable = Not a Solution

While the lack of documentation and a registration UI can be tackled with development knowledge and code, the slow performance and error handling make Project Online event receivers an unusable technology. If you are contemplating a solution design that requires an event receiver save yourself the time and money by coming up with another idea. I only hope that more patches and releases to the Project Online environment will fix this behaviour in the future. 



 
Comments are closed