Anonymous_User Absent Member.
Absent Member.
453 views

RXMap field from collectors


Hi,
I am trying to understand better how RXMap field works in terms of
structure. It seems a field or structured variable which keeps other
fields which are usually parsed from event sources data. Well, that is
my understand.
I have tried to search it on so many .js files of native collectors but
I did not get its structure.
Does anybody have more detail about it or have played with RXMap
before?

I need to understand that because for some reason, some string data is
truncated to 255 characters when it is stored on RXMap (I guess). I
created a simple and custom collector and add more than 255 characters
to e.fn field and it worked fine. When I use some collectors which use
RXMap field,, e.fn (FileName) is truncated.

Regards
HH


--
hugohigashi
------------------------------------------------------------------------
hugohigashi's Profile: http://forums.novell.com/member.php?userid=89996
View this thread: http://forums.novell.com/showthread.php?t=447960

0 Likes
3 Replies
Anonymous_User Absent Member.
Absent Member.

Re: RXMap field from collectors

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Could you clarify which collectors truncated the data? That seems to be
the most important issue and if we can find the actual mapping perhaps
we can track back to the first question on how it should work.

When using your own collector and the e.fn field was NOT truncated
initially, did the data make it all the way through the system in its
> 255-character length form? Are you using Log Manager or Sentinel
> and

which versions/patches?

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOwnTaAAoJEF+XTK08PnB5/84QALanmIYvDYLdhfF72uexmk4T
C5dDexFahX1ckMjgCuHN4XAAxSRaCyVzt7L6IJX8IfAJXZGbKcuQWDXAV+UHYkuE
VyBWmjv4kDnIh+8UW7FySQxwL/IGUs/2bny9eCo1vvW9yBTWjC7YikhtE8CgeBJa
vPNVdFGN7ZjiC+EiQSaOJeR8U8fwMyuO+TG4WusNkje7L4gNjr5UQhoVYDbW1O8J
JxiZoW8rGfBy3k6UuFToSrG/Lpk8gmpyWmAOTXddZSNIJECAMglXn/DpH2we9PCA
Zi0qz0NzmSXYERN3H9jEP1RE5uk1ieXGjVp8S516FsDtkunpf2dsTNpirx70TSWp
4wBm8h1xf1fU5pydPZj1vc63+wJR+nBoK3MwCfP152LRFr864PXAwXMS/hmQ1VMU
X3YyHcyQfQSuAe/G3dmEgof9k/BHZbP9geZhRtpEpQJ/n5zdMnfZxsMc6oqRb0do
EYXckUgpQ3GHH6lNXEEabtK/pzwV2o5DvS+ZwHlVRZuagwg2YOMz1CpAGDnfOQJ5
b4c+OHcTnOmRspF8hyO8eHIrgEqG8Ik5quKcFDvqJgxd7IBx1MRcqZ9WlNKHTTZY
ZnfzyBQuXQGmgmHr7PZTL4EEcR+Etz/+/Y3sGAOgC6Ft1T3+m0IS1vG+WNcMPw7G
LmEPrQNPG0AFQ6KYueSc
=MNci
-----END PGP SIGNATURE-----
0 Likes
Highlighted
Anonymous_User Absent Member.
Absent Member.

Re: RXMap field from collectors


Actually, Sentinel Classic... I have not tested on SLM or Sentinel 7
yet..
The collector is for Novell Access Manager and the field name it was
observed to be truncated on Sentinel was FileName. But that does not
mean Sentinel is doing that.
I have already addressed that through Novell support and they are
taking care of that, thanks.

But I am curious about this RXMap variable that it is being used on
this native collector... I am trying to understand better so I could try
to re-use it in some other custom collectors...

Regards
HH


--
hugohigashi
------------------------------------------------------------------------
hugohigashi's Profile: http://forums.novell.com/member.php?userid=89996
View this thread: http://forums.novell.com/showthread.php?t=447960

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: RXMap field from collectors


Hi Hugo,

RXMap is a bit of an artificial construct. Basically we get an object
back from the Connector called ConnectorData, but it's a Java object, so
we have to unpack it in some way. The first thing we do is attach it to
the 'rec' object, which is a Javascript object. Next, we iterate through
the various fields that come back from the Connector (we basically get a
map of data back). There are really two types of fields that come back:
1) Event data
2) Metadata
and two different ways that the Connector will treat the event data:
1) As a single string
2) As a set of fields

Some examples: the Database Connector creates an output metadata field
called "s_Database" that indicates the name of the database that the
data was retrieved from. It also gets event data back from the various
columns, and can either place each field into a separate variable (a
map) or can concatenate them into a long string. The File Connector only
retrieves line-by-line string data and sets a single event data field
with that line of data.

The problem is that the Connector just sets all this stuff at the root
level of the connectorData object, which introduces some problems. First
of all, there's the potential for name conflicts - if a database
happened to have a column called s_Database, it would conflict with the
metadata field of the same name. For that reason the Database Connector
allows you to specify a prefix to put in front of each column name
retrieved from the database.

So what we decided to do when we unpack the Java object and put the
individual fields into the 'rec' object was to enforce a better
separation of data and metadata. For Connectors operating on lines of
data, what you'll see is all the metadata in the root of 'rec', and a
single special variable rec.s_RXBufferString which contains the line of
data. For Connectors operating on maps of data, you'll see the same
metadata in the root of 'rec' but all the actual event data stored under
a rec.RXMap hash.

Note that RXMap doesn't have any particular structure or class, it's
literally just a hash of data in whatever form it arrived in from the
Connector. So really what you find in there is entirely dependent on the
event source and the Connector.


--
DCorlette
------------------------------------------------------------------------
DCorlette's Profile: http://forums.novell.com/member.php?userid=4437
View this thread: http://forums.novell.com/showthread.php?t=447960

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.