This discussion is archived
6 Replies Latest reply: Sep 4, 2013 1:57 PM by Nagarajan Seshadri RSS

ATG-Endeca integration - Modifying the user's search query term before it is sent to Endeca

Jon Schneider Newbie
Currently Being Moderated

While testing the ATG-Endeca front-end search/browse integration in my organization's commerce application, one of our QA team members noticed that a search term consisting of just a vertical pipe character ("|") would cause the entire product catalog to be returned in the search results, as though every single product in the catalog was a match for that search term.

 

This behavior can be seen in the Endeca JSP Reference Application as well, so this behavior doesn't seem to be caused by something that our custom application code is doing.

 

This is undesirable behavior for our application -- the business would prefer that we not show the entire catalog of products at the same time without it being sliced down somehow (either via a search term, or via the application of property filters).

 

I'm considering implementing a solution of just scrubbing "|" characters from the search term input.  It would be easy enough to do this on the client side, but as with any other web application input validation, we'd really want to be doing this on the server side. 

 

I think this would need to be done by overriding/extending a part of the OOTB ATG pipeline where it sends the search query to Endeca for processing.  However, this isn't something that I've done before.  I've read through Chapter 7 of the ATGEndecaIntegrationGuide.pdf ("Query Integration"), but it isn't immediately obvious to me how/where I'd best go about overriding/extending an OOTB ATG component to accomplish filtering out "|" characters from the search query term.

 

Has anyone done this kind of thing before?  If so, could you please describe how you went about doing it?

 

Thanks!

 

-Jon

  • 1. Re: ATG-Endeca integration - Modifying the user's search query term before it is sent to Endeca
    Jon Schneider Newbie
    Currently Being Moderated

    I ended up implementing this as follows:

     

    - Create a new class that extends the InvokeAssembler class;

    - Set up a custom InvokeAssembler.properties file that points to my new derived class;

    - In the service() method of the new derived class, use methods of the DynamoHttpServletRequest to filter pipe characters out of the Ntt parameter value and out of the query string.  Then, call super.service() to handle the request.

     

    -Jon

  • 2. Re: ATG-Endeca integration - Modifying the user's search query term before it is sent to Endeca
    Nagarajan Seshadri Newbie
    Currently Being Moderated

    Jon,

     

    Can you clarify as to whether you are using Endeca Experience Manager? I am asking this because InvokeAssembler is a droplet which you would use only when you would want to insert cartridges on a normal JSP which isnt served by Experience Manager, isnt it ? If your whole page is rendered via Experience Manager shouldnt you be doing in the Cartridge Handler or the NavigationStateBuilder or somewhere else where it is appropriate ? Using InvokeAssembler on JSPs is kind of not a preferred approach if your whole page is already served by XM.

     

    -Naga

  • 3. Re: ATG-Endeca integration - Modifying the user's search query term before it is sent to Endeca
    Jon Schneider Newbie
    Currently Being Moderated

    Hi Naga!  :-)

     

    Our implementation is not currently using Experience Manager.  We just have the combination of ATG and "vanilla" Endeca.

     

    Thanks for the note, though. We are evaluating moving to Experience Manager in the future, and I will keep this in mind.

     

    -Jon

  • 4. Re: ATG-Endeca integration - Modifying the user's search query term before it is sent to Endeca
    Nagarajan Seshadri Newbie
    Currently Being Moderated

    Ok. Great :-)

     

    To understand your problem better, just incase you can share more information on how you are interacting with Endeca when the user query is submitted it would be of great help. I am asking this because Droplets as a general ATG practice should only be used for Data rendering / view whereas FormHandlers should be used for Validating or modifying user data from HTML Forms.

     

    -Naga

  • 5. Re: ATG-Endeca integration - Modifying the user's search query term before it is sent to Endeca
    Jon Schneider Newbie
    Currently Being Moderated

    Naga, our implementation is based on the technique described in the ATGEndecaIntegrationGuide.pdf, 10.1.2 version, in Chapter 7 ("Query Integration"), in the section "Invoking the Assembler using the InvokeAssembler Servlet Bean" (beginning on page 66).

     

    -Jon

  • 6. Re: ATG-Endeca integration - Modifying the user's search query term before it is sent to Endeca
    Nagarajan Seshadri Newbie
    Currently Being Moderated

    Thanks for that information, Jon. Ideally if you are using assembler with or without ExperienceManager you have some OOTB Cartridge handlers at your disposal which you can override to do whatever customizations you want to do. If you read the integration guide about Assembling pages you would understand that you can do Page content assembling by two ways - using Assembler completely for the whole page or using Invoke Assembler servlet bean to assemble a small section of your page - could be related products / spotlights or anything of that sort. But the InvokeAssembler as I know off is really not for modifying requests to Endeca. Its more like you want to insert a Spotlight or SearchBox or some other cartridge then insert an InvokeAssembler with the specified contentItem details and then use the renderContentItem to render the same as below

     

    <div id="headerMiddle">

    <dsp:droplet name="InvokeAssembler">

    <dsp:param name="contentCollection" value="/content/Shared/Global Search Configuration/Search Box"/>

    <dsp:oparam name="output">

    <dsp:getvalueof var="searchBox" vartype="com.endeca.infront.assembler.ContentItem" param="contentItem" />

    </dsp:oparam>  

    </dsp:droplet>

    <c:if test="${not empty searchBox}">

    <dspl:renderContentItem contentItem="${searchBox}"/>

    </c:if>        

    </div>

     

    So its more for generating HTML (on the whole or partial) rather than editing a user input and submitting it to the MDEX.

     

    To help understand you situation better, before introducing the InvokeAssembler how was your query sent to Endeca ? Is it just a form submit to the same page with a Ntt param ? You can understand which component/cartridges are actually handling your request by enabling loggingDebug on /atg/endeca/assembler/AssemblerTools component.

     

    -Naga

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points