Apama Documentation : Developing Apama Applications : Developing Correlator Plug-ins : Advanced Plug-in Functionality in C++ and C : Introducing complex_plugin
Introducing complex_plugin
Appropriately, this extended C++ example is called complex_plugin.cpp, and it is also available in the samples\correlator_plugin\cpp directory of the Apama installation. A README.txt file in the directory describes how to build the example plug-in.
This time, the C++ example has three plug-in C++ methods defined:

class ComplexPlugin {
  public:
 
    static void AP_PLUGIN_CALL test1(
      const AP_Context& ctx,
      const AP_TypeList& args,
      AP_Type& rval,
      AP_TypeDiscriminator);
 
    static void AP_PLUGIN_CALL test3(
      const AP_Context& ctx,
      const AP_TypeList& args,
      AP_Type& rval,
      AP_TypeDiscriminator);
 
    static void AP_PLUGIN_CALL test4(
      const AP_Context& ctx,
      const AP_TypeList& args,
      AP_Type& rval,
      AP_TypeDiscriminator);
}
ComplexPlugin::test1 dynamically decodes and displays its arguments, and then modifies the contents of any sequences that are passed to it. ComplexPlugin::test3 allocates and returns an ExampleChunk opaque object (see The chunk type for more information on opaque objects). ComplexPlugin::test4 uses an ExampleChunk object as created by ComplexPlugin::test3, modifies and prints its contents, and then returns it.
You may have noticed that no test2 was defined. This is intentional and the reason will become evident shortly.
In order to map the above C++ methods to plug-in functions, you must define the Functions static array. This time this looks as follows:

static const char8* test1ParamTypes[4] =
  {"integer", "float", "boolean", "string"};
 
static const char8* test2ParamTypes[4] =
  {"sequence<integer>", "sequence<float>", "sequence<boolean>",
   "sequence<string>"};
 
static const char8* test3ParamTypes[1] = {"integer"};
static const char8* test4ParamTypes[1] = {"chunk"};
 
static AP_Function Functions[4] = {
  {"test1",&ComplexPlugin::test1,4,&test1ParamTypes[0],"string"},
  {"test2",&ComplexPlugin::test1,4,&test2ParamTypes[0],"float"},
  {"test3",&ComplexPlugin::test3,1,&test3ParamTypes[0],"chunk"},
  {"test4",&ComplexPlugin::test4,1,&test4ParamTypes[0],"void"}
};
This definition highlights some of the powerful capabilities available to plug-in developers.
*First of all it maps ComplexPlugin::test1 to the plug-in method test1, indicates that it takes four EPL parameters, sets these to be an integer, a float, a boolean and a string respectively, and sets the return type to be a string.
*It then maps ComplexPlugin::test1 (again!) to the plug-in method test2, this time indicating that it will take four EPL parameters, and sets these to be a sequence of integer, a sequence of float, a sequence of boolean and a sequence of string, respectively. It then sets the return type to be a float. It is important to note that this multiple mapping of the same C++ method can only be carried out if the method is written with no assumptions regarding the type of its parameters or result. In fact, if you examine the full source code for this example, as provided below, you will see that this method examines the parameters' types before manipulating them.
*ComplexPlugin::test3 is mapped to test3 and set to take a single integer. Interestingly though, it is set to return a chunk type. This is a special purpose opaque type. For an explanation of this type, The chunk type.
*ComplexPlugin::test4 is mapped to test4, and accepts a chunk type. Its implementation is designed to work on the chunk result produced by ComplexPlugin::test3. It does not return a value.
Copyright © 2013-2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback