Architecting, installing and maintaining your SAS environment

Dashboard Usage

Reply
New Contributor
Posts: 3

Dashboard Usage

Our department has created various dashboards.  We've been asked to see if there is a way to see how much usage the dashboards are getting.  Also, is there a way to tell what users are logging in to view the dashboards?

 

We know how many users have been granted access, but we want actual numbers on the usage.

 

I've looked at the knowledge base plus also at various log files, but so far no luck.

 

We are on SAS 9.2.

 

Thanks...Mundo

PROC Star
Posts: 1,322

Re: Dashboard Usage

How are the dashboards produced, i.e. BI Dashboard, BI stored process, WRS, VA, or ...?
New Contributor
Posts: 3

Re: Dashboard Usage

Directly from our developers:

 

"We use BI Dashboard 4.3.  For drilling down on indicators, we set up our links as stored processes that open in a new window."

 

Mundo

PROC Star
Posts: 1,322

Re: Dashboard Usage

I don't know BI Dashboard.  But would suggest this related thread which explains different approaches for processing logs, I would think Dashboard usage would show up in some of this logging data discussed:

https://communities.sas.com/t5/Administration-and-Deployment/RE-How-to-track-who-accessed-what-table...

Also references this nifty paper:

http://support.sas.com/resources/papers/proceedings14/1247-2014.pdf

 

Honestly I haven't explored this logging much (I'm not an admin).  As a developer, for some home-grown logging of the usage of stored processes I wrote, I soemtimes have the stored process write append a record to a permanent log dataset each time the stored process is called, storing the name of the user, parameters passed, and some other info.  It's a quick and dirty way for me to keep track of who is using them, how often, etc.

Trusted Advisor
Posts: 1,321

Re: Dashboard Usage

Thanks @Quentin for mentioning @TriciaAanderud and my "nifty" paper Smiley Happy

 

@Edmundov - here is a link to the Audit, Performance and Measurement package that collects the data that you are after from the ARM log files. The package is very useful as it has some predefined SAS code that you can further customise. https://support.sas.com/rnd/emi/APM94/index.html With the release of SAS 9.4 and Environment Manager, this is now not available as a download and I'd suggest you contact SAS Technical Support.

 

Kind Regards,

Michelle

New Contributor
Posts: 3

Re: Dashboard Usage

Posted in reply to MichelleHomes

I want to thank everyone for your suggestions.  The current log files don't appear to gather the information we're looking for so we might wait until we upgrade to 9.4 to see what our options are.

 

Thanks again.

 

Mundo

Frequent Contributor
Posts: 134

Re: Dashboard Usage

On 9.2, as mentioned by Quentin you can try to install the APM kit thus enabling audit reports. I am not sure this tool also covers Dashboard usage : let's hope it does ! If not, then I'll suggest three workarounds :

 

  1. locate the Dashboard log file(s) ( probably : <MidTier Server SASCFG>/Levn/Web/logs  with backslash on Windows)  and code or re-use some parsing SAS scripts that retrieves the relevant information - if this information is logged at all ! Then with a Stored Process or even Infomap/WRS you'll be able to create the reporting you need

2. As suggested below, try setting up a dedicated log file(s) using Log4SAS API in order to record the information (if 1. doestn't provide it already) and add a parsing script in the same manner as 1.

 

3. [more burdensome but effective if done properly] for each Dashboard  add a small invisible Stored Process  that records each access by creating an empty flag file named accordingly, like <MetataData Session or instance PID>_<account>_<Dashboard name>_<etc.>_<STP PID>_<TimeStamp>.log. Then with a small SAS script, you collect every now and then the flags and loads the information into some SAS tables etc. The STP code doesn't change, it is a small macro program that prints the macro parameters into a filename on a specific folder.

You'll have to set a systematic naming rule for each Dashboard if you try to set up this, it helps.

 

 

 

 

 

 

 

Frequent Contributor
Posts: 106

Re: Dashboard Usage

[ Edited ]

I was going to suggest something very similar to @ronan, but even simpler. You do not need to wait for 9.4 and you do not need to change any of your stored process code.

 

 

In your STP autoexec_usermods, issue a libname statement and define a dataset somewhere called auditlib.stp_&syshostname._&sysjobid., defining the variables you want to collect for each stored process execution. Something like this should work:

 

libname audits "/some/storage/somewhere";

data audits.stp_&syshostname._&sysjobid.; length a_username a_programname a_someparam $100; length a_timestamp 8; run;

 

Make sure that you use a hostname/pid reference in your table so that you avoid multiple processes trying to lock the same sas table. 

 

 

Then, in Management Console, within the metadata config for your stored process server context, you can define a SAS program that runs and appends the parameters you're after to your audit table that you just initialised in your stp autoexec_usermods, before each requestThis page also shows you how to alter this per-request metadata config:

 

initprogram.PNG

 

 Something like this will do for your initialisation program:

 


data appendme;
  length a_username a_programname a_someparam $100;
  length a_timestamp 8;
  a_username="&_METAUSER";
  a_programname="&_PROGRAM";
  a_someparam="any specific identifier that you pass to your stps";
  a_timestamp=datetime();
  output;
run;
  
proc append data=audits.stp_&syshostname._&sysjobid. base=appendme; 
run;

 

Whenever you want to run your audit reports, you can create a unifying view of all of your audit tables (one for each session). This will give you what you want, is much easier than installing APM, and with far less performance overhead. If you create an overarching view, you can even create a dashboard to report on this stuff in real time.

 

HTH

Nik

Ask a Question
Discussion stats
  • 7 replies
  • 463 views
  • 4 likes
  • 5 in conversation