Views Integration

If you're gonna be caching data anyway, then why not just use what's built out now?
cck and a field map will get at what it sounds like you're after.

I'll also throw in that -- on top of the API call limit, which is really a pain once you hit it -- you have to worry about latency issues around a back-end http connection slowing down your front-end user experience.

We don't want to turn our Salesforce objects into node data because they are going to have to be accessible from multiple Drupal sites. It's sort of a complex and perhaps uncommon use case.

Again, I don't see any issue with storing Salesforce objects as node data, even across multiple Drupal sites.

Have you looked into using Salesforce Outbound Messaging? I put together a module in this issue Update Drupal on Salesforce content creation. Using hook_xmlrpc, it establishes two-way communication between Salesforce and Drupal. Of course you'd have to do some Salesforce configuration, but you could use this module on all your Drupal sites to keep your Drupal instances in synch with your Salesforce data. I assume that's your primary concern? What other concerns do you have with this approach?

What you're describing would likely solve the problem with one or two sites but we will need to add many sites in the future that will need access to all of the existing data. We don't want to share any other content so it doesn't make sense to share those tables with the new sites (and I feel like that would get especially dicey with a CCK setup like this which could potentially change in the future.

Furthermore, our client is adamant about having one and only one copy of the data (but is willing to make exceptions for caching). I think what we really need to do is create listings of content that (with the exception of some caching) does not live in our database. If this is a rare enough use case that sf views integration doesn't make sense as a contribution to the module we'll just share it in a blog post and leave it at that.

What you're talking about is a different approach from the direction development has gone w/ this suite.

However, you could definitely make use of salesforce_api to accomplish your task (sf_node and sf_user are antithetical to your purpose).

Some folks have been kicking around the idea of a caching mechanism, and you could make use of hook_xmlrpc to keep your cache clean. I don't have a full grasp of what you're trying to do or how you plan to approach it, but I'm interested to see what you come up with.

Let's keep this thread open and keep us posted on your progress.

tizzo, Views integration as Views 3.0 allows and has been demonstrated in the past with Flickr's API would be #@$% awesome! Please keep this up to date. Such a module would only be dependent on small parts of salesforce API module. E.g. it wouldn't use the fieldmap API. Consider working on #444350: Absract fieldmap API to optimize code/memory use, though this wouldn't be a requirement.

I think such a module is appropriate in SF API core, though may be easier to maintain/manage as it's own module elsewhere on drupal.org. That's up to you, but I'd encourage contribution to SF API module, if you are happy to maintain it here.

I have some very simple integration working quite well, but the real value of this comes from being able to work with the custom objects defined in salesforce. After looking at the wsdl from salesforce I think we could use an abstracted field_map api to programmatically generate the data for hook_views_data so that all you'd have to do is check off which objects you'd like to make available to views.

I've started some work on this but I'm afraid our client doesn't want to develop it quite that far so I have hard coded the few objects/fields that we need and unless someone want to sponsor the development I probably won't be able to push this much further...