Getting started with transport layer plug-in development
In order to facilitate quick development of a transport layer plug-in your distribution includes a transport plug-in skeleton.
This file, called skeleton-transport.c, implements a complete transport layer plug-in that complies with the transport layer Plug-in Development Specification but where all the custom message source specific functionality is missing. The file is located in the samples\iaf_plugin\c\skeleton directory of your installation.
The skeleton starts a background thread to do the actual message reading. This is the only approach suitable, unless the external transport is able to call back into the transport layer plug-in.
In order to turn the skeleton into a fully operational message source specific transport layer plug-in, the plug-in author needs to fill in the gaps within the updateProperties, sendTransportEvent, addEventDecoder, removeEventDecoder, flushUpstream, flushDownstream, start, stop, getLastError and getStatus functions. These must implement their specified functionality in the context of the custom message source. The constructor, destructor and info functions are also likely to require adaptation.
The skeleton defines a structure, called EventTransport_Internals, to store all its private data, and this structure is placed within the reserved field of the AP_EventTransport object created within the constructor method. It is likely that this structure will need to be modified to contain additional data that the adapter might require.
Any custom initialization and communications code, such as code to connect and register with a message bus, or opening a database, etc., can either be placed in the constructor or in the primary worker thread’s run method. Alternatively, one might need to place such code in the updateProperties method, which is called by the IAF at initialization time as well as whenever it is requested to reload the configuration file and thus resend the plug-in’s properties.
The distribution also includes a Makefile (for use with GNU Make on UNIX) as well as a workspace file and dsp folder, for use with Microsoft’s Visual Studio .NET on Microsoft Windows, for this skeleton, which can be adapted to compile your transport layer plug-in and link it against any custom libraries required.
Once a plug-in is built, it needs to be placed in a location where it can be picked up by the IAF.
This means that on Windows you either need to copy the .dll into the bin folder, or else place it somewhere which is on your ‘path’, that is a location that is referenced by the PATH environment variable.
On UNIX you either need to copy the .so into the lib directory, or else place it somewhere which is on your ‘library path’, that is a directory that is referenced by the LD_LIBRARY_PATH environment variable.