Retrieving Commerce attribute values to Configuration has been one of the BigMachines’ limitations that BigMachines has. Most of the implementations follow SFDC->Quote-> Configurator->Quote->SFDC flow. In such scenarios, it is very common to have a requirement which needs Quote data to be used in Configuration.
The clean and easiest solution for this is writing a JS Cookie. Write a cookie and paste it in the ‘Header&Footer’ section of the admin. The ‘Header&Footer’ is typically the placeholder to store all the JS related to Config/Commerce manipulations.
Sample Cookie snippet:
\\File Manager by default has an util_class.js which has many commonly used JS functions like get cookie, set cookie defined. So use it
<script type="text/javascript" src = 'https://testge.bigmachines.com/bmfsweb/testge/image/Scripts/util_class.js'> </script> <script type="text/javascript">
\\On the commerce page, find the commerce attribute and store its value in the browser
if (document.bmDocForm) {
var commerceAttr1 = document.getElementsByName("commerce_attribute");if(commerceAttr1.length != 0){
var tempcommerce_attribute = commerceAttr1[0].value;
_util.setCookie("config_attribute",tempcommerce_attribute, 2);
}
}
var changed = false;
\\Now search for the config attribute and then apply the cookie value to it
if (document.configurationForm)
{
if (document.configurationForm.config_attribute)
{
var tempconfig_attribute = _util.getCookie("config_attribute");
if (document.configurationForm.config_attribute.value != tempconfig_attribute)
{
if (tempconfig_attribute != null && tempconfig_attribute != "")
{
document.configurationForm.config_attribute.value = tempconfig_attribute;
changed = true;
}
}
document.configurationForm.config_attribute.readOnly = true;
}
if (changed)
{
submitPage(document.configurationForm, true, true);
}
}
Now this helps to auto-populate the configuration attribute with a commerce attribute value. Whenever user populates value to this ‘commerce_attribute’ on the quote page and then opens the configuration (via add line items or reconfigure), this cookie value is stored and then applied to the configuration attribute after arriving there.
This answers a lot of scenarios. Most of the requirements which need SFDC values to be populated in configuration, can make use of this effort. Also if the SFDC values are not directly the values that needs to be populated in configuration, but if they have a mapping index, all you have to do is get those values to config and then do a BML across the mappings table to populate the config data.
Hey nice post ….
I think its better to avoid getElementsByName usage and use getElementById if possible as getElementsByName implementation is not proper in IE and might give u strange results at times .
Deepthi, thanks for the feedback. We’ve considered two things for using ‘Name’ instead of ‘ID’. The attributes which need to be populated by the cookie are available across multiple PLs (i.e, multiple configurators). We thought that going by ID, we might have to write multiple cookies for same attribute when presented in different config flows. Name helps us by just one cookie across multiple PLs. Also we couldnt trust the Rich UI framework as the IDs could be tricky at times!
Anyways, good one though. Might help the readers to choose from.