[meta] Drupal 8 Roadmap

My own preference, for maintainability, is to avoid a monolithic Salesforce Suite package. I'd prefer to see a more or less straight port of the existing 7.x-3.x branch to Drupal 8 (with the possible change of abstracting the REST and SOAP API interactions into a separate PHP library hosted on packagist). We will be better off for maintenance and support if we try to keep things simple.

I think features like merge contact handling could be handled by a contrib module (e.g. "Salesforce Contacts") that uses the hooks provided by Salesforce Push and Pull modules to implement that feature, and others relating to Contact syncing (for example there are a number of behaviors related to user account syncing that could be dealt with there).

The feature in #1 would be a good candidate to consider for Salesforce Push though.

And here's a feature idea:

feature: Full test suite for REST API interactions
priority: normal
effort: high
impact: No new functionality, but will make testing patches and writing new features much more maintanable. We would need to take an approach like Mollom and write a mock web service that is used as an endpoint for testing push/pull interactions.

Hey folks. Aaron, thanks for getting the ball rolling on a D8 port.

Aaron, quick note on #1. While there's clearly room for improvement of the queue handling, we addressed the FIFO issue in part by allowing the ordering of the mappings (via a drag and drop interface on the mapping overview page). So if you have accounts related to contacts, simply make sure that accounts are processed first and then the module properly handles relationships from there.

Regarding #2, while nodes can't be merged, RedHen and CRM core contacts can. Just a heads up that we stay focused on generic entity handling and not just nodes.

Per Kosta's comment in #3, we're committed to a lean set of building blocks to enable a wide array of use cases on a common base. We're definitely excited to be involved in moving a D8 port forward, although I have to be honest that our velocity will be in large part dictated by project needs. Given the 7.x-3.x rewrite took us around 800 hours, I'd assume something similar for 8.x.

My primary goal is to do a straight 1:1 port of the 3.x branch just to merely get things working. THEN think about other stuff.

I have done significant development in extensions for the 7.x version in a salesforce_sync and salesforce_queue modules. Sync is improving the developer interface (SOAP focused now, but I've got a REST+SOAP branch). Queue has everything that was discussed in comment #1.

The salesforce_sync module also has other features roped in that I'd like to see integrated more discretely. Sync rules allows for setting what conditions will allow overwriting when syncing, such as only when the target value is empty. There's also token support, so that, for example, if two records need to be synced simultaneously and one depends upon the other, the dependent can reference the other record as a token.

Abstract the heavy lifting as a library so that work done on 8.x features can be easily ported back to 7.x, so that this and future versions would require a lighter drupal-specific wrapper.

Abstract salesforce_mapping. Currently it focuses on just entities, but I'd like to abstract it so what is being mapped is a plugin, allowing for a generalized mapping UI and ability to map other things, such as webform.

As for testing, there's still the issue of how to authenticate with Salesforce. I could not get authentication using oauth working with simpletest. The only way I could get authentication to work is to scrape the data from the primary database and copy it to the test database. Besides that, I've got REST and SOAP testing done in that REST+SOAP branch I mentioned earlier.

Interesting... I don't have a 8.x-3.x-dev in my version dropdown, which is why my comment reverted it back to 7.x.

As for testing, there's still the issue of how to authenticate with Salesforce. I could not get authentication using oauth working with simpletest. The only way I could get authentication to work is to scrape the data from the primary database and copy it to the test database. Besides that, I've got REST and SOAP testing done in that REST+SOAP branch I mentioned earlier.

That's why I think we should take the approach from #4, to create something like a "Salesforce Test Server" module (see http://drupalcode.org/project/mollom.git/tree/refs/heads/7.x-2.x:/tests for an example).

It would take a bit of work to get this implemented, but once it's done, you don't have to rely on using credentials from an existing Salesforce instance for running the tests.

That's why I think we should take the approach from #4, to create something like a "Salesforce Test Server" module (see http://drupalcode.org/project/mollom.git/tree/refs/heads/7.x-2.x:/tests for an example).

Could you explain how this would work for Salesforce specifically? What would be the steps/workflow?

Could you explain how this would work for Salesforce specifically? What would be the steps/workflow?

I think the basic idea (@levelos mentioned this here; Mailchimp is using the same approach) is that there is a salesforce_tests_server module, whose job is to mimick the responses you get from CRUD with the Salesforce REST API. So in the tests, when you call $salesforce->apiCall(), you're actually posting responses to for example https://localhost/salesforce-test/rest/v1 instead of https://na15.salesforce.com. The Salesforce Tests Server responds with some dummy data. The tests can use the data returned from the Salesforce Tests Server as a basis for making assertions. Writing up the dummy responses to the potential calls to the Salesforce REST API would be a tedious task.

If I get time next week I can try to write a proof of concept using this approach.

Todd are you still running this with your patch on the latest D8 release?
I can see this is old and maybe forgotten module but ill test it and Todds patch soon with the latest d8 release.

Sweet, thanks man. Basic might work for me since I dont need much, I had considered just winging it without the module. lol Im building the site in d7 already but jumping to 8 has been very tempting!
Thanks again man, perhaps there is an official update coming soon.

Todd,

Does this patch allow the Salesforce API Suite module to work with D8 with full functionality? A D7 working module for D8 for integration to Salesforce without any additional custom module coding?
Relevant URL: https://www.drupal.org/node/2124001 & https://www.drupal.org/files/issues/salesforce-update_to_beta_6-2124001....
Regarding: salesforce-update_to_beta_6-2124001.patch

So, new guy here.

I've made some changes to this module to get it working with the authorization_code workflow (this workflow in Salesforce doesn't use a a refresh token).

How do I find the documentation that lets me know how to contribute to the project, provide patches and all that?

Hi edwinbsmith,

This documentation might help https://www.drupal.org/patch/submit

If you need a hand, I am happy to help you get set up - hit me up on IRC or twitter, username cam8001.

Hi folk,

I'm new to Salesforce in general. A client asked to integrate the website with Salesforce API. Authentication is done through Username-Password OAuth Authentication Flow, but my understanding is this is not covered by current 3.0 - 3.1 roadmap?

Is it worth to have this integrated? Will you accept a submodule or better having this as a separated contrib?