You were really really close. There are a couple of issues with your iRule...
Findstr usage
The usage of findstr is this:
findstr
You are using it like this:
findstr
Switch the two paramters around and you are half way there.
The next problem is with the skip count parameter. You are putting in 7, but "category=" is 9 so after you switch the paramters, your extracted string will be "y=XXYYZZ" when you really want it to be "XXYYZZ". Change the skip count to 9 and you should be all set.
I tested this iRule and it seems to work in my setup.
when HTTP_REQUEST
{
if {[HTTP::path] == "/searchcombined.asp" }
{
set CategoryID1 [findstr [HTTP::query] "category=" 9 "&"]
if {$CategoryID1 != ""}
{
set CategoryID2 [findclass $CategoryID1 $::CategoryIDs " "]
if {$CategoryID2 != ""}
{
set qstring [string map [list $CategoryID1 $CategoryID2] $qstring]
}
}
HTTP::respond 301 Location "http://[HTTP::host]/common/search/SearchResult.aspx?$qstring"
}
}
Data Group Naming
With that being said, I had to rename my data group to "CategoryID
s". In your post you named your data group "CategoryID". I assume this is just a typo but if not, you'll need to either rename your data group or change the value in the findclass command.
301 redirect
You'll need to put a "?" between your new URI and the $qstring variable.
One more thing...
Actually, possibly one more issue would be with the fact that you are issuing the HTTP::respond regardless of whether CategoryID1 is extracted from the URI or CategoryID2 is pulled from the data group. Maybe this is your intention, but thought I'd point it out. You could end up with redirects going to the SearchResult.aspx page with the original [HTTP::query] value.
In the future, I'd recommend throwing in a bunch of logging after every line where you assign or lookup values. That way by looking in the /var/log/ltm file it's fairly easy to diagnose where the logic breaks in your iRules. Then when things are working, comment it out for production use.
Hope this helps...
-Joe