Experience.FellowshipOne.com

I know there are a million people to ask, but I dig this forum.  It's pretty cool.

I am wondering just how flexible XML/Data Exchange is.  I am a versed PHP programmer.  What all I can I do in Fellowship One by using XML or data exchange.  Can I query, insert and update so that I could have some cool interfaces, like an interface for a volunteer altar worker to enter a form...

Totally new to Fellowship One.

Is there any FT Staff who know if there are any plans related to Data Exchange?

It would be great, but I also understand the limited power that can / cannot be given to make direct access to tables and database relationships.

collinglover

Thanks for your interest in DataExchange!  When we originally architected DataExchange a few years ago we wanted to create an API that would be easy to use yet extensible while still being able to grow organically via input from churches.  One thing I have learned is that the Church community has many bright individuals who tend to think way outside of their technology boxes. 

A very cool aspect of DataExchange is that it was developed with a base set of constraints which included using a platform / language independent transport mechanism (XML over HTTPs) - everything else came from "Wouldn't it be cool ifs" and "Can DataExchange dos" from the community.  I could go on about how great the feedback and ideas have been but I think you would appreciate some real world examples instead of my babble:

1.  We had a user successfully integrate ESRI’s mapping technology and DateExchange to help his pastor understand where members live in relation to visitors, etc…

2.  For non-collection methods (such as UpdateIndividual or UpdateHousehold) you can choose how the update is processed - synchronously or asynchronously.  You can integrate DataExchange with your existing website by providing users a real-time login mechanism in addition to providing them with the ability to update the personal information.

3.  What about an online book store?  We currently have several churches using DataExchange in combination with our Payment Gateway API to process transactions and associate then with existing individuals in Fellowship One.

I could go on, but I want to point out that mspidle is correct, even though you can query on and update just about every piece of information on households and individuals, the depth of the API does not yet extend much past those entities.  With that said, you make a very important point – the Data model is very complex and often time does not lend itself to extension outside of the application it was architected for -  though possible it may not be practical.  The difference between data and information can sometimes be a hard line, especially when it comes to how to flex that data model outside of a controlled environment.

One of the most powerful aspects of DataExchange is that is it extremely extensible - meaning that other entities can be snapped into it without breaking any interfaces and allowing you the greatest access to your data. When designing DataExchange, we based it on some of the principles of other popular RESTful architectures so the requests will always be structured the same; it's the content of that request that will change.

As for plans of future development... The following is something I said while speaking with a Church about DataExchange:

"Individuals like you are what make functionality like DataExchange awesome.  Your desire to make church better drives our desire to enable you to do just that.  Your thoughts, feedback, questions, and ideas live in FellowshipOne - not just in my inbox or your head. I look forward to hearing your feedback, and I thank you for helping us enhance these tools."

We want DataExchange to be a "community thing."  We still have our project plans and our agile way of doing things - but the deep passion is in the user's hands and in the hearts of the developers – a smelting pot of functional ideas.  I look forward to hearing your feedback, and I thank you for helping us enhance these tools.

Nick,

Could you or someone else share with the community what the project plans are for DE? This would help us understand where you are planning to go currently, as well as give us an opportunity to comment and make suggestions before you start development.

The roadmap plans for DE remain open. Our roadmap for all of our products are driven by our customer base. The most popular requests for DE are Attendance and Contributions data.  Both are considered non-trivial but for different reasons. Attendance retrieval would be fairly straightforward but posting attendance could be failry complex as you would need to understand and traverse the Activity hierarchy to post the attendance data to the proper Activity, Room/Location/Class, Schedule, etc.  You would also need to understand if that was a Participant, a Staff Person, etc.  Just some thoughts off the top of my head.  The Contributions data is problematic only from the perspective of security. Granted, only someone with F1 Administrative rights should be given access to use DE.  But the sensitive data contained within the Giving records has brought to bear additional questions about if additional security checks should be required.  I'd like to hear your thoughts, and others, on where you feel we should head next with DE.

 Curtis Simons