oData Support

Kanwei Li

Greetings - I know it's not on the roadmap at the moment, but has there been any interest in oData support for the Blackbaud Sky API?  Something like this will be particularly useful for generating custom queries. 


Currently, our system queries the gift endpoint to get a collection of gifts.  Then, for each gift, we query the constituent endpoint to see if that particular gift is from an individual.  Then, we query the campaign endpoint to learn more about the gift's campaign.  We cache campaigns on our server so that we don't have to re-query the database.  While all of it is doable, it's sort of inefficient and limits the scope of the service that we can offer our customers.


What I love about odata is that we can write url queries to get exactly what we need, in one call.  The efficiency gains from doing something like this can allow us to broaden the scope of the service that we offer to customers and reduce server load (both on your end and our end).


What's even more awesome is that the underlying databases appear to be SQL server databases, so providing an oData service seems totally doable via Link to Entities, .Net's oData controller, and a configuration file that limits the scope of the services offered by oData.  That seems to be a big payoff without having to write too much code (since Microsoft did that).  To start with, perhaps that config file can limit the service to GET requests on certain entities and only join tables via indexed fields.  Sounds reasonable.


Any thoughts or interest in oData?






 

Kanwei Li

Greetings friends - just wanted to follow up.  I keep thinking about this oData idea, and I came across a blog post that may describe the benefits more accurately.


The cool thing about oData is that you can control which features are turned on. So if you don't want users to write a bad oData query on an unindexed field (for performance reasons), you can include that in the odata configuration like this (pseudocode):

var entityTypeConfig = builder.EntitySet<SomeType>("SomeType").EntityType;<br/>entityTypeConfig.Property(x => x.SomeField);<br/>entityTypeConfig.Property(x => x.SomeField2).IsNotFilterable().IsNonFilterable();

At the minimum, we'd only need oData navigation properties that link specific objects (eg. gifts->constituent->constituents->constituentcodes, gift->gift code), so that we don't have to make a lot of https get requests on a per/gift basis, so you can really limit the features in a beta v1 release. 


I think something like this will result in more feature-rich integrations for all of your partners with a huge performance boost (on your servers and ours).