Plugin framework
| Plugins intended for use in the Squiz DXP or Funnelback multi-tenanted and dedicated v16 require a review before they can be used and this is currently only available to internal Squiz developers. |
The plugin framework provides developers with a suite of options for developing Funnelback plugins.
Plugins are developed using the Java programming language and package up the extended functionality into an extension that can be enabled by a search implementer from the search dashboard.
Plugins are subject to review by the Funnelback product team prior to being installed onto the Funnelback server. See the publishing section for information on how to submit your plugin for review.
On average the product team will provide a decision on your plugin within two business days of receiving the request.
Getting started
- Setting up your development environment
-
Install pre-requisites and configure your IDE.
- Generate a plugin project
-
Learn about the tool used to create a new plugin project.
- Tutorial: Developing your first plugin
-
Follow a step-by-step tutorial that covers implementation of a very simple plugin. The tutorial covers the complete process, including setup of your development environment.
- Plugins - Groovy and equivalent Java code examples
-
For existing Funnelback developers that are familiar with writing Groovy filters and hook scripts.
Plugin interfaces
Plugins provide various interfaces which, when implemented, extend Funnelback in a number of ways.
| A plugin must implement at least one of these interfaces and may require the implementation of multiple interfaces to deliver the required functionality. |
The interfaces enable the implementation of:
-
Query-time modifications to the question and response data model as part of the search lifecycle, or as servlet filters that access and modify the request and response servlets.
-
A custom gatherer for use with a custom data source to enable the gathering of content from arbitrary data sources.
-
Filters that analyze and manipulate document content prior to indexing.
-
Faceted navigation custom sort comparator that implements a custom sorting algorithm for faceted navigation categories.
The plugin framework also provides a number of supporting interfaces that usually support the above use cases but can also be used standalone. These interfaces enable:
-
Indexing configuration that will be set for a data source, primarily to support the plugin’s custom functionality. This includes configuration of metadata mappings, external metadata, gscopes, kill lists and auto-completion CSV.
Plugin configuration
Plugins should be designed to be reusable and read configuration options from the data source or results page.
Plugins support two types of configuration:
- Configuration supplied via configuration keys
-
Configuration keys can be defined within data source or results page configuration, which are available to the plugin via a Java map. These configuration keys are key-value pairs that are stored with the other configuration for the data source or results page and are service the configuration needs of the majority of plugins.
- Configuration supplied via a configuration file
-
A plugin-specific configuration file can be defined to capture complex configuration for a plugin. This is appropriate when plugin configuration requirements are not satisfied by simple key-value pairs, e.g. if you need a set of keys to define a single rule that the plugin uses.
Configuration files can be defined in two formats - plain text and JSON.
Plugin documentation
Each plugin must provide documentation which provides detailed information on how the plugin works and how to configure it.
Plugin unit tests
Each plugin interface provides corresponding test classes which must implement unit tests for the plugin functionality.
| Unit tests must be supplied for plugins to ensure that automated upgrades to the Squiz DXP environment can be performed safely without breaking any plugin functionality. |