nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

TeamSite Search & Metadata

Annad

Hi,
I am evaluating some of the work we did with DCR and metadata.
We are setting some of the DCR fields as the extended attribute (EA) on the 'OnSave' action in FormAPI. For example, title, description, date modified and date issued. We are not currently using these custom EAs at all anywhere in TeamSite. However, we don't want to completely remove them since we might need them in the future for some other application (May be TeamSite Search??).

So basically my question is, with TeamSite Search can we search both the EAs and DCR content. Is there any disadvantage of having some information only in DCR and not in EA.

Please advise,

Anna.

Find more posts tagged with

Comments

nipper

So you have 3 choices:

You can use full text search. Easy to do, not super efficient, works well but will get more answers that you were hoping (likely).

You can configure search to index certain fields of the DCRs in question. Search can run on those and you will get only DCRs as answers. Check the section Field Mapping Configuration in the TS Admin manual (Configure TS Search Chapter)

You can push the values to EA and search them.

All of the 3 will work, but 2 nad 3 are the best for your implementation. I would tend to use #2, the indexer will do more work but removing formapi (esp if it is a call server) is a good thing, call servers and iwextattr can be unreliable and can pose performance issues (under high load).

HTH

Andy

Annad

Hi Andy,
Your reply was very useful. I was originally thinking of removing the custom EA that were set by calling the callserver(). However, I wanted to check on the best practice around this so that we don't run into problems in the future with the search.

Thanks again,
Anna.

nipper

NP, just my HO, call servers are a pain to get working, when they work they are great, when they don't they are a pain to debug. If there is a reasonable way to do what you want without the callserver, then you should use it. Since this is supported built-in functionality, searching for DCR fields is the best way to go.

Annad

some more concerns.
Do you see any potential issues because we are not storing the DCR fields as EAs. From your past experience, do you think we weould be limited on the things we can do because we don't have the DCR fields as EAs.

I am asking these questions, so that I am not making a wrong decision now.

Thanks,
Anna.

nipper

I seldom store DCR fields as EAs. It tends to be more of a problem then it helps. There are cases, where you have a consistent code in the DCR (like a product code or something like that), where you may store it as an EA as well, but that is the exception rather than the rule. EAs are faster to work with than reading a DCR and parsing the XML, so if there are fields that are needed in external tasks and the additional 1-100 millisecs for the parsing of XML is important, then you may want to keep a field as an EA.

Generic text fields as EAs tend not to work well, care needs to be taken to verify that special characters, spaces, etc, do not break anything.

What fields do you have in the DCR that you would consider leaving as EAs.

Annad

I have only the title, description, date modified and date issued.
The only place thre are being used is when the aspx page is generated through the TPL. But I can easily access the DCR fields in the TPL.

Thanks,
Anna.

nipper

You can run it either way, but I would just leave them in the DCR. If you are concerned about the performance of the external tasks to process that information (or is it just going via DataDeploy to the DB) then making it an EA will help. Unless your loads and volumes are so great, that should not be an issue.