TeamSite Submit Reports

Hello!

Let me preface this: We don't have TeamSite Reporting, and it isn't an option (already been explored and its just not in the budget).

That said... how can I obtain the information contained in Submit Logs for a given Workarea (Properties > Submit Log). I'd like to have both the count of items submitted, and whether it was an addition, deletion or modification. I've tried looking at the iwevent.log file, but doesn't seem to have this detail in it -- that I can understand anyway.

I've tried finding this on my own and have failed... any advice would be much appreciated. My end goal is this: I need a count (by user if possible, but not necessary) of how many items were added, modified or deleted (and this a total number of items submitted) in a month -- reported on monthly. That's it. I've gotten some very raw numbers from the event log, but it counts a directory full of things as 1, which isn't accurate obviously.

Thanks
-mike

Find more posts tagged with

Comments

Adam Stoller

Hello!

Let me preface this: We don't have TeamSite Reporting, and it isn't an option (already been explored and its just not in the budget).

That said... how can I obtain the information contained in Submit Logs for a given Workarea (Properties > Submit Log). I'd like to have both the count of items submitted, and whether it was an addition, deletion or modification. I've tried looking at the iwevent.log file, but doesn't seem to have this detail in it -- that I can understand anyway.

I've tried finding this on my own and have failed... any advice would be much appreciated. My end goal is this: I need a count (by user if possible, but not necessary) of how many items were added, modified or deleted (and this a total number of items submitted) in a month -- reported on monthly. That's it. I've gotten some very raw numbers from the event log, but it counts a directory full of things as 1, which isn't accurate obviously.

Thanks
-mike

There are a number of ways to approach this - If you're sure nobody every calls iwsubmit directly - you can collect data from your workflows, if someone does (or might) call iwsubmit directly - consider looking into creating an iwat trigger script to collect the data you're looking for - once you figure out how to collect the data - then you need to figure out how to store it for latter accessing to generate the reports.

carnix

There are a number of automatic scripts that use iwsubmit calls, though no one manually logs in a does iwsubmit (I'm the only one with console access to the TeamSite server). The reason I want to know by user is to differentiate between these automatic submits and human user ones (auto submits are always done by SYSTEM), but its not of absolute importance.

You lost me on the iwat trigger script thing, I'm not familiar with that. Can you (or someone) elaborate?

Its seem to me, though, that if the data can be gotten at in the GUI there must be some way to get at it via a CLT or something... Having a script that runs every night, or even every hour, to log away that data is fine if its not data that is stored in a long-term way.

Thanks
-mike

nipper

So there are triggers on specific events. You can run a certain script when a specific event happens, like iwsubmit. If you only want reports from data submitted via workflow, then you can add an external task to log the information.

Are you on Unix or DOS ? On DOS the command is
iwat -help
usage: iwat [-h] [-v] [-s servername] eventpattern program

On Unix, you *used* (in TS 5.5.X) to modify the iw.local file with similar information. I do not know if that is still the case or if iwat is the prefered way now.

Andy

Adam Stoller

There are a number of automatic scripts that use iwsubmit calls, though no one manually logs in a does iwsubmit (I'm the only one with console access to the TeamSite server). The reason I want to know by user is to differentiate between these automatic submits and human user ones (auto submits are always done by SYSTEM), but its not of absolute importance.

You lost me on the iwat trigger script thing, I'm not familiar with that. Can you (or someone) elaborate?

Its seem to me, though, that if the data can be gotten at in the GUI there must be some way to get at it via a CLT or something... Having a script that runs every night, or even every hour, to log away that data is fine if its not data that is stored in a long-term way.

Thanks
-mike

Read the CLT manual and search DevNet for information about iwat

There is the iwevents CLT which might do what you want - you can read the CLT manual for that too.

pdasarat

Yes we use iwevents -s vpath all and then parse through the output and report the same. -u flag refers to all update

John742

You can also use the predefined command trigger -> iwatsub to grab the already set variables for the event and append to a custom log

carnix

I spotted it at the bottom, sorry, I was looking in the wrong place for iwat commands.

Still. I created a simple logging Perl script based on the code from the sample script in the manual. The idea being it would simply take all the ENV variables and dump it to a TAB file I can use to collection the data for later reporting.

I use to following command:
>iwperl

/Interwoven/TeamSite/iw-home/bin/iwatsub.ipl

/Interwoven/TeamSite/iw-home/local/bin/care/tsEventLogger.ipl

And it just sort of hangs (which is expected). But, when I submit a file, nothing shows up in the TAB file (I validated the perl script with use strict, no errors). This isn't the way I would normally pull ENV, but its the way the sample script did it (the second one, replication).

When I say nothing shows up, I mean the file isn't modified. When I run the script standalone, the file is appended with a bunch of tabs and a new line (blank values) which means the probably isn't with the logger script, but elsewhere....


#!d:/Interwoven/TeamSite/iw-home/iw-perl/bin/iwperl
use TeamSite::Config;
use strict;

$| = 1;

my $IW_EVENT = $ENV{'IW_EVENT'};
my $IW_TIMESTAMP = $ENV{'IW_TIMESTAMP'};
my $IW_EVENTLINE = $ENV{'IW_EVENTLINE'};
my $IW_EVENTUSER = $ENV{'IW_EVENTUSER'};
my $IW_EVENTROLE = $ENV{'IW_EVENTROLE'};
my $IW_WORKAREA = $ENV{'IW_WORKAREA'};
my $IW_SUBMITID = $ENV{'IW_SUBMITID'};
my $IW_EDITOR = $ENV{'IW_EDITOR'};

#Also tried this from the other script, after initializing blank scalars to validate under strict:
#use Env qw(IW_EVENT IW_TIMESTAMP IW_EVENTLINE IW_EVENTUSER IW_EVENTROLE IW_WORKAREA W_SUBMITID IW_EDITOR);

my $iwhome = TeamSite::Config::iwgethome(); chomp $iwhome;

open(IWEVENTS,">>$iwhome/local/logs/iweventlog.tab");
 print IWEVENTS "$IW_EVENT\t";
 print IWEVENTS "$IW_TIMESTAMP\t";
 print IWEVENTS "$IW_EVENTLINE\t";
 print IWEVENTS "$IW_EVENTUSER\t";
 print IWEVENTS "$IW_EVENTROLE\t";
 print IWEVENTS "$IW_WORKAREA\t";
 print IWEVENTS "$IW_SUBMITID\t";
 print IWEVENTS "$IW_EDITOR\n";
close IWEVENTS;

exit;

Adam Stoller

Please read the manual again - carefully.

iwatsub needs to be launched as a service
iwat gets registered within the backing store and does not require the overhead of being launched as a service.

iwat****.ipl launched scripts look at environment variables (%ENV).
iwat lunched scripts look at command line arguments (@ARGV).

I recommend iwat over iwatxxx any day - it's a much cleaner model for implementation IMO.