Detailed use of Sessions

Question

An SDK user recently sent me this query:
So I wrote this parser:
instance.PARSER.assemble = function() {
var idx = 0; // table index
---SNIP---
return true;
I still don't understand when to use "this.PARSER.xxx" and
"instance.PARSER.xxx" or "Record.prototype.xxx".
I guess that's my main problem at the moment (understanding the laxness
of ECMA script - I'm used to use JAVA, C++ and all that stuff)
Also I don't get it which info to put into the newEvt and which one
into sessRec[0]...
And I also don't get when to use the "legacy" attributes and when the
"new ones" (like evt vs EventName) ...
DCorlette
DCorlette's Profile: http://forums.novell.com/member.php?userid=4437
View this thread: http://forums.novell.com/showthread.php?t=449867

Answer 1

And here was my (long-winded) response, which has some details that
folks might find interesting:
1) When the Collector initializes, it creates a few global objects to
keep track of, well, global things.
- One such object is 'instance', which is of class 'Collector' and
represents the actual running Collector instance. We put lots of other
stuff, like the state of parameters, caches, and other "in-memory"
objects into 'instance' as a convenient place to store them (so
'instance.MAPS' holds our maps, for instance).
- In the main Collector loop, we also create (and delete) a couple
other global objects, one of which is 'rec', which represents the next
inbound log record (class 'Record') from the event source.
- Also we create 'e' which represents that output Sentinel event
(class 'Event') that is currently being constructed.
2) In 'normal' Collector flow, the basic idea is that you take the
input record ('rec'), chop it up into pieces (and typically we store
that parsed data back as new attributes of 'rec') and normalize the
data, and then call a conversion routine to "convert" the 'rec' into
'e'. In other words, with rare exceptions you really shouldn't modify
'e' directly, instead you do all your partial parsing on and in 'rec',
and then the conversion to 'e' is dictated by the Rec2Evt DataMap.
3) Also just to make sure this is clear, methods that are declared as
prototypes on a class are members of that class, essentially, sort of
like normal member methods on a Java class. So if you have 'rec', and a
method Record.prototype.foo(), you can call rec.foo() and you'll end up
in a member method (and 'this' will refer to 'rec'). So in general if
you call the method from 'rec' it's a Record class member, from
'instance' it's a Collector member method (and 'this' will be
'instance', and from a Session object (like 'sess' in my example) it's a
Session member method (and 'this' will be the Session).
So you made a comment: "And I also don't get when to use the "legacy"
attributes and when the "new ones" (like evt vs EventName) ..."
The answer here is that the "long" variable aliases are recognized
attributes of the Event class. In most cases, you will NOT access them
directly so it would be somewhat unusual for you to actually write them
in your code. The 'short' tags you're talking about are probably
attributes of the 'rec' object, and those are just temporary variables
you create to hold the partial results from your parsing - they can
actually be anything you want, can be nested into deep structures if you
wish, etc etc. We happen to use the Sentinel internal field names for
convenience and because it helps to indicate (sometimes) the purpose for
which we intend to use that parsed data later on. Ultimately, the only
place you need to care about those 'rec' variables is when you construct
your Rec2Evt.map file that describes how a Record can be converted into
an Event - you'll see those Sentinel long field names on the left (the
*target* Event fields) and you put whatever Record attributes (again,
array references and deep structures in the Record are supported) on the
RHS.
When you're dealing with a Session, however, things get a little wonky.
First of all, you don't have the "simple" logic of 1-1 map from Record
to Event, so in general you don't end up using the global 'e' object as
your output Event (the main loop is typically short-circuited before
e.send() is called). Second, we play some tricks to allow you to
construct Sessions in re-usable ways. Let me explain this second point
first:
A) So, as you know we have a defined Session class. A Session will hold
some number of input Record objects (N+1, since Record [0] is an empty
Record), which then will need to be re-assembled, or parsed, or
summarized, or something. We don't know in advance. As a result, there's
no way we can pre-define a method by which the Session will be parsed -
that's up to you, the developer. So how do you do that?
Well, the first option would be for you to define a *prototype* method
on the Session object. Then when you create a Session in your code, that
method will be available as a prototype. But that can be a little tricky
- we have some scenarios where there are different Session types that
require different parsers, or that the parser may need to be modified
mid-stream. Our solution therefore is to have you create some number of
generic "Session" parsers, essentially as anonymous methods that aren't
attached to anything in particular. For convenience (so we can find them
later), we recommend you put them in the instance.PARSERS bucket, where
there could in fact be other parsers (like SQLOffset parsers). But at
that point the parsers are kind of disembodies parsers that can't really
be used to do anything yet.
At runtime, when you create a Session object, you then determine which
Session parser makes sense for the type of Session you are creating, and
you use the addParser() method to attach one of your stored Session
parsers to the Session. That parser then becomes the canonical parser
for that Session (although you could swap it out later if you wanted
to), and will automatically be called when the Session expires.
B) The second wrinkle is that since you don't have the simple 1-1
Record to Event logic, you have to re-create some of that basic logic
yourself. Your Session parser actually runs in the Session namespace,
and hence 'this' is the Session itself - underneath that you have
sessRecs[0] (a blank record) and sessRecs[1] - [N] which represent the
stored input Records. The general idea is that you would take the bits
and pieces you need from sessRecs[1]-[N] and copy that data into
sessRecs[0] (so it becomes your staging area for parsed data), but
that's optional - you could do it other ways if you really want. For
example, if you know that most of the data you need is already parsed
and in sessRecs[1], then you can just say sessRecs[0] = sessRecs[1], and
you have a copy of the starting record.
The Session object itself has a special send() method that essentially
takes sessRecs[0] and converts it into an Event, but again you don't
have to use that logic if you don't want to. In fact, you could create
multiple custom Rec2Evt DataMaps, multiple output Events from a single
Session, any sort of manipulation is possible. But if you want the
simplest approach, just make sessRecs[0] look like a complete input
Record, and use Rec2Evt.map to define the conversion, then use the
Session.send() method to send it (you need to pass in an Event that has
things like the DeviceEventTime preset, however).
Hope this helps!
DCorlette
DCorlette's Profile: http://forums.novell.com/member.php?userid=4437
View this thread: http://forums.novell.com/showthread.php?t=449867