> -- > You received this message because you are subscribed to the Google Groups > "Plone Salesforce Integration" group. > To post to this group, send email to plonesf@googlegroups.com. > To unsubscribe from this group, send email to > plonesf+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/plonesf?hl=en.
-- Cofounder and CEO ifPeople - Innovation for People www.ifpeople.net t: 678-608-3408 130 Boulevard NE, #6 Atlanta, GA 30312
> -- > You received this message because you are subscribed to the Google > Groups "Plone Salesforce Integration" group. > To post to this group, send email to plonesf@googlegroups.com > <mailto:plonesf@googlegroups.com>. > To unsubscribe from this group, send email to > plonesf+unsubscribe@googlegroups.com > <mailto:plonesf%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/plonesf?hl=en.
> -- > Cofounder and CEO > ifPeople - Innovation for People > www.ifpeople.net <http://www.ifpeople.net> > t: 678-608-3408 > 130 Boulevard NE, #6 > Atlanta, GA 30312 > -- > You received this message because you are subscribed to the Google > Groups "Plone Salesforce Integration" group. > To post to this group, send email to plonesf@googlegroups.com. > To unsubscribe from this group, send email to > plonesf+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/plonesf?hl=en.
Thanks, Chris. Let me know if you guys want to try using this and need any help getting started or want to sanity check that it's the right approach for a particular use case. It'll also play a part in my case study talk at ploneconf. cheers, David
On 9/30/11 7:51 AM, Ken Wasetis [Contextual Corp.] wrote:
> Very cool, indeed!
> I meant to ask: Is this bi-directional synching, or one-way from > Plone to SF or from SF to Plone?
At this point it only handles pulling data from Salesforce into Plone based on the metadata in the schema. It's not too hard to write an event handler to push changes back to Salesforce when the object is modified in Plone, but there's "some assembly required" for that functionality at this point.
It would be relatively straightforward to add this for cases where there is only one object involved on the Salesforce side and you're just dealing with simple field mapping. If you're pulling values from related objects, it would get harder to automatically do the right thing, and impossible to make an automatic approach be transactional (since multiple calls to Salesforce would be necessary with multiple objects). In our project where we have a Contact that has multiple sub-records for education and job history, we wrote a (SOAP) webservice in Apex on the Salesforce side, and then used suds to call that webservice from Plone in an ObjectModifiedEvent handler. This lets us pass everything in one call and let the sorting out of where things go happen on the Salesforce side. But it's definitely not a plug-and-play solution (the code and WSDL are custom to the Salesforce instance).
Some possible ways to sidestep the problems in dealing with multiple objects that I haven't had time to explore yet: 1. I think the partner (i.e. generic) Salesforce webservice now supports updating multiple objects in one call, if you've configured external id fields. 2. The winter '11 update includes some support for JSON serialization of Salesforce data, which may make it easier to create a webservice that is custom but able to handle arbitrary types of objects.
Another issue with writing back to Salesforce is that sometimes Salesforce is down for maintenance. So for a robust solution you need a queue to handle the tasks for writing to Salesforce. I want to explore using plone.app.async for this yet, but haven't found time yet.
On a completely different note related to collective.salesforce.content -- I have a branch where I started making a UI so that you can set up a synced content type TTW. I'd love to finish this up so that there's a non-programming path to getting Salesforce data exposed in Plone. But I'm unlikely to find time to do it soon unless someone wants to sponsor the project.
Thanks for the details on where things stand with this. We don't have an immediate need, but could have a client with interest in some level of bi-directional updating to/from Salesforce in the coming months, so this is really helpful. And if that work comes through and they need to update numerous Salesforce objects, I'd be glad to tap you to help build that additional functionality as a funded effort, if you're available.
If we have some client commitment before the Plone conference, and if others are interested in addressing some of the things you mention on the to-do list below, it could make sense to do a Salesforce plugin sprint, but I know you're surely pulled in 10 directions when it comes to sprinting there.
Once the sprint suggestion board is open for the conference, we'll see if there's interest.
> On 9/30/11 7:51 AM, Ken Wasetis [Contextual Corp.] wrote: >> Very cool, indeed!
>> I meant to ask: Is this bi-directional synching, or one-way from >> Plone to SF or from SF to Plone? > At this point it only handles pulling data from Salesforce into Plone > based on the metadata in the schema. It's not too hard to write an > event handler to push changes back to Salesforce when the object is > modified in Plone, but there's "some assembly required" for that > functionality at this point.
> It would be relatively straightforward to add this for cases where > there is only one object involved on the Salesforce side and you're > just dealing with simple field mapping. If you're pulling values from > related objects, it would get harder to automatically do the right > thing, and impossible to make an automatic approach be transactional > (since multiple calls to Salesforce would be necessary with multiple > objects). In our project where we have a Contact that has multiple > sub-records for education and job history, we wrote a (SOAP) > webservice in Apex on the Salesforce side, and then used suds to call > that webservice from Plone in an ObjectModifiedEvent handler. This > lets us pass everything in one call and let the sorting out of where > things go happen on the Salesforce side. But it's definitely not a > plug-and-play solution (the code and WSDL are custom to the Salesforce > instance).
> Some possible ways to sidestep the problems in dealing with multiple > objects that I haven't had time to explore yet: > 1. I think the partner (i.e. generic) Salesforce webservice now > supports updating multiple objects in one call, if you've configured > external id fields. > 2. The winter '11 update includes some support for JSON serialization > of Salesforce data, which may make it easier to create a webservice > that is custom but able to handle arbitrary types of objects.
> Another issue with writing back to Salesforce is that sometimes > Salesforce is down for maintenance. So for a robust solution you need > a queue to handle the tasks for writing to Salesforce. I want to > explore using plone.app.async for this yet, but haven't found time yet.
> On a completely different note related to > collective.salesforce.content -- I have a branch where I started > making a UI so that you can set up a synced content type TTW. I'd love > to finish this up so that there's a non-programming path to getting > Salesforce data exposed in Plone. But I'm unlikely to find time to do > it soon unless someone wants to sponsor the project.
