The Drupal 8 Salesforce Suite allows you to map Drupal entities to Salesforce objects using a 1-to-1 mapping. To do this it provides a series of field mapping types that allow you to select how you want to relate the data between the two systems. Each field type provides handling to help ensure the data is handled correctly on each side of the system.
As of this writing the suite provides six usable field mapping types:
- Properties — The most common type to handle mapping data fields.
- Record Type — A special handler to support Salesforce record type settings when needed.
- Related IDs — Handles translating SFIDs to Drupal Entity IDs when two objects are related in both systems.
- Related Properties — For handling properties across a relationship (when possible).
- Constant — A constant value on the Drupal side that can be pushed to Salesforce.
- Token — A value set via Drupal Token.
There is a seventh called Broken to handle mappings that have changed and need a fallback until its fixed. The salesforce_examples module also includes a very simple example called Hardcoded the shows how to create a mapping with a fixed value (similar to, but less powerful than, Constant field).
These six handle the vast majority of use cases but not all. Fortunately the suite was designed using Drupal 8 annotated plugins , so you can add your own as needed. There is an example in the suite’s example module, and you can review the code of the ones that are included, but I think some people would find an overview helpful.
As an example I’m using the plugin I created to add support for related entities to the webform submodule of the suite (I’m referencing the patch in #10 cause that’s current as of this writing, but you should actually use whatever version is most recent or been accepted).
Like all good annotated plugins to tell Drupal about it all we have to do is create the file in the right place. In this case that is: [my_module_root]/src/Plugins/SalesforceMappingField/[ClassName] or more specifically: salesforce_webform/src/Plugin/SalesforceMappingField/WebformEntityElements.php
At the top of the file we need to define the namespace, add some use statements.
<?php
namespace Drupal\salesforce_webform\Plugin\SalesforceMappingField;
use Drupal\Core\Entity\EntityInterface;
use Drupal\Core\Form\FormStateInterface;
use Drupal\salesforce_mapping\Entity\SalesforceMappingInterface;
use Drupal\salesforce_mapping\SalesforceMappingFieldPluginBase;
use Drupal\salesforce_mapping\MappingConstants;
Next we need to provide the required annotation for the plugin manager to use. In this case it just provides the plugin’s ID, which needs to be unique across all plugins of this type, and a translated label.
/**
* Adapter for Webform elements.
*
* @Plugin(
* id = "WebformEntityElements",
* label = @Translation("Webform entity elements")
* )
*/
Now we define the class itself which must extend SalesforceMappingFieldPluginBase.
class WebformEntityElements extends SalesforceMappingFieldPluginBase {
With those things in place we can start the real work. The mapping field plugins are made up of a few parts:
- The configuration form elements which display on the mapping settings edit form.
- A value function to provide the actual outbound value from the field.
- Nice details to limit when the mapping should be used, and support dependency management.
The buildConfigurationForm function returns an array of form elements. The base class provides some basic pieces of that array that you should plan to use and modify. So first we call the function on that parent class, and then make our changes:
/**
* {@inheritdoc}
*/
public function buildConfigurationForm(array $form, FormStateInterface $form_state) {
$pluginForm = parent::buildConfigurationForm($form, $form_state);
$options = $this->getConfigurationOptions($form['#entity']);
if (empty($options)) {
$pluginForm['drupal_field_value'] += [
'#markup' => t('No available webform entity reference elements.'),
];
}
else {
$pluginForm['drupal_field_value'] += [
'#type' => 'select',
'#options' => $options,
'#empty_option' => $this->t('- Select -'),
'#default_value' => $this->config('drupal_field_value'),
'#description' => $this->t('Select a webform entity reference element.'),
];
}
// Just allowed to push.
$pluginForm['direction']['#options'] = [
MappingConstants::SALESFORCE_MAPPING_DIRECTION_DRUPAL_SF => $pluginForm['direction']['#options'][MappingConstants::SALESFORCE_MAPPING_DIRECTION_DRUPAL_SF],
];
$pluginForm['direction']['#default_value'] =
MappingConstants::SALESFORCE_MAPPING_DIRECTION_DRUPAL_SF;
return $pluginForm;
}
In this case we are using a helper function to get us a list of entity reference fields on this plugin (details are in the patch and unimportant to this discussion). We then make those fields the list of Drupal fields for the settings form. The array we got from the parent class already provides a list of Salesforce fields in $pluginForm[‘salesforce_field’] so we don’t have to worry about that part. Since the salesforce_webform module is push-only on its mappings, this plugin was designed to be push only as well, and so limits to direction options to be push only. The default set of options is:
'#options' => [
MappingConstants::SALESFORCE_MAPPING_DIRECTION_DRUPAL_SF => t('Drupal to SF'),
MappingConstants::SALESFORCE_MAPPING_DIRECTION_SF_DRUPAL => t('SF to Drupal'),
MappingConstants::SALESFORCE_MAPPING_DIRECTION_SYNC => t('Sync'),
],
And you can limit those anyway that makes sense for your plugin.
With the form array completed, we now move on to the value function. This is generally the most interesting part of the plugin since it does the work of actually setting the value returned by the mapping.
/**
* {@inheritdoc}
*/
public function value(EntityInterface $entity, SalesforceMappingInterface $mapping) {
$element_parts = explode('__', $this->config('drupal_field_value'));
$main_element_name = reset($element_parts);
$webform = $this->entityTypeManager->getStorage('webform')->load($mapping->get('drupal_bundle'));
$webform_element = $webform->getElement($main_element_name);
if (!$webform_element) {
// This reference field does not exist.
return;
}
try {
$value = $entity->getElementData($main_element_name);
$referenced_mappings = $this->mappedObjectStorage->loadByDrupal($webform_element['#target_type'], $value);
if (!empty($referenced_mappings)) {
$mapping = reset($referenced_mappings);
return $mapping->sfid();
}
}
catch (\Exception $e) {
return NULL;
}
}
In this case we are finding the entity referred to in the webform submission, loading any mapping objects that may exist for that entity, and returning the Salesforce ID of the mapped object if it exists. Yours will likely need to do something very different.
There are actually two related functions defined by the plugin interface, defined in the base class, and available for override as needed for setting pull and push values independently:
/**
* An extension of ::value, ::pushValue does some basic type-checking and
* validation against Salesforce field types to protect against basic data
* errors.
*
* @param \Drupal\Core\Entity\EntityInterface $entity
* @param \Drupal\salesforce_mapping\Entity\SalesforceMappingInterface $mapping
*
* @return mixed
*/
public function pushValue(EntityInterface $entity, SalesforceMappingInterface $mapping);
/**
* An extension of ::value, ::pullValue does some basic type-checking and
* validation against Drupal field types to protect against basic data
* errors.
*
* @param \Drupal\salesforce\SObject $sf_object
* @param \Drupal\Core\Entity\EntityInterface $entity
* @param \Drupal\salesforce_mapping\Entity\SalesforceMappingInterface $mapping
*
* @return mixed
*/
public function pullValue(SObject $sf_object, EntityInterface $entity, SalesforceMappingInterface $mapping);
But be careful overriding them directly. The base class provides some useful handling of various data types that need massaging between Drupal and Salesforce, you may lose that if you aren’t careful. I encourage you to look at the details of both pushValue and pullValue before working on those.
Okay, with the configuration and values handled, we just need to deal with programmatically telling Drupal when it can pull and push these fields. Most of the time you don’t need to do this, but you can simplify some of the processing by overriding pull() and push() to make sure the have the right response hard coded instead of derived from other sources. In this case pulling the field would be bad, so we block that:
/**
* {@inheritdoc}
*/
public function pull() {
return FALSE;
}
Also, we only want this mapping to appear as an option if the site has the webform module enabled. Without it there is no point in offering it at all. The plugin interface provides a function called isAllowed() for this purpose:
/**
* {@inheritdoc}
*/
public static function isAllowed(SalesforceMappingInterface $mapping) {
return \Drupal::service('module_handler')->moduleExists('webform');
}
You can also use that function to limit a field even more tightly based on the mapping itself.
To further ensure the configuration of this mapping entity defines its dependencies correctly we can define additional dependencies in getDependencies(). Again here we are tied to the Webform module and we should enforce that during and config exports:
/**
* {@inheritdoc}
*/
public function getDependencies(SalesforceMappingInterface $mapping) {
return ['module' => ['webform']];
}
And that is about it. Once the class exists and is properly setup, all you need to do is rebuild the caches and you should see your new mapping field as an option on your Salesforce mapping objects (at least when isAllowed() is returning true).
