Learn about the long-awaited effort underway to port the Salesforce Suite, a complex Drupal 7 module, to Drupal 8.
In November of 2016, we passed the one-year anniversary of the Drupal 8.0.0 release. The community is finally catching up on porting more advanced modules to this latest version, and the Salesforce Suite is no exception. Aaron Bauman, the original architect of this suite of modules that integrate Drupal and Salesforce, has been working on the port of the Suite from D7 to D8 for quite some time. Dozens of meta-comments, half a dozen refactors, and hundreds of hours later, Salesforce-8.x-3.x is picking up steam.
In this session, we'll explore aspects of navigating the dozens of new Drupal 8 APIs, architectural decisions when planning your projects, issues management, and team coordination. We'll look at the current state of Salesforce Suite's update to Drupal 8, including:
Major components already ported from Drupal 7, including Salesforce Mapping UI, Drupal to Salesforce Push, and Salesforce to Drupal Pull
New features for Drupal 8, including new Plugin APIs, event scheme, Queue APIs, examples module, unit tests, and new class hierarchy
Roadmap to Drupal 8 stable release, including migration paths from Drupal 7, a baked-in SOAP client, more unit tests, kernel tests, more examples, and additional documentation.
In addition to porting existing 7.x-3.x functionality, 8.x-3.x fixes long-standing bugs and fills in gaps from the 7.x-3.x fork, as well as introduces brand new features
Quick overview of the 2 key processes of Salesforce module:
push. Diagram of real-time push. (push also happens asynchronously)
pull is asynchronous (during cron) only. Uses core DatabaseQueue API
Placeholder slide to demonstrate setting up a Mapping, filling out a form, and pushing data to Salesforce
Salesforce Suite defines 2 entity types: Salesforce Mapping + Mapped Object
Each relies on a storage handler to provide convenience methods, e.g. to look up by foreign keys.
Plugin API replaces many hacky elements of hook system, eliminates relying on naming conventions for core functionality.
With Plugin API we finally have full extensibility and pluggability.
What do we mean by that?
Pluggability: contrib space can replace existing plugin implementations
Extensibility: contrib space can add new plugins
Class inheritance! Interfaces! PSR-4!
Pull plugin uses core DatabaseQueue and a QueueWorker plugin to pull data from SF to Drupal
Push plugin defines PushQueue to extend DatabaseQueue, and a SalesforcePushQueueProcessor Plugin to bulk-process pushing data from Drupal to SF. Core Queue API is designed to process items one-at-a-time; relies on serialized data; with Salesforce API, we can (and should) do better: optimization of query usage / network callouts e.g. grouping similar actions; prioritization of push actions, e.g. "Account" before "Contact"
OK, not exactly but pretty close.
All hooks have been replaced with events for D8.