Transport and codec plug-in configuration
The adapter configuration file requires both a <transports> and a <codecs> element.
The <transports> element defines the transport layer plug-in(s) to be loaded, and contains one or more nested <transport> elements, one for each plug-in.
The syntax of the <codecs> element mirrors the <transports> element precisely, and contains one or more nested <codec> elements, each of which defines a codec layer plug-in to be loaded.
The <transport> and <codec> elements
The transport or codec layer plug-in that should be loaded is defined by the attributes of the <transport> or <codec> elements:
To load a C or C++ plug-in, there must be a
library attribute, whose value is the filename of the library in which the plug-in is implemented. The extension and library name prefix will be deduced automatically based on the platform the IAF is running on. For example, on Windows
library="FileTransport" would reference a file called
FileTransport.dll; on a UNIX system the library filename would be
libFileTransport.so.
To load a Java plug-in, instead provide a
className attribute, whose value is the fully qualified name of the Java class that implements the plug-in.
If the optional
jarName attribute is also provided, the plug-in class will be loaded from the Java archive (
.jar) that it specifies; otherwise the IAF will use the usual classpath searching mechanism to locate the class. See
Java configuration (optional) for more information about setting a classpath for use with the IAF.
All
<transport> and
<codec> elements must also have a
name attribute. The name is an arbitrary string used to reference the plug-in within the IAF, and must be unique within the configuration file. Even if the same plug-in was to be loaded more than once inside the same IAF, the corresponding
<transport> or
<codec> elements would still need to have different names.
The
<transport> and
<codec> elements can include an optional
recordTimestamps attribute. This attribute supports the latency framework feature. The value of the attribute determines the values of the
recordUpstream and
recordDownstream members of the
IAF_TimestampConfig object (C/C++ plug-ins) or
TimestampConfig object (Java plug-ins) object passed to the semantic mapper. The attribute takes one of the following values:
none — Do not record any timestamps
upstream — Record timestamps for upstream events only
downstream — Record timestamps for downstream events only
both — Record timestamps for both upstream and downstream events
The default, if the recordTimestamps attribute is not present, is none.
The
<transport> and
<codec> elements can include an optional
logTimestamps attribute. This attribute supports the latency framework feature. The attribute takes a space- or comma-separated list of keywords for its value. Supported keywords are:
upstream — Log latency for upstream events
downstream — Log latency for downstream events
roundtrip — Log roundtrip latency for all events, in a plug-in-specific way
logLevel — Set the logging level for timestamp logging. Any of the standard Apama log levels are accepted for this keyword.
The value of this attribute determines the values of the logUpstream, logDownstream, logRoundtrip and logLevel members of the IAF_TimestampConfig object (C/C++ plug-ins) or TimestampConfig object (Java plug-ins) passed to the semantic mapper. If the logTimestamps attribute is not present, the log level defaults to INFO and the other timestamp logging parameters default to false.
Note:
Although C/C++ and Java transport and codec layer plug-ins may coexist in the same IAF, using a C/C++ codec plug-in with a Java transport plug-in or vice-versa is not permitted.
Plug-in <property> elements
<transport> and <codec> elements may also contain any number of <property> elements, which are the mechanism by which plug-in-specific options are configured.
Each <property> element has two attributes: name and value. The syntax of the name and value is entirely determined by the plug-in author. Typically the name, value pairs are not ordered, and there is no constraint on the uniqueness of the names. Most plug-ins treat the name attribute in a case-sensitive manner.
In most (though not all) cases, plug-in authors allow properties to be changed dynamically without restarting the IAF, by using the IAF Client tool to request a reload of properties from the IAF configuration file. See
IAF Management – Managing a running adapter I for more information about using the IAF Client.
Example
The transport/codec definition section of an IAF configuration file might look as follows for a C/C++ transport plug-in implemented on Windows by FileTransport.dll with a codec in StringCodec.dll:
Similarly the configuration section for the equivalent Java plug-ins, both packaged inside FileAdapter.jar, would be:
You are advised to peruse the iaf_4_0.dtd file as it represents the complete syntactic reference to the correct structure of the configuration file.
The topic
Event mappings configuration describes the semantic translation and transformation rules.
IAF samples illustrates an example configuration file.