Checking who's searching for what

Did you know the latest version of Content Manager allows you to store user queries in the workgroup server logs?  Imagine extracting from these logs a treasure-trove of anecdotal meta-data searching tips & tricks or insight into actual product usage.  You can get quick reports of who searched for what and when.

To get this going you need to modify the properties of your workgroup server(s).

The workgroup server has two properties that we need to enable: 

1. Enable logging on next deployment
2. Add user query strings to workgroup server log

Once you click OK you have to save and deploy.

This forces the server(s) to re-initialize using the new configuration.  I will see log files accumulating on the local server's application data directory.  If I use windows explorer I can navigate to it like shown in the image below.

If I open that file within Notepad++ I can see a lot of information.  I just want to focus in on the search queries though.  The search itself is surrounded by the pipe character (|).  Here's what my log looked like after a few quick searches.

Powershell is such a handy thing!  I created one that manages these logs files and extracts what I need.  I use a dictionary to track users, their queries, and relational details about the queries themselves.  For instance if the user searched by title, notes, or any word, I look-up other trim indexed words.  When the user doesn't use asterisks, I calculate what would have happened if they did.  I can then use this for targeted training one-on-one, or to guide the creation of updated training materials.

Take the first entry where I searched for "cli".  I was able to see that there were four indexed words containing "cli" (clinic, clinics, clinic-, and clinton).  Those 4 words are used a total of 57 times (not necessarily unique records).  Yet I, as the user, received 0 results.  The user would have received results when using wildcards. 

The really nifty part is powershell has a ConvertTo-Json command.  If I output the results to a json file within my webdrawer instance, I can consume all of this new information in other places.  Like maybe within webdrawer, during an audit, or as part of a health check.

Speaking of webdrawer and indexed words..... 

Don't let OLE DB slow you down

Out-of-the-box sounds good to most, but to a trained ear it screams "poor performance".  It could be the root cause of users receiving a "timed out" response when searching, or sluggish response when scrolling through search results.  A quick way to try and resolve this poor performance is to use a native driver.

When creating a dataset within the Content Manager Enterprise Studio we can either pick SQL Server or Oracle as our database platform.  Making a selection tells the solution which flavor of SQL to use, but not which driver to use.  You get to pick that on the connections tab, as shown below. 

Connection tab of my dataset properties

The very first thing written in that text box is the provider (driver) to be used when connecting to the database.  You can see here I'm using the SQLOLEDB.1 driver.  That's the default.  If I click the blue KwikSelect icon I can see the datalink properties dialog.  

Initial view of connection string properties

Clicking onto the Provider tab will show all of the available drivers.  The highlighted one is the currently selected one for the connection string.  So that "SQLOLEDB.1" equals the "Microsoft OLE DB Provider for SQL Server".  That's the generic one that comes with Windows.  It works but won't contain the unique features and refinements of your SQL Server version. 

Since I have the SQL Server Native Client available, I should be picking that!

List of drivers available on the local machine

Picking the native client forces me to click next and then re-enter my database details.  That's because I'll have new options and features available for my connection.  The interface changes slightly (and more options are available off the advanced tab).  I'll just re-enter what I had before and click OK.

Now if I save and deploy all is well.  If I have multiple workgroup servers I have to deploy the native client onto all of them.  I also have to match the native client version to the SQL server instance build (you should not use mixed builds).    Same goes for Oracle environments.

Don't take my word for it though.  Try it in your development environment and see for yourself (use a load test tool to simulate DB activity).

Renumbering Classification/Category Items

Another question over on the forum!  You can't easily renumber classifications via the thick client.  And you can't accomplish this particular change via DataPort (because it uses the level number as the unique Id), so time to break out powershell!

Add-Type -Path "D:\Program Files\Hewlett Packard Enterprise\Content Manager\HP.HPTRIM.SDK.dll"
 
$db = New-Object HP.HPTRIM.SDK.Database
$db.Connect
$classifications = New-Object HP.HPTRIM.SDK.TrimMainObjectSearch -ArgumentList $db, Classification
$classifications.SearchSTring = "top"
foreach ( $obj in $classifications ) {
    $classification = [HP.HPTRIM.SDK.Classification]$obj
    $newId = ([System.Int32]::Parse($classification.IdNumber)-1).ToString("000")
    $classification.SetProperty([HP.HPTRIM.SDK.PropertyIds]::ClassificationLevelNumberUncompressed, $newId)
    $classification.Save
}

In the script above, I find all top-level classifications and renumber everything down one number.  It works because I know my top-level numbering pattern. Here is my top-level pattern.

You can see on line 9 of my code that I am reducing the existing level number by one and then formatting that change to have leading zeros (for a maximum length needed by my pattern).  You'd need to work out the appropriate method for determining the uncompressed number, otherwise it's pretty straight forward.

This should give the OP some ideas as to how to accomplish his goal.