PSI: Filter constraints and escaping the recursive event handler

A couple of topics that have come up through support incidents and comments posted here.  The first on the use of the filter or xmlFilter parameters available in a few of the web services, and the second talking about event handlers and what happens if you fire an event based on Check-In that then issues a check-in – how do you break the loop?


The SDK details how the xmlFilter parameter can be used to filter the returned dataset and the sample code covers the CustomFields dataset.  However there are a couple of limitations that you should be aware of.  You can use the PSLibrary.Filter.Fields.Add to control the columns returned in the dataset and PSLibrary.Filter.Criteria to control the rows.  The criteria can only be used against the main tables of the dataset and cannot be used to filter rows in the secondary datasets.  For example the Resource web service has the ResourceDataSet which contains the ResourcesDataTable as the main datatable and also several others including the ResourceAvailabilityDataTable.  Only rows in the ResourcesDataTable can be filtered using criteria. You will get a ResourceFilterInvalid Exception (or CalendarFilterInvalid exception if you try to use criteria on CalendarExceptionsDataTable of the Calendar web service).  This should be fairly obvious as the construction for the criteria does not allow for a specific DataTable to be referenced.  The other limitation is less obvious and will be corrected in our documentation shortly.  The ResourceCustomFieldsDataTable cannot be filtered at all using the filter parameter – you will get a ResourceFilterInvalid exception.  In both cases you can of course use filter on the client once you have the full dataset returned.  Another option would be to create your own PSIExtension that does the extra filter and keep everything server side.

Recursive Event Handlers

I addressed this question from a comment but might be useful for a full posting.  So if as part of your workflow you have an event handler for check-in, and when it fires you need to update something in the project then you will also need to check-in when you have finished, which will then fire the event handler and so on.  The best way I could think of to break the circle is to set a specific string as the session description when you use the check-in in your event handler.  Then you can check in your code before checking out if the sessions description in the project dataset is the one for your event handler – or a user session description which will be of the format machinenamepwa_account.  If it is your setting then no need to continue.  If anyone has a better way then please share.

Technorati Tags: Project Server 2007