Experience.FellowshipOne.com

We've started the process of integrating F1 into a new Ruby on Rails rebuild of a site. From what I read/tried, the F1 Data Exchange API didn't allow RESTful account creation, editing, or tithing. These are all requirements for us to do seamlessly from the site website, with no pop-ups.

To achieve this, we're using Ruby WWW::Mechanize through scRUBYt. This allows a fairly pretty scrape to take place between our site and F1 Weblink. The site forms will authenticate against F1 as needed for each task behind the scenes, and display the results/errors/status messages back to the client. The user will remain logged in locally, and the system will log them in/out of F1 for each request rather than saving the session info since there will typically only be 1 or 2 F1 tasks that the user will do per session. This way there's no popups, and if the bridge ever breaks or the F1 site changes, it will gracefully fall-back to local authentication, disable any F1 interaction, and notify us to find and fix the issue(s).

Is anyone else doing something similar? Is the API someday going to be able to handle these more in-depth type tasks? It's certainly not the easiest work, but it's about 50% complete and going well.

-- Jeff
 

Hi Jeff,

My name is Matt Vasquez and I'm a dev at Fellowship Technologies.  I also do Ruby on Rails development outside of my work here at FT.  You are correct that Data Exchange is not a RESTful api.  I would contest that Data Exchange is not a good candidate for integrating into your website, mainly because it is not transactional.  Data Exchange was designed to handle heavy-lifting scenarios (inserting and updating a lot of data at once).  That is why we provide a view into the Data Exchange queue from within portal.  And the reason why it is implemented as a pinhole api (actions are passed as part of the XML payload).  I would actually caution against using WWW::Mechanize to consume WebLink.  Although perfectly valid, any changes we make to WebLink will break your functionality.  Affecting your users until you can get a fix in place.  We have plans (hopes) to create a consumable API more suited for RESTful interaction and more transactional in nature.  We'd love(!) to hear your opinions of what should be exposed through a v1 api.  Feel free to ask any questions you want and I'll try to answer them.

Hey Jeff,

 Matt's right, when we originally architected DataExchange a few years ago our intent was to fulfill the need for mass data imports.  DataExchange is in fact transactional; supporting both asynchronous and synchronous transactions - with real-time feedback.  It implements an abstraction layer to avoid breaking implemented interfaces and to help with extensibility / scalability.  The abstraction layer also allows you to be able to choose what data points you want and those that you do not (likewise with updates - you choose what you update) - to minimize the amount of data being sent over the wire. 

The queue found in the portal is really for devs to come and experiment with the different mechanisms of the API or analyze the different results of their queries. 

We have a few hundred churches currently consuming DataExchange for their live website - replacing our individual / household, login, account creation, etc... modules provided via weblink.  

Please feel free to contact me if you have any questions regarding the DataExchange API as well.

--Nick Floyd (nfloyd@fellowshiptech.com)

Thanks for both of the responses,

"The queue found in the portal is really for devs to come and experiment with the different mechanisms of the API or analyze the different results of their queries. "

How can I find out more about the portal? Would that be something that the F1 admins at the church would have access to or know more about?

 "I would actually caution against using WWW::Mechanize to consume WebLink..."

I totally agree, scraping is the absolute worst way to do it, I just don't currently have a better way, and we're building the logic to fail gracefully so that the users are minimally affected if/when you change the weblink fields, etc.

Here's what we are specifically interacting with F1 for:

• Registering a new F1 account
• Editing an existing F1 account
• Getting tithing reports
• Submitting a tithe
• One-time authentication

This is a short-term project that will be deliverable within the next 3 weeks. Let me know a) if there is a better way to implement the above interactions without popups, and b) if not then if it sounds like a reasonable upgrade in the future. And if the queue/portal is a good place to play with the existing tools, then I'm interested in finding out more about it.