Intelligent Design : DataExchange

Fellowship One APIs - Past, Present, and Future

FTProductDev — Wed, 25 Feb 2009 22:42:00 GMT

With the up coming Fellowship One RESTful API we wanted to take the some time and look back on our other two APIs and reflect on what we intended them to be and what they actually became. We looked at the their interfaces, authentication, resources, versioning, protocols, logging mechanisms, "debuggability", etc... What we found out was that in the world of "API" nothing ever ends up like you intend.

Fellowship One Data Exchange: A very powerful XML RPC API that was specifically designed to address massive data import and export needs. It's ridged pinpoint interface allow users to build simple data presses, which move large amounts of data between disparate systems. A few years into the product's life we introduced the ability to do synchronous transactions - a decision that completely changed many consumer's usage patterns.

Serendipity stepped in and instantly consumers began to use this brute force application on websites to perform anything from profile updates to seamless login patterns. After seeing how much the community found value in the login metaphor we've published docs and given presentations on the best practices of this approach. We now have 3rd parties writing web applications and hosting web sites that do a myriad of things.

Being a SOAP based .NET web service, consuming Data Exchange required the language to either have a library that constructs SOAP envelopes or that the developer understand that protocol and be able to construct a SOAP message manually.

Another characteristic of this API are the logging and response mechanisms; both were intended to only be used / interpreted by the consuming application. Its authentication is based on simple credential / key maps.

Fellowship One Payment Gateway: A .NET SOAP based web service that gives churches the ability to submit giving / e-commerce transactions. The interesting thing about this service is that it was originally developed for internal consumption only and later opened up to external consumers for book stores, tithe applications, etc... another decision point that changed the way an established API was used.

Payment Gateway answered a changeling question of: "how do I get all of my billing and payments to go through one channel and be able to report on the transactions going through that channel?" Much like Data Exchange, we saw it consumed in ways we couldn't have imagined.

We used credential and signed key authentication for this API.

Fellowship One RESTful API: A REST based web application that uses several open protocols and patterns to provide consumers access to secure resources.

STANDARDS, PROTOCOLS, and PATTERNS - nothing else. Looking back, we could see where their is major value in sticking with something that is "tried and true." If we could use web based patterns and protocols for a web based API we could not only get instant adoption but gain the efficiencies and effectiveness of technologies that "just work."

This next generation of API is, ironically based on foundations that have been in place for years. We chose MVC as the application architecture, OAUTH protocol for Authentication, REST and HTTP 1.1 as the transport. This API should give web developers an tool where all they have to think about is what to do with the resources.

Thank you for partnering with us over the years; we have a lot of fun stuff up ahead and we hope to see you at the Dev track @ DC09!

Hang with the Developers of Fellowship Technologies @ DC08

FTProductDev — Tue, 29 Apr 2008 17:32:00 GMT

The Development team here @ Fellowship Technologies wants to meet you @ Dynamic Church 08. We want get to know the men and women behind the screens. We've planned a few things so that we can connect with you and talk shop as well as get together for some fun time - why waste time sleeping.

Developers and non developers are welcome. Here's the schedule:

Thursday 15^th

200pm – Presentation(Rockhill) – Network Infrastructure (drez)

500pm – Presentation(Frisco 3) – Moving to REST (nfloyd)

- RESTing DEV

o Handout public keys and private secrets to all devs attending so that you can test drive the new API.

500pm – Presentation(Rockhill) – Leverage DataExchange(csimmons)

630-800pm - Group dinner – Dinner with dev - look for the tables marked "DEV" (probably in the back, away from the "normal" people)

900pm - Movie with Dev – just another opportunity to interact with other devs in an environment that we are comfortable where we don’t have to talk shop if we don’t want to.

Friday 16^th

1100am – Presentation(Rockhill) – Inside FT (drez)

1200-100pm – Birds of a feather lunch (We will be sitting @ the tables marked IT)

100pm – Presentation(Frisco 5) - Content Management (thardy)

230pm – Presentation(Rockhill) – Customizing Weblink(tcoulson)

730-930pm Concert

1000pm – Gaming with Dev – Go up against and talk trash to the Fellowship Technologies Devs in TF2. You don't want to miss this...

Saturday 17^th

1000-1200pm - Ask the experts (Frisco 5)

1. API 3 person panel discussion and questions with laptops open showing the code for the new RESTful API

2. Developers – Interact with the team responsible for building Fellowship One

Contact me with questions and let us know if we're going to see ya.

--Nick (nfloyd@fellowshiptech.com)

Sorry about the Smoke and Mirrors

nfloyd — Sun, 20 May 2007 18:36:00 GMT

So, during my presentation @ DC07 - Consuming DataExchange, I used a mobile device, outlook, and a check in printer in a demo on “thinking forward” and outside of the norm on DataExchange. While I had all of my plates spinning I plowed through the demo without explaining the code and technology behind it… for all of those who have forgiven me ;) here ya go:

What I used:

1 x Cingular HTC 8525 w/WM6 + Push synchronization

1 x Exchange Mail Server

1 x Instance of Outlook 2007

1 x Microsoft OfficeXP WebServices Toolkit 2.0 (So that my VBA could talk to DataExchange)

1 x Redemption (3^rd party freeware that suppressed security warnings – I did not want to disrupt the demo with having to click a dialog box)

1 x Check in Printer

This is what I did:

I walked up to Andrew Mitry and Bob VanDerPloeg (of Discovery Church) told them some scenario that I was part of the first time visitors ministry and wanted to talk to them because they were new to my church – I recorded their First and Last names as well as their Phone numbers (note: I could’ve captured their email, address, spouse – to generate another individual, children, etc….).

While I was entering Bob’s information into my HTC Andrew’s information was being pushed to our exchange server – synchronization happens automatically on my device, though you could schedule it for every minute or something more appropriate.

Once the information hit our exchange server my outlook client pulled down the new information into my contacts folder. I had the following script setup to run each time a new contact arrived during my session:

'==================================================

'ExportContacts(oiContact As ContactItem)

' This sub handles the following

' Create a safe object to avoid security warnings - see (http://www.dimastr.com/redemption/) for more information

' Create XML based on the new contact

' Send XML to the DataExchange web service

' Notify the user

'==================================================

Private Sub ExportContacts(oiContact As ContactItem)

On Error Resume Next

Dim sXML As String

Dim SafeContact

Set SafeContact = CreateObject("Redemption.SafeContactItem")

SafeContact.Item = oiContact

sXML = "<?xml version='1.0' encoding='UTF-8'?>"

sXML = sXML + "<tns:dataRequest xmlns:tns='UpdateHousehold'>"

sXML = sXML + " <authenticateHeader>"

sXML = sXML + " <churchCode>[ChurchCode] </churchCode>"

sXML = sXML + " <user>[USERID]</user>"

sXML = sXML + " <password>[PASSWORD] </password>"

sXML = sXML + " <method>UpdateHousehold</method>"

sXML = sXML + " <version>2.0</version>"

sXML = sXML + " <methodGroup>People</methodGroup>"

sXML = sXML + " </authenticateHeader>"

sXML = sXML + " <configuration>"

sXML = sXML + " <requestProcessType>Synchronous</requestProcessType>"

sXML = sXML + " </configuration>"

sXML = sXML + " <data>"

sXML = sXML + " <household entityState='Added'>"

sXML = sXML + " <householdName>" + SafeContact.FirstName + " " + SafeContact.LastName + "</householdName>"

sXML = sXML + " <addresses/>"

sXML = sXML + " <communications/>"

sXML = sXML + " <individuals>"

sXML = sXML + " <individual entityState='Added'>"

sXML = sXML + " <title/>"

sXML = sXML + " <salutation/>"

sXML = sXML + " <prefix/>"

sXML = sXML + " <firstName>" + SafeContact.FirstName + "</firstName>"

sXML = sXML + " <lastName>" + SafeContact.LastName + "</lastName>"

sXML = sXML + " <suffix/>"

sXML = sXML + " <middleName/>"

sXML = sXML + " <goesByName/>"

sXML = sXML + " <formerName/>"

sXML = sXML + " <gender/>"

If Len(SafeContact.Birthday) <> 0 Then

sXML = sXML + " <dateOfBirth>" + SafeContact.Birthday + "</dateOfBirth>"

Else

sXML = sXML + " <dateOfBirth/>"

End If

sXML = sXML + " <maritalStatus/>"

sXML = sXML + " <householdMemberType>Head</householdMemberType>"

sXML = sXML + " <occupation/>"

sXML = sXML + " <occupationDescription/>"

sXML = sXML + " <employer/>"

sXML = sXML + " <school/>"

sXML = sXML + " <formerChurch/>"

sXML = sXML + " <status>New from Mobile</status>"

sXML = sXML + " <weblink entityState='UnChanged'>"

sXML = sXML + " <userId/>"

sXML = sXML + " <password/>"

sXML = sXML + " <passwordHint/>"

sXML = sXML + " <passwordAnswer/>"

sXML = sXML + " </weblink>"

sXML = sXML + " <attributes/>"

If Len(SafeContact.HomeAddress) <> 0 Then

sXML = sXML + " <addresses>"

sXML = sXML + " <address entityState='Added'>"

sXML = sXML + " <addressType>Primary</addressType>"

sXML = sXML + " <address1>" + SafeContact.HomeAddressStreet + "</address1>"

sXML = sXML + " <address2/>"

sXML = sXML + " <city>" + SafeContact.HomeAddressCity + "</city>"

sXML = sXML + " <postalCode>" + SafeContact.HomeAddressPostalCode + "</postalCode>"

sXML = sXML + " <country>USA</country>"

sXML = sXML + " <stProvince>" + UCase(SafeContact.HomeAddressState) + "</stProvince>"

sXML = sXML + " </address>"

sXML = sXML + " </addresses>"

Else

sXML = sXML + " <addresses/>"

End If

sXML = sXML + " <communications>"

If Len(SafeContact.Email1Address) <> 0 Then

sXML = sXML + " <communication entityState='Added'>"

sXML = sXML + " <communicationType>Email</communicationType>"

sXML = sXML + " <communicationValue>" + SafeContact.Email1Address + "</communicationValue>"

sXML = sXML + " <listed>true</listed>"

sXML = sXML + " </communication>"

End If

If Len(oiContact.HomeTelephoneNumber) <> 0 Then

sXML = sXML + " <communication entityState='Added'>"

sXML = sXML + " <communicationType>Home Phone</communicationType>"

sXML = sXML + " <communicationValue>" + SafeContact.HomeTelephoneNumber + "</communicationValue>"

sXML = sXML + " <listed>true</listed>"

sXML = sXML + " </communication>"

End If

sXML = sXML + " </communications>"

sXML = sXML + " </individual>"

sXML = sXML + " </individuals>"

sXML = sXML + " </household>"

sXML = sXML + " </data>"

sXML = sXML + " </tns:dataRequest>"

'Call the Web Service - See Class Module - clsws_DataRequest for more information

CallDataExchangeWebMethod sXML

MsgBox "Contact Exported..."

End Sub

The function CallDataExchangeWebMethod would send the information to DataExchange. DataExchange would then synchronously store the data into the Database, making it instantly available to check in and all of the other applications that use the same data store…ta-da!

Sorry again for not going more in depth during the demo, I had a bit too much Monster Java energy drink that morning and was moving @ light-speed. Thanks again to all who were able to make it to the DataExchange sessions – remember think “Why Not”!

--Nick

DataExchange API - Connect with people not just systems

nfloyd — Fri, 10 Nov 2006 05:08:00 GMT

You know that little link at the bottom of most content driven sites – the one labeled “Developers.” Perhaps it’s a link to a doc, code samples, or some type of instructional repository. How it is represented is really inconsequential, the real meat behind the link is what it means to the community it is meant for and to the team that developed what's behind it.

I am talking about APIs (Application Programming Interface); the software world is filled with them – Ebay, Google, Facebook, PlayStation 3, etc… As a developer I seek out access to the semi-elusive underworld of APIs. This is a place to come and see a Developer wear his code on his sleeve, a community of bashes and praises, a smelting pot of homegrown solutions shared with others inspired by the absence of glass ceilings.

The term and its functionality ring a blissful freedom. How ambiguous is the definition: “the interface that a computer system, library or application provides in order to allow requests for services to be made of it by other computer programs, and/or to allow data to be exchanged between them (Provided by: wiki)." Although it does not roll off the tongue this definition speaks volumes about this technology’s design model – there isn’t one. Well not just one, but many.

After writing the FellowhipOne DataExchange API I found that I was asked more questions on the design model than on the consumer implementation. I would feed out some garbled techno-babble stating that it was built loosely on a RESTful implementation, that it was strictly XML based with various security patterns and object models that allowed the flexibility of versioning and full backwards compatibility, etc… but it was so much more than that…

I have met some of the most talented, most experienced, and most interesting people through DataExchange – The developers that use it; they were the ones that really built it. Providing challenges and problems to solve – I love the Church DEV community! Colossians 3:23 until the end.

The definition for API is not at all like the one above - in my opinion. I would like to think it is more like:
APIs (Association Producing Interchange): "The interface that a community of developers uses to collaborate, innovate, and build on ideas to change and invigorate a software experience." We have a unique opportunity as developers; we can come together using our various backgrounds and knowledge to make a really great "something" - but we have to connect with people not just systems.