Find sitecore items with a specific OMS profile?

Question

I have to find all items in Sitecore (or rather, in the contents) that have a certain OMS (marketing suite) profile checked in the "Tracking" attribute. The Tracking attribute appears to be stored as XML and has a raw value like

<tracking>
  <profile name="Widdly Scuds"><!-- some irrelevant keys... --></profile>
</tracking>

and I need to fetch, for example, all items with the "Widdly Scuds" profile.

The first solution I thought of was fast query over the Tracking attribute. Sitecore query or XML would have to crawl the entire contents each time, which would probably be unacceptably slow, but I'll try it if there are no alternatives.

This is the first fast query I tried:

fast://*[@Tracking = '%Widdly Scuds%']

but that returns 0 results. So I tried this:

fast://*[@Tracking = '<tra%']

and this (which would match the names of many of the profiles:

fast://*[@Tracking = '%A%']

And those also returns 0 results. I'm not really certain how Tracking is stored or queried, but it appears to be unusual since I can't get any results from it by any means.

The query needs to be fast enough to run a few dozen times during a short page rendering (probably not more than 20-30 seconds). The results can be cached for awhile, but not very long. The front page of a section of the site I'm working on needs to display an item count for each profile I'm querying, and there will be, maybe, 50-ish profiles.

So, how do I quickly get all items with a certain marketing profile?

Edit: I ended up using Lucene. Details of that adventure to appear in future questions, maybe...

Answer 1

If you use query or iterate descendants, avoid starting the query from / if possible - start from the equivalent of /sitecore/content/someitem.

Another approach is to use a Lucene or other search index. See the Sitecore reference for more info.

Answer 2

Ugh, the Tracking field is actually stored as __Tracking. Whoops. So the query ends up being

 fast://*[@__Tracking = '%"Widdly Scuds"%']

This still has problems, as it's still trying to query XML via string operations and I may end up screwed later if a profile and key have the same name, but it works well enough for now.