LogStat function undocumented. Cannot populate the count field

[anavarro]

Hi All,

I have been trying to populate the sp_log table from my widget and since it is an OOB table I thought I would give it a go with $sp.logStat('param1', 'param2', 'param3', 'param4') that I have seen other OOB widgets use.

I have been able to figure out that param1 populates type field (string), param2 populates table field (table name), param3 populates ID field to the record on the table (sys_id), param4 populates Text field (string).

However I cannot find any parameter to populate the Count field on the Service Portal Log Entry records, although I can see plenty of records with type 'search' that have this field populated.

How is this being accomplished and can I avoid creating my own log function to achieve the same?

Thank you

[Jace Benson]

I'd avoid using this stuff until SN documents their stuff.

Also the numbers they trackwith this function don't make sense.  I've already opened a HI ticket about the dashboard not adding up correctly when doing searches and such.  It's been open for months.

I've posted about the lack of the documentation: https://community.servicenow.com/community?id=community_question&sys_id=716f76a9db58dbc01dcaf3231f96...

Maybe they'll respond more to more feedback so please share this issue with the teams that do the documentation.  I'm not sure if its two groups or one but both Docs and Developer are missing this so submit on both.

Docs (feedback bottom middle after you're logged in): https://docs.servicenow.com/bundle/kingston-application-development/page/app-store/dev_portal/API_re...

Developer (feedback top right after you're logged in): https://developer.servicenow.com/app.do#!/api_doc?v=jakarta&id=c_GlideSPScriptableScopedAPI

[anni-h]

Which numbers in particular have you found do not make sense?  Are you referring to the number in the "Count" field or the counts of sp_log entries for searches?

I've definitely found the sp_log table less than fully intuitive to interpret, and not quite focused where we need it (on user activity). When I've tested searches that I know return 1 or zero returns, the resulting log records match in that I'll see a Type=search with Count=1 or 0 as matches my portal search results, and if I did a search in a widget that searches both catalog and kb at the same time, I'll see two sp_log records, one of Type=search logged for each table.

My hope was to be able to extrapolate from that very manageable test+result to trusting the entire data set... I'm curious what you've run into.

My main complaint is that the one search from a widget instantaneously searching two tables logs two records even though the user entered one search so while it reflects activity with all that information, it's inaccurately reflecting actual user activity. At the volumes of portal activity, us parsing all that log data based on timestamp is way too much effort (I think) to be worth it. On the flip side, if the one search of both tables were logged in one record, including all involved tables in the one record would not result in easier/better report building per se, just a different focus. So we do look at this data but use it on relative terms over time.

[Jace Benson]

Everytime I've tried to make heads or tails of the data on sp_log it's been pretty useless.

I know I have a outstanding PRB1246448 with SN HI atm about it.  So if I want to track usage I guess its on me to make that happen.

This it the meat of my hi ticket, but yea, because of it I'd steer clear.

take the following scenario's into account;

1. Search on the landing page, type in access, press enter.

-- What do you think should show up in this case on the sp_log table?

-- A result that the "search" page was queried for "access", however the only record that gets generated is that the search page was accessed, not what it was searched for.

2. Search on the landing page, type in access, click on one of the type ahead catalog items.

-- What do you think should show up in this case on the sp_log table?

-- A result that a search was used on the index page perhaps, and then when the next page loads, the sc_cat_item and/or the catalog view page loaded?

3. Search on the landing page, type in blaze, click on "Search the KB for blaze".

-- What do you think should show up in this case on the sp_log table?

-- A result that a search was used on the index page perhaps, and then when the next page loads, the kb_search was used with the term blaze.

I guess what I'm trying to say, is it's unclear how this is supposed to work but if you look at the usage overview, it appears as if i'm supposed to see search terms, (i'm not seeing that) and i'm supposed to see other things but it's not clear what i'm supposed to be seeing.

[anni-h]

Is it possible that three of the parameters change based on what the first parameter is? Looking at our sp_log table, depending on the Type, different fields get logged, apparently never more than 3 more (other than basic system stuff like timestamps). Type=search never logs a Page, Type=page_view never logs a Text or Count.

As @jacebenson notes, though, without formal documentation it's all kind of speculation. And with or without documentation, it's somewhat subject to change, but a sudden change would be unfortunate given the nature/purpose/needs of reporting on such logs.