APL Plugins

Owned by Former user (Deleted)
Last updated: May 04, 2023 by Former user (Deleted)

A new APL plugin is defined by extending the DRAPLPlugin class. The code server will locate all such classes and make their functions available within the APL language. This class will be instantiated by the APL compilation engine to extract information about the available APL functions from getFunctions and the Executor class, which is responsible for executing the function, from getExecutorClass.

If the plugin routes UDRs into the workflow, this should be declared by implementing getOutputTypes and returning all types that the plugin may route for each outgoing route. If the plugin expects any hardcoded route names to be present in the workflow, it must also implement getExpectedRouteNames. The presence of these names on outgoing routes will then be validated.


APL

APL functions developed using DTK need to be imported. If the function get_package_name() returns a package name, that name must be used to import the included functions, as in the following example:

Example - The function get_package_name()

import apl. package_name;

If the returned name is not imported, the included functions cannot be accessed and will not be highlighted.

If the function get_package_name() returns null instead, the functions will be globally available and automatically highlighted regardless of where they are used.

Note!

Since Function Overloading is not supported, all APL plugin function names must be unique. This also applies if the functions have different parameters, for example, a(int x) and a(string x).

If an Aggregation/Analysis agent or APL module imports two functions with the same names, the calling agent or APL module will become invalid, even if the functions are located in different APL modules.

DRAPLFunctionSignature

A DRAPLFunctionSignature object describes each new function. The function name is returned by the getName method. The number of parameters and their data types are returned by the getArgumentTypes method and the return type by the getReturnType method. If the function supports dynamic parameters, the isDynamic method will return true. In this case, the function must have an additional parameter of the Java type List that, when called, will contain the additional parameters.

The APL compiler will automatically make the necessary syntax validations regarding the name, parameters and return type when APL code is compiled. If additional validation is required, the validate method must be implemented. It is essential that the Executor class has a function that exactly matches the name, the return type and the number of parameters stated by this object.

DRAPLExecutor

When a workflow is executing, the APL function call will be delegated to the corresponding function in the APL plugins Executor object. An Executor class must implement the interfaces DRAPLExecutor or DRAPLTxnExecutor, where the latter allows the APL plugin to interact with the transaction handling.

Executor classes will have their initialize method called once, prior to any invocation of the function(s) they hold. Transaction Executors may implement the methods from DRBatchTransactionResource, such as cancelBatch or commit.

To route UDRs from the plugin, a router must first be obtained by calling getRouter on the environment.