A big thank you to the Salesforce Foundation for inviting me to contribute a post on Plone+Salesforce integration to their blog. It was fun to reacquaint myself with all the tools and learn what’s new. Timely too, since we have just started work on a new Plone site for The Mountaineers which will include integration of all their custom content with Salesforce.com. We are working on this project in partnership with Percolator Consulting. They are engagement strategists and Salesforce specialists and are creating the CRM back end while we are creating the Plone site.
In the process of writing and discussing this post, I discovered that David Glick, who is working on The Mountaineers project with us, and Jason Lantz, from the Innocence Project, were having similar thoughts about the Plone+Salesforce toolkit. This week we had a chat to explore ways in which we might collaborate.
There are two main areas in need of improvement.
- Salesforce.com API integration – The current Python library used by Plone is Beatbox, which is a wrapper for the Salesforce.com SOAP API. We now have Simple Salesforce, a Python library providing a low level interface to the Salesforce.com REST API (it returns a dictionary of the API’s JSON response). There is also a new socket-based streaming API. David and Jason are evaluating replacing Beatbox with one of these more modern components.
- Message queuing – The current set of Plone+Salesforce tools rely on real-time communication with Salesforce.com, which slows performance and does not recover gracefully from network errors. A message queuing approach is sorely needed, where API requests can be queued for delivery and automatically retried. David and Jason are evaluating our options for Python message queuing. This includes but is not limited to plone.app.async. We would like the Plone implementation to build on a pure Python layer that could be used in any Python web framework (such as Django or Pyramid).
These items are critical to the success of The Mountaineers’ and the Innocence Project’s Plone+Salesforce integrations. In both cases the volume of API calls will be great enough that asynchronous communication is a must-have. Over the next few weeks we hope to create a plan that our two projects can collaborate on, for drastically improving the Plone+Salesforce infrastructure. This will benefit the entire Plone+Salesforce ecosystem – for example, the message queuing system could be used as the basis for a form-to-Salesforce solution that is more responsive and robust.
We would also like to improve the administrative tools that are available. Site admins will need a control panel that allows them to monitor and retry messages in the queue. Down the road it would be great to provide a way for integrators to define Plone to Salesforce content mappings through the web. Today it is necessary to do Python development to implement anything other than a fairly simple Plone+Salesforce web-to-lead form.
Our goal is to flesh out a plan by June 5th, when David, Jason and I will all be at Plone Symposium Midwest. Please contact me if you’d like to join our conversations, and maybe even sprint on an improved Plone+Salesforce infrastructure!
