Additional data on BRItemModel from brSM

Experience Manager (PaaS/OnPrem)
1

Hi All,

As usual, we are also requiring to access additional fields on BRItemModel from brSM. We know that Log in - Issues resolves this issue by exposing the “resource” publically on version 14.x. However, we are not in state to upgrade to 14.x yet. We currently are on 13.4.0.

So I would like to know the best approach to achieve this.

cc @woonsanko

2

Hi,

That functionality has been back ported to 2.4.1: in your specific case this means that you can just update the dependency version in the boot project root pom, something like

<starterstore.version>2.4.1</starterstore.version>

and you will be able to use this new functionality.
In addition, I would also like to suggest to upgrade your XM project to 13.4.1, as explained here [1]

HTH,
Giacomo

[1] Upgrade 13.4.0 to 13.4.1 - Bloomreach Experience Manager (PaaS/Self-Hosted) - The Fast and Flexible Headless CMS

3

Hi @giacomolm, thanks for your swift and accurate reply.
much appreciated.

Thanks.
Ravinder

4

Hi @giacomolm

After updating the dependency to 2.4.1, we’ve started getting following error on search pages:

[INFO] [talledLocalContainer] 24.12.2019 12:41:58 DEBUG http-nio-8080-exec-6     [BRProductRepositoryImpl.findAll:126] Finding products from connector: ID='bloomreach', ResourceSpace: 'productsResource'.
[INFO] [talledLocalContainer] 24-Dec-2019 12:41:58.423 SEVERE [http-nio-8080-exec-6] freemarker.log._JULLoggerFactory$JULLogger.error Error executing FreeMarker template
[INFO] [talledLocalContainer] 	FreeMarker template error:
[INFO] [talledLocalContainer] 	The following has evaluated to null or missing:
[INFO] [talledLocalContainer] ==> starterstoreQueryParam_offset  [in template "bloomreach_productSearch_pathVariables.ftl" at line 1, column 3]
[INFO] [talledLocalContainer] 
[INFO] [talledLocalContainer] ----
[INFO] [talledLocalContainer] Tip: If the failing expression is known to legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing</#if>. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)??
[INFO] [talledLocalContainer] ----
[INFO] [talledLocalContainer] 
[INFO] [talledLocalContainer] 	----
[INFO] [talledLocalContainer] 	FTL stack trace ("~" means nesting-related):
[INFO] [talledLocalContainer] 	- Failed at: ${starterstoreQueryParam_offset}  [in template "bloomreach_productSearch_pathVariables.ftl" at line 1, column 1]

Blockquote

Is it because we have not upgraded the BrXM to 13.4.1?

5

Hi, thanks for your question. It’s not related to upgrading brXM.

It seems like there is a leftover in the commerce connector document.

More specifically, If you open the bloomreach (brSM) connector document under the Administration folder [1], you will find on the right side a list of connector component path variables.
I would suggest to remove all the entries (including the start: ${starterstoreQueryParam_offset}) except for the fl entry.

If that’s ok for you, please try the suggested solution and let me know, thanks!

[1] https://documentation.bloomreach.com/library/solutions/commerce-starterstore/connector-configuration/commerce-connector-set-model.html

6

I’ve removed the starterstoreQueryParam_offset entry and left the rest. The problem is gone now. I saw some new changed in BRProductRepositoryImpl and made the changes in connector component accordingly.

Thanks

7

We have encountered a problem in using getResourceData () like ${compositeBean.resourceData.getValue(“brand”)} on FTL. I have found that ProductDecorationCommand has extended getItemModel() and calls the productRepo.findOne() every time we want an attribute value. So it is ending calling BrSM multiple time just for 1 product.

8

Hi Ravinder,

Nice catch! Yes, the #getItem() method should have cached the returned itemModel instead of trying to invoke the backend.
I’ll fix the bug asap. What is the version you’re working with now?

Woonsan

9

We had upgraded to 2.4.1 as you suggested in previous comment. So it is 2.4.1

10

Thanks, Ravinder!
I’ve filed a ticket, https://issues.onehippo.com/browse/ACCEL-896, to fix it soon.

Woonsan

11

I’ve also backported the fundamental fix to 2.4 branch: https://issues.onehippo.com/browse/ACCEL-897. We will try to cut a release 2.4.2 soon-ish.

BTW, you can try to assign the resourceData in the template level to reduce the unnecessary calls:

<#assign resourceData = compositeBean.resourceData />
${resourceData.getValue(“brand”)}
...
${resourceData.getValue(“somethingElse”)}

Of course, this is not a real fix, but reduced the calls as many times as using compositeBean.resourceData directly temporarily.

Regards,

Woonsan

12

Hi,

Please also consider that in case you are using CRISP and cache option is enabled, invoking directly the resourcedata shouldn’t trigger an external call: but definitely there is an overhead.