Hit List Remote Reports
With Remote Reporting, if you are running your web server
with Microsoft IIS, O'Reilly WebSite, or any NT version of
Netscape, you can generate remote reports from anywhere in
the world, via the Internet, without buying any additional
software. This is one of Hit List's most convenient features
as it can greatly assist companies whose travelling or telecommuting
employees need access to reports.
If you are planning to use Remote Reports, there are four
issues you need to understand:
1) Setting up and enabling Remote Reports;
2) Deciding which type of reports to allow remote users to
run;
3) Setting up Hit List Remote Report security; and
4) Performance issues.
1) Setting up Remote Reports and Troubleshooting
First, you will need a Win-CGI capable webserver on your
Hit List machine. At this writing, such webservers included
Microsoft IIS and Microsoft Personal Web Server, Netscape,
and OÍReilly Website. As of this writing, Apache and Lotus
Domino do not support Win-CGI and thus while Hit List can
certainly analyze these webserversÍ log files, they cannot
be used to serve up Remote Reports.
Next, when running Hit List Setup, you will see a checkbox
for Remote Reports in one of the first dialog boxes you
see. If the checkbox is grayed out, Hit List did not detect
the webserver on your machine and you may want to verify
that you have one of the above-mentioned Win-CGI capable
webservers on your machine.
Setup will simply install a small connector application
to link this webserver to the Hit List engine. This connector,
a small Win-CGI application, is only invoked when someone
is running a remote report. It will not interfere with
your webserver.
If for some odd reason Hit List can't detect the webserver
(and thus make the settings available during Setup to
install Remote Reports) AND you are using one of the Win-CGI
capable webservers discussed above, you might also use
this checklist to make sure everything gets in there correctly
(or to "manually" install Remote Reports).
1. Make a subdirectory under your home directory like
/stats.
2. Copy all .htm files in "\program files\marketwave\hitlist"
to above dir EXCEPT mwhlrrl.htm
3. If running O'Reilly WebSite or Netscape, copy RunHL4xx.exe
to your WinCGI directory. For Netscape, you'll have
to create this. If running IIS, copy RunHl4xx.exe AND
IS2WCGI.DLL to your /scripts directory. If IIS, rename
IS2WCGI.DLL to the same base name as RunHL4xx.exe (like
RunHL40e.dll).
4. Copy mwhlrrl.htm to the same directory as RunHL4xx.exe
went.
5. Open all the .htm files and look for references
to: FORM ACTION="http://www.mycompany.com/Scripts/RunHL.dll
Change these to point to the .exe copied above (or
dll for IIS users).
For example:
FORM ACTION="/Scripts/RunHL40e.dll (for IIS)
FORM ACTION="/Scripts/RunHL40e.exe (for Netscape or
O'Reilly).
6. Create a directory under the webserver's Scripts
directory with the .exe/dll called MWGraphs and give
users READ (not Execute) access to this directory.
Error: I keep getting "document contains no data",
"server error" or "the server returned an unrecognized
response" when I run Remote Reports?
This can be caused by a number of things:
1) You didn't install Remote Reports properly. Check
the "manual install" checklist seen above to verify that
the components are in fact in their correct locations.
2) The webserver has strict restrictions on file access.
Check to make sure the file restrictions on the webserver
(which can be in addition to NT's) mimic those seen
in the "manual install" document seen above. If you
don't have anonymous access enabled to the webserver,
it likely won't work (but you'd likely see other problems
prior to this as well).
3) Check the error log. Netscape actually produces
its own error log, which you can open in Wordpad and
examine for clues as to why things are not working correctly.
Microsoft IIS writes its errors to the NT Event log,
which you can look at in Event Viewer.
4) After trying a few report attempts from HLEZ.htm
(the simplest and quickest of the Remote Reports) if
you see one of the above errors, do a windows Find for
"cgi" (without quotes) on all local drives. If you DO
see any cgixxxx.tmp files (where xxxx represents random
number/characters) Remote Reports are working, but something
else is going wrong - contact Marketwave Technical Support for help
at this point. If you DON'T see any cgixxxx.tmp files
on the computer's drives, IIS is probably trying to
write them to a drive or folder that isn't allowing
such activity. Go to step 6 below.
5) If you see a "error opening database" error message,
this means you haven't set up the default database against
which Remote Reports are intended to run. Open the Remote
Report Security Manager from the Hit List main screen,
highlight the Group in the upper right you are working
with, (usually Administrators initially) and then check
the box "set domain and database permissions" and hit
the Change button. Now, hit New and select the database
that you intend Remote Reports to run against (whether
Access or ODBC) and then hit OK and OK again, and try
the Remote Report again.
6) Make sure your System Temp folder isn't in a drive
that is "protected" from access. We have seen some customers'
IIS installations that were trying to write the win-cgi
tempfiles to the \winnt folder, which as you might expect,
was protected from access and thus their Remote Reports
weren't working. You can create a "System" Temp variable
in the Control Panel/System/Environment applet to get
around this potential problem, then reboot the computer
and try again.
2) Using Remote Reports
Which type should I use?
There are three types of remote reports that you can
give users access to.
The first type is called Pre-Defined Remote Reporting,
which allows your users to simply run reports that
are already defined in Hit List (such as Complete
Analysis).
The second type is called EZ reporting, accessed
via the HLEZ.htm, which allows users to custom design
their own simple queries It is the best choice when
users need to make simple, customized reports on single
calculations only.
The third type is called Ad-hoc reporting,
accessed via the Hitlist.htm, which allows your remote
users to get as complex as they would like by choosing
all the calculations manually.
Once Hit List is properly installed and you've created
a database, you are ready to test Remote Reporting,
probably starting with Ad-hoc or EZ reporting.
When using Remote Reports, Hit List will generate
a very complex ñscriptî for the server to execute.
That script is encoded as an HTML file. Hit List will
launch your web browser with that script and, when
you click OK on the form, it will submit the request
to your web server. When your server is done generating
the report, it will be sent back to the browser. Unfortunately,
there is no way for your browser to be updated with
status information as the report runs.
Where are the files and how to I access Remote Reports
through my browser?
In a "typical" install of Remote Reports, these html
files are located in the Stats directory under your
wwwroot, so the URL you'd usually type in your browser
to access them would be something like:
www.yourcompany.com/stats/login.htm [Pre-Defined
Remote Reporting] (or)
www.yourcompany.com/stats/HLEZ.htm [EZ reporting]
(or)
www.yourcompany.com/stats/hitlist.htm [Ad-hoc reporting]
You may remember that Setup prompted you about putting
these files in this location, and you may have put
them in an additional location as well, in which case
you might try that alternative.
What reports should I run first?
ItÍs probably a good idea to start out with simple
Ad-Hoc or EZ reporting, to get a feel for how itÍs done.
Next, move to simple reports like ñExecutive Summaryî
that will run quickly. Finally, remember that you can
customize Pre-Defined reports when directly in Hit List,
and then make a few, some or all of those reports available
to the various Groups and Users you set up in the Remote
Report Security Manager.
3) Remote Reports and Security
Central to every webmaster's daily activities are security
concerns. Hit List includes a complete Security Manager,
so that only users that you give specific permission to
will be able to run Remote Reports. Go to Tools/Remote
Report Security Manager (or hit the ñSecurityî button
at the top of the Hit List main screen). This is where
you specify who gets to see (and run) what types of reports
in the Remote Reports interface.
It is most common to give the System Administrator (possibly
you) access to all reports remotely, while restricting
other Users to a limited subset of reports. Much like
NT security, Hit List supports security groups, which
can be used to further restrict access by Guest accounts.
Just set up a Group in the upper left, then its Users
on the right, then with the Group name highlighted again
check the boxes for the reports that Group can run. Or,
with the particular User highlighted on the right, you
can switch to the User properties tab and make this user
a member of any Group you want, also setting this userÍs
Password.
You can also control what databases the Ad-Hoc interface
runs against by filling out the ñdefault ad-hoc databaseî
setting near the bottom of the Remote Report Security
Manager dialog box. Note that the database(s) that the
Pre-Defined Remote Reports run against (ie Complete Analysis)
are set within the actual reports from the Hit List main
interface by clicking Design and going to the Database
tab (or by default under Options/Database). If you want
even more control over who gets to see what database,
you can use the ñset domain and database permissionsî
setting to control specific domainsÍ visitors getting
to use specific Hit List databases. Just hit the ñchangeî
button and enter these settings as desired.
It is important to note that Ad Hoc Reports are automatically
filtered so that they only retrieve data that relates
to the server that answered their request. For example,
if someone uses HITLIST.HTM from www.VirtualServer1.com,
all data will be linked to that server. Because of this
filtering, no remote user can see data from any virtual
site you host. So, youÍd have to make this Domain be able
to see the Database for other sites by using the ñset
domain and database permissionsî setting as discussed
above.
As you have already seen, there is a "Guest" account
in the RRSM that by default has no password. There is
also an Administrator account that has complete access
with the password "hitlist". You may want to make changes
to either of these or add new accounts with different
passwords and levels of access.
Remember that ultimately NT security will "trump" Hit
List, so if you have fairly tight security on the NT computer
you're using for Remote Reporting, you may need to make
some adjustments to let the appropriate people access
the desired reports.
4) Performance Issues with Remote Reports
Running Remote Reports can impact your web server's performance.
However, you can minimize this by having Hit List run
as a low-priority task. To do this, set the Priority setting
in Options/Advanced to ñLowî.
This means that all other applications, including your
web server, will have a higher priority than Hit List.
This will keep them responsive, even when Hit List is
running. However, if nothing else is happening on your
server, Hit List will run just as fast as when it is using
the Normal priority setting.
When using Remote Reports, you can ensure better report
performance by removing report elements that are especially
slow to calculate. For example, you can remove complex
report elements like Path thru Site, Jumps within the
Site, Previous Pages, etc. You also might consider removing
the check for looking up site names. Remember that you
can create as many different versions of the form as you
like, making it possible to offer different people different
options.
|
