The reporting function needs the following
modifications/fixes before being used to generate
reports for delivery to providers:
1. Main loop in ReportManager.generateReportsByPeriod()
should defer calling logSession.setReported() (which is
currently being called in
generateReportsForResourceAndPeriod() until the session
has been reported for all resources affected by the
session. At present each session only gets reported
for one resource, even though many resources may have
logRecord entries for the session. The simplest way to
handle this is to defer all calls to
logSession.setReported() until the end of
generateReportsByPeriod().
2. I think that there is a similar problem in the way
that the PortalUsageManager gets
ReportOverviewDataBeans to build the
PortalUsageOverview data. Since each session may
include data reported for many different resources,
there may be results from a number of different
resource reports to combine to make a portal usage
report. In fact many of the numbers reported for each
resource cannot be added together (e.g. the count of
taxa displayed is unlikely to equal the total of this
value for all indiviual resources, since several will
include the same taxon). It is therefore better just
to generate the portal usage overview as a separate
step in the ReportManager (see below).
3. There is another category of logRecord which is
currently not being processed. We have two classes of
Service (distinguished by serviceserviceclasskey):
specimen/observation records (for which there is a
Resource associated with every record) and taxonomy
records (for which there are no resources). If you
look at the old routines in DatabaseLoader you will see
that the loop for generating reports ran twice, once
for the resources and once for the services without
resources. I think that some simple changes to the
ReportManager would allow you to do the same there. In
fact it may make sense to treat it as three loops (or
three passes through the data), once for the resources,
once for the services without resources, and once for
the portal as a whole. These call all be stored in the
same table with the first set having values for both
reportservicekey and reportresourcekey, the second set
having values for reportservicekey and 0 for
reportresourcekey, and the third having 0 for both.
Most (all?) of the BitSet code should work the same in
all cases and then the sessions can be marked as
reported after all is complete.
4. When reporting eventtype 6, the count stored should
not be the number of taxon keys found, but rather the
total of the logrecordcount values for all logrecords
with distinct combinations of taxon key and resource
key. This is a little messy, but I think that the
following will do for all practical purposes (bitNumber
could collide for different combinations of taxon key
and resource key, but it is unlikely) - unless you see
a problem with it:
BitSet recordsOfferedSet = new BitSet();
int recordsOfferedCount = 0;
. . .
case 6: /* Records Offered */
// Not perfect but close enough
int bitNumber = logRecord.getTaxonKey() *
logRecord.getResourceKey();
if (!recordsOfferedSet.get(bitNumber))
{
recordsOfferedSet.set(bitNumber);
recordsOfferedCount += logRecord.getCount();
}
break;
