Apama 10.3 | Apama Documentation | Developing Apama Applications | Developing EPL Plug-ins | EPL Plug-ins in C and C++ Written Prior to 10.0 | The EPL plug-in APIs for C and C++ | Primary class types
Primary class types
The primary class types follow:
*AP_Chunk — This is the base class for all chunk values. Plug-ins need to inherit from this class and add suitable data and function members in the derived class to manage their private data structures in memory allocated by the plug-in itself. AP_Chunk instances are passed in and out of plug-in functions as the "chunk value" of AP_Type objects, and referenced in EPL code via variables of type chunk.
*AP_decimal — The EPL decimal type is transferred as a uint64 in the IEEE 754-2008 decimal format. We suggest using the Intel Decimal Floating Point library v2.0U1 (see https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library). It can contain a value, NaN, positive infinity, or negative infinity. See the API Reference for EPL (ApamaDoc) for more information on the decimal type. An example of how to use this library in a plug-in can be found in the decimal plug-in sample (see samples\correlator_plugin\cpp\decimal in your Apama installation).
*AP_Type — This is a type-safe encapsulation of an EPL object for passing arguments and return values into and out of plug-in functions. The implementation of the AP_Type member functions is internal to the correlator. One consequence of this is that plug-ins cannot create a useful instance of this class themselves; the only valid AP_Type objects are those passed to a plug-in function by the correlator. AP_Type is a "smart union" object; each instance holds a single value of one of the supported types and only allows access to data of that type. Note that integer, float, and boolean values are passed by value, while the "complex" types (sequence and chunk) are passed by reference, so changes made to the contents of these objects by a plug-in will be seen by the invoking EPL code. Strings are treated slightly differently: though EPL string objects themselves are immutable, the plug-in API allows return values and the values in a sequence of strings to be modified. When this is done, a new EPL string object is created containing the specified text. As of version 5.0 it is no longer possible to modify a string argument to a plug-in function.
*AP_TypeList — A container class for an ordered list of AP_Type objects, typically used to hold the argument list for a plug-in function call.
*AP_Context — The execution context for a plug-in function call. Holds per-call correlator-internal data and provides various utility functions to plug-ins. Note that the implementation of the AP_Context member functions is internal to the correlator. One consequence of this is that plug-ins cannot create a useful instance of this class themselves; the only valid AP_Context objects are those passed in to a plug-in function by the correlator.
*AP_Function — A plug-in function descriptor. The argument and return types in this structure are strings (not AP_TypeDiscriminator objects) that use the same syntax as EPL declarations. For example, if one declares a function argument as a sequence of integers, the corresponding element of the paramTypes array would contain sequence<integer>.
*AP_CorrelatorInterface — An abstraction of the interface for calling back into the correlator. There is a single method provided that enables a plug-in to send events to the correlator. An instance of this class is acquired by requesting it via a method on the AP_Context.
The header file also defines pointers to the plug-in initialization and destructor (or shutdown) functions, as well as version checking. Each plug-in must export these two functions with these signatures, named using specific macros and with "C" linkage. The first is called immediately upon loading of the plug-in by the library whereas the other is called immediately before unloading.
If the plug-in's functions can safely be called simultaneously from multiple EPL contexts, a get-capabilities function should be defined that announces the plug-in as thread-safe.
Some plug-ins may need to keep thread-specific data in order to work correctly; in which case a thread-ended function should also be defined. This function will be called on the thread so that resources can be freed if the thread is ending before the plug-in is shut down. When the shutdown function is called it is responsible for freeing resources related to any threads that are still running.

Copyright © 2013-2018 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.