Apama Documentation : Connecting Apama Applications to External Components : Developing Custom Adapters : Using the IAF : The IAF configuration file : Transport and codec plug-in configuration
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:
...
<transports>
  <transport name="File" library="FileTransport">
    <!-- Transport-specific configuration property -->
    <property name="input" value="simple-feed.evt"/>
    <property name="output" value="output.evt"/>
  </transport>
</transports>
<codecs>
  <codec name="String" library="StringCodec">
    <!-- Codec-specific configuration property -->
    <property name="NameValueSeparator" value="="/>
    <property name="FieldSeparator" value=", "/>
    <property name="Terminator" value=";"/>
  </codec>
</codecs>
...
Similarly the configuration section for the equivalent Java plug-ins, both packaged inside FileAdapter.jar, would be:
...
<transports>
  <transport
   name="File"
   jarName="JFileAdapter.jar"
   className="com.apama.iaf.transport.file.JFileTransport"
  >
    <!-- Transport-specific configuration property -->
    <property name="input" value="simple-feed.evt"/>
    <property name="output" value="output.evt"/>
  </transport>
</transports>
<codecs>
  <codec
   name="String"
   jarName="JFileAdapter.jar"
   className="com.apama.iaf.codec.string.JStringCodec"
  >
    <!-- Codec-specific configuration property -->
    <property name="NameValueSeparator" value="="/>
    <property name="FieldSeparator" value=", "/>
    <property name="Terminator" value=";"/>
  </codec>
</codecs>
...
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.
Copyright © 2013-2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback