BACKGROUND
Every so often myself or Jon will get a batch of emails asking for the latest
status on the Salesforce Connector, since our grant from the Salesforce.com
foundation was originally announced in 2006. They always come
in groups.
Externally, the product has shown little sign of movement for those that
don’t scour (and perhaps do…) the Collective Checkins list, which
can be a great way to gauge what’s active in the Plone community.
As a way to respond to those that have asked or are curious, I plan to post a
series of several blog posts on The Plone Blog updating everyone on the latest.
Overall, the progress has been slow and arduous, but there have been a ton of
rewarding and committed conversations and discussion with the crew of us up in
Seattle (includes the talented Brian Gershon of The Web Collective and RagingWeb.com and Jesse
Snyder of NPower Seattle) that get together to hack on Plone and Salesforce.com
integration every Friday afternoons for “Open Source Friday’s”. Throughout this
all, a small, but interested community has formed, which is a key to ultimate
success in my opinion. Things are looking up.
THE FOUNDATION
Part of the original grant money went towards paying Enfold Systems to assess the
status of and cleanup the beatbox codebase. It’s a Python wrapper that talks to the
Salesforce.com SOAP API written by Simon Fell, who was the original architect of the Salesforce.com API. Beatbox originally lived here, but has seen several homes throughout its life cycle and the active development is now happening at Google Code. (Drop any of us a line if you want to be involved in this project.)
I don’t have a ton of insight into beatbox in and of itself, as I’ve not dug in too
deeply, but it’s now got a good suite of tests, thanks again to the Salesforce.com foundation
and Enfold Systems and in our testing, development, and use of it we’ve added better
support for various core Python data types and Salesforce.com SObject field types
and exception handling that can be used within your applications.
It’s hard to say how exactly this will evolve, but supporting the latest and
greatest Salesforce.com SOAP API (we’re 2 major releases behind now) and putting
this code up as an Egg on the Cheese Shop are up there. The latter will hopefully
be done later this week. We’d be particularly open to help at this level of the stack
BRINGING IT TO ZOPE
Thanks to NPower Seattle and one of its clients, we were
able to dust off and extend a simple Zope product that merely manages credentials for a
Salesforce.com instance, adds security, handles a volatile connection to
Salesforce.com, and extends the Salesforce.com API to those that don’t want
to write filesystem code in unprotected Python space (i.e. browser views,
tools, utilities, etc.) in order to import the needed methods for talking to
Salesforce.com.
Our primary ambition here is to make this easier for someone that’s worked with
the other toolkits provided by Salesforce.com that implement the exact same API
methods. So even though things like “upsert” and “describeSObjects” might
look foreign to a Python/Zope/Plone programmer, it should be comforting for
anyone that’s written code that talks to the Salesforce.com API.
This product will likely evolve fairly slowly (it’s basically feature complete)
going forward (there’s always better
test coverage, using Zope 3 appoaches, and keeping in line with the portions of the Salesforce.com API that
beatbox supports) with the chance that we’ll do a fairly disruptive name change
before officially releasing this. We hope to bite the bullet and decide on this
soon.
WHAT’S NEXT
Okay, so we’ve got these infrastructure pieces that work with our stack, what can
we do with them? Stay tuned. Over the next couple days, I’ll cover using this stuff
to display desired data on your Plone site and a custom adapter we’ve got working
with PloneFormGen.
Making Plone play well with Salesforce.com
Originally from The Plone Blog by Andrew Burkhalter
http://plonewars.com/2007/07/13/making-plone-play-well-with-salesforcecom/