Class Connector

Defined in: connector.js.

Class Summary
Constructor Attributes	Constructor Name and Description
	Connector(uuid) This class represents the Connector(s) passing data to the Collector.

Field Summary
Field Attributes	Field Name and Description
	DBQuery The DBQuery object is used to hold the default SQL query that will be issued against a database source.

Method Summary
Method Attributes	Method Name and Description
	addParser(parser) Adds a default parser that will automatically be called to determine the current offset.
	addSubParser(parser) Enable suboffset handling for SQLQuery objects and add a handler that will be automatically called to determine the suboffset.
	cleanup() This method frees up resources held by this object.
<inner>	getData(secs)
	Parser(input) The parser used to pull the latest offset out of the last database record.
	read() This method reads the next set of input data from the Connector queue.
	send(msg) This method sends data to the attached Connector.
	sendQuery() The sendQuery() method will transmit a string to the Connector for processing; for example with the DB Connector this would be the database query, and for the Process Connector this would be passed to STDIN of the process.
	start() Starts this Connector in ESM.
	stop() Stops this Connector in ESM.
	SubParser(input) The parser used to pull the latest suboffset out of the last database record.

Class Detail

Connector(uuid)

This class represents the Connector(s) passing data to the Collector. Connectors actually feed a single inbound queue of event data, so you cannot address them individually. This has implications for scenarios where you must send data to the Connector - in this case you can only have a single Connector per Collector (DB Connector, for example). The template handles most things to do with reading and writing to the Connector, but in some unusual circumstances you may need to use this class.
Author: Novell Engineering.

Parameters:
{String} uuid: UUID of the Connector in ESM

Field Detail

DBQuery

The DBQuery object is used to hold the default SQL query that will be issued against a database source. It is only used if the Connector is a DB Connector, and will be initialized on receipt of the first record.

See:: SQLQuery

Method Detail

{Boolean} addParser(parser)

Adds a default parser that will automatically be called to determine the current offset. The parser should be defined as a function that can be attached to a SQLQuery. instance.PARSER is provided as a convenient place to store pre-defined parser routines. Any time a new event source is discovered and a SQLQuery is allocated for it, this default parser will be attached to it.

Example:

// ...in initialize() method
instance.PARSER.getOffset = function(input) {
  return input.RXMap.RecNumber;
  ...
};
conn.addParser(instance.PARSER.getOffset);

Note that you could simply create a single parser that will be assigned by default to all SQLQuery objects, but you can also predefine several parsers and dynamically attach them directly to SQLQuery objects; see the SQLQuery object API for details.

Parameters:
{Function} parser: - The parser function to attach to this session

Returns:: {Boolean} Result

See:: SQLQuery

{Boolean} addSubParser(parser)

Enable suboffset handling for SQLQuery objects and add a handler that will be automatically called to determine the suboffset. Many databases don't use an incremental event ID that can be guaranteed to be unique per event, and properly increment over time. To handle this scenario, we commonly query based on a timestamp offset, but in many cases the resolution of the timestamp is such that we may get multiple events for any given offset. Since we can't guarantee that we will get all the events assigned to a single offset (either because we hit MaxRows or because some of the events hadn't been generated yet), we need to query the same offset again until we see the next offset in the received data (which implies that we've passed into the next timeslice). The resulting issue, however, is that we may get duplicate events in subsequent queries which we must filter out be keeping track of which events we've already processed. To do this, we need to have a way to uniquely identify each event by some field or combination of fields, but this value need not be incremental. This feature uses an internal cache of processed events, plus a registered function to extract the unique value from processed events.


Example:
// ...in initialize() method
instance.PARSER.getSubOffset = function(input) {
  return input.RXMap.RecID;
  ...
};
conn.addSubParser(instance.PARSER.getSubOffset);

Note that if you define a subparser, it will be automatically attached to all SQLQuery objects that are allocated for event sources.
If you have some event sources that use suboffsets and some that don't, you'll manually have to disable suboffsets for those SQLQuery objects
that don't use suboffsets (see SQLQuery API).

Parameters:
{Function} parser: - The parser function to attach to this session

Returns:: {Boolean} Result

See:: SQLQuery

cleanup()

This method frees up resources held by this object.

<inner> getData(secs)

Parameters:
secs

Parser(input)

The parser used to pull the latest offset out of the last database record.

Parameters:
input

{Record} read()

This method reads the next set of input data from the Connector queue. Connector.read() returns a Record object that is a map of the input data received plus Connector meta-information.

Returns:: {Record} The record received from the Connector queue, basically a hash map

{Boolean} send(msg)

This method sends data to the attached Connector. Note that if this function is used the Collector can support attachment of only a single Connector. It handles both sending strings to Process Connectors and SQL Queries to DB Connectors.

Parameters:
{Object} msg: Message to send to the Connector

Returns:: {Boolean} Status of send attempt

See:: SQLQuery

{Boolean} sendQuery()

The sendQuery() method will transmit a string to the Connector for processing; for example with the DB Connector this would be the database query, and for the Process Connector this would be passed to STDIN of the process. See each Connector's documentation for details. Please note that for many Connectors this step is not necessary, and can be skipped. For the Database Connector in particular, the template will help handle offsets and suboffsets automatically if you define parsers for them (see SQLQuery class), and will handle the complexities of re-querying the DB (hence, you'd only use this in special circumstances).

Example: // Note: not an example of usage, but of implementation: Record.prototype.sendQuery = function() { conn.send("exec fetch"); return true; }
Defined in: release.js.

Returns:: {Boolean} Whether the query was sent correctly

See:: SQLQuery

start()

Starts this Connector in ESM.

stop()

Stops this Connector in ESM.

SubParser(input)

The parser used to pull the latest suboffset out of the last database record.

Parameters:
input

Classes

Class Connector