Full-text search index on hosted feature layer attribute doesn't appear to be working properly in EB (AGOL-hosted version)

1997
4
Jump to solution
11-03-2023 03:29 PM
Labels (1)
BrianFausel
Occasional Contributor III

Since the October ArcGIS Online (AGOL) update I have had problems with attribute-based text searching in Experience Builder (EB). All of the items I am dealing with are hosted in ArcGIS Online, including the application and layers. In these examples there are no items coming from Enterprise.

 

Problematic item

My Search bar widget in EB is set up to search a text attribute in an hosted feature layer. Problem can also be seen in other Esri apps but I am specifically working with EB in this case.

 

Problem Description

I have an AGOL-hosted feature layer with a full-text index defined on an attribute and as a result certain types of searches do not work in EB.

Alternatively, if I have a similar but separate feature layer with NO indexes the EB search works as expected. This is the opposite way I would think it would work.

 

I have 2 public EB apps below that demonstrate the issue. In both try searching for the address string "3805 s casper"

EB app without indexes

EB app with full text index set up

In both apps if you type only "3805" you'll see the desired result appear in the candidate list.

But if you start typing "3805 s" the results will work properly in the app without the index but will NOT work in the one with the full text index. In this case typing "3805 s" says "no results."

 

The problem has something to do with the search widget breaking change mentioned in the EB blog, as I did not encounter it before the update. I have also read the Searching for Features blog from last November and have not been able to come up with a solution other than to eliminate all attribute indexes. Reading this blog suggests that even a search like "3805 casper" (leaving out the direction "s") should return a proper result when indexes are created.

 

Is anyone else having a similar problem?

@RussRoberts 

 

 

1 Solution

Accepted Solutions
RussRoberts
Esri Notable Contributor

This looks to be an issue with the EB search widget. The search term is not separating the searched terms apart causing the index to not return results vs. JSAPI widget that Map Viewer and other apps use will break up the search terms and will match how the index has tokenized the terms.  Would recommend creating a support ticket for this.

EB does a fulltext search on search term "3805 s"

JSAPI Search will do search term 3805, search term s

RussRoberts_0-1699281930346.png

 

 

View solution in original post

4 Replies
RussRoberts
Esri Notable Contributor

This looks to be an issue with the EB search widget. The search term is not separating the searched terms apart causing the index to not return results vs. JSAPI widget that Map Viewer and other apps use will break up the search terms and will match how the index has tokenized the terms.  Would recommend creating a support ticket for this.

EB does a fulltext search on search term "3805 s"

JSAPI Search will do search term 3805, search term s

RussRoberts_0-1699281930346.png

 

 

BrianFausel
Occasional Contributor III

Thanks Russ. I'll investigate the Map Viewer search you mentioned and will definitely contact support to either create a ticket or see if there is one already. Will post any updates I find.

0 Kudos
BrianFausel
Occasional Contributor III

I have opened a support ticket. In the meantime I tested the searching in the web map JSAPI search as you suggested. I saw the same results you did where the index search appears to work. Interestingly I also tested it in a WebAppBuilder app that also worked the same as the web map.

A side-question I have is about the candidate list that appears if a user enters the direction "s" when using the web map JSAPI search. In this example if I just type "3805" I see 4 candidates (which is correct):

3805_only.jpg

 

If I type "3805 s" then I only see 2 candidates and note that they are ones with words that start with "s" later in the string:

3805_s.jpg

And finally if I type "3805 casper" it finds the correct one. This is actually the ideal behavior and what I would expect from a full text index. But I am still curious why "3805 s" does not show 4 candidates.

3805_casper.jpg

0 Kudos
BrianFausel
Occasional Contributor III

I have confirmed with Esri Support that this appears to be a bug in Experience Builder. It was logged as ENH-000163068 if you want to refer to it.

• Synopsis: Experience Builder Search Widget does not honor the Feature layer's Full Text Field Indexes
• Status: In Review

Below is a summary of what I saw while searching for variations of an address string in a text attribute in Experience Builder (ExB) and Web AppBuilder (WAB). In my case the apps and data are all hosted in ArcGIS Online. I haven't done any testing with anything coming from Enterprise.

The example address I am searching is stored in the text attribute as "3805 s casper dr" (address number, direction abbreviation, street name, suffix abbreviation).

  • "3805" (left-side start of the string) returns a proper candidate list in all ExB and WAB apps.
  • "casper" (street name in middle of string) returns an appropriate candidate list in WAB (with layer index) and ExB (with layer index). The recent AGOL update causes this search to return NO results in ExB (no index on layer).
  • "3805 s" (direction included) returns partial results in WAB (with index) - 2 of 4 (?), NO results in ExB (with index) and all available candidates in ExB (no index).
  • "3805 casper" (direction left out) returns correct result in WAB (with index) and NO results in ExB (with index) or ExB (no index).

I have only tested address-like text strings but would guess there might be a problem with other types of text.

In my case the workaround will be to eliminate all text indexes on the feature service. This at least allows my users to enter "3805 s casper" to get results they have been used to seeing.

 

0 Kudos