oData Support

Kanwei Li
Kanwei Li
Sixth Anniversary Facilitator 1
in Blackbaud Raiser's Edge NXT®: General Discussions
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?






 

Comments

  • Kanwei Li
    Kanwei Li
    Sixth Anniversary Facilitator 1
    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).


     
  • Aidan Lambert
    Aidan Lambert
    Third Anniversary Kudos 1 Name Dropper Participant

    I'm far from an expert on this, but having poked around this issue before I can tell you what I gathered:

    If you store your database locally, this is doable. Do some google searching and you should be able to find a couple community posts about it. But if you're hosted with BB, this is something that was a feature, but BB decided to stop allowing for security reasons (there was a data breach a few years ago). The only option I've been able to find for accessing hosted data is through the API endpoints.

    I don't know if they're working on finding a way to reinstate this feature securely or not, but I agree that oData would be far more resource and time efficient.

Categories