# Additional data on BRItemModel from brSM **URL:** \ **Category:** Experience Manager (PaaS/OnPrem)\ **Created:** [December 23, 2019, 10:42am UTC](https://community.bloomreach.com/t/additional-data-on-britemmodel-from-brsm/1646 "2019-12-23T10:42:09Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![rsingh1](https://avatars.discourse-cdn.com/v4/letter/r/779978/32.png) [@rsingh1](https://community.bloomreach.com/u/rsingh1)\ **Post date:** [December 23, 2019, 10:42am UTC](https://community.bloomreach.com/t/additional-data-on-britemmodel-from-brsm/1646/1 "2019-12-23T10:42:10Z")
Hi All, As usual, we are also requiring to access additional fields on BRItemModel from brSM. We know that [Log in - Issues](https://issues.onehippo.com/browse/ACCEL-695) 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 ---
**Author:** ![giacomolm](https://yyz1.discourse-cdn.com/flex027/user_avatar/community.bloomreach.com/giacomolm/32/1733_2.png) [@giacomolm](https://community.bloomreach.com/u/giacomolm)\ **Post date:** [December 23, 2019, 11:31am UTC](https://community.bloomreach.com/t/additional-data-on-britemmodel-from-brsm/1646/2 "2019-12-23T11:31:14Z")
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 > \2.4.1\ 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](https://documentation.bloomreach.com/13/library/upgrade-minor-versions/upgrade-13.4.0-to-13.4.1.html) ---
**Author:** ![rsingh1](https://avatars.discourse-cdn.com/v4/letter/r/779978/32.png) [@rsingh1](https://community.bloomreach.com/u/rsingh1)\ **Post date:** [December 23, 2019, 11:46am UTC](https://community.bloomreach.com/t/additional-data-on-britemmodel-from-brsm/1646/3 "2019-12-23T11:46:58Z")
Hi @giacomolm, thanks for your swift and accurate reply. much appreciated. Thanks. Ravinder ---
**Author:** ![rsingh1](https://avatars.discourse-cdn.com/v4/letter/r/779978/32.png) [@rsingh1](https://community.bloomreach.com/u/rsingh1)\ **Post date:** [December 24, 2019, 12:47pm UTC](https://community.bloomreach.com/t/additional-data-on-britemmodel-from-brsm/1646/4 "2019-12-24T12:47:44Z")
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. (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? ---
**Author:** ![giacomolm](https://yyz1.discourse-cdn.com/flex027/user_avatar/community.bloomreach.com/giacomolm/32/1733_2.png) [@giacomolm](https://community.bloomreach.com/u/giacomolm)\ **Post date:** [December 24, 2019, 1:20pm UTC](https://community.bloomreach.com/t/additional-data-on-britemmodel-from-brsm/1646/5 "2019-12-24T13:20:58Z")
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](https://documentation.bloomreach.com/library/solutions/commerce-starterstore/connector-configuration/commerce-connector-set-model.html) ---
**Author:** ![rsingh1](https://avatars.discourse-cdn.com/v4/letter/r/779978/32.png) [@rsingh1](https://community.bloomreach.com/u/rsingh1)\ **Post date:** [December 24, 2019, 1:22pm UTC](https://community.bloomreach.com/t/additional-data-on-britemmodel-from-brsm/1646/6 "2019-12-24T13:22:57Z")
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 ---
**Author:** ![rsingh1](https://avatars.discourse-cdn.com/v4/letter/r/779978/32.png) [@rsingh1](https://community.bloomreach.com/u/rsingh1)\ **Post date:** [January 23, 2020, 12:09pm UTC](https://community.bloomreach.com/t/additional-data-on-britemmodel-from-brsm/1646/7 "2020-01-23T12:09:00Z")
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. ---
**Author:** ![woonsanko](https://avatars.discourse-cdn.com/v4/letter/w/b5a626/32.png) [@woonsanko](https://community.bloomreach.com/u/woonsanko)\ **Post date:** [January 23, 2020, 2:05pm UTC](https://community.bloomreach.com/t/additional-data-on-britemmodel-from-brsm/1646/8 "2020-01-23T14:05:10Z")
Hi Ravinder, > [@rsingh1](#): > > I have found that ProductDecorationCommand has extended getItemModel() and calls the productRepo.findOne() every time 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 ---
**Author:** ![rsingh1](https://avatars.discourse-cdn.com/v4/letter/r/779978/32.png) [@rsingh1](https://community.bloomreach.com/u/rsingh1)\ **Post date:** [January 23, 2020, 3:03pm UTC](https://community.bloomreach.com/t/additional-data-on-britemmodel-from-brsm/1646/9 "2020-01-23T15:03:16Z")
We had upgraded to 2.4.1 as you suggested in previous comment. So it is 2.4.1 ---
**Author:** ![woonsanko](https://avatars.discourse-cdn.com/v4/letter/w/b5a626/32.png) [@woonsanko](https://community.bloomreach.com/u/woonsanko)\ **Post date:** [January 23, 2020, 3:09pm UTC](https://community.bloomreach.com/t/additional-data-on-britemmodel-from-brsm/1646/10 "2020-01-23T15:09:04Z")
Thanks, Ravinder! I’ve filed a ticket, [https://issues.onehippo.com/browse/ACCEL-896](https://issues.onehippo.com/browse/ACCEL-896), to fix it soon. Woonsan ---
**Author:** ![woonsanko](https://avatars.discourse-cdn.com/v4/letter/w/b5a626/32.png) [@woonsanko](https://community.bloomreach.com/u/woonsanko)\ **Post date:** [January 23, 2020, 5:29pm UTC](https://community.bloomreach.com/t/additional-data-on-britemmodel-from-brsm/1646/11 "2020-01-23T17:29:45Z")
I’ve also backported the fundamental fix to 2.4 branch: [https://issues.onehippo.com/browse/ACCEL-897](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: ```auto <#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 ---
**Author:** ![giacomolm](https://yyz1.discourse-cdn.com/flex027/user_avatar/community.bloomreach.com/giacomolm/32/1733_2.png) [@giacomolm](https://community.bloomreach.com/u/giacomolm)\ **Post date:** [January 23, 2020, 5:41pm UTC](https://community.bloomreach.com/t/additional-data-on-britemmodel-from-brsm/1646/12 "2020-01-23T17:41:46Z")
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.