Plugin Development Framework¶
Past Approaches to Plugin Development¶
Flow plugins have been developed in the past using many different approaches. This section provides an overview for background and perspective.
History¶
The following 2 approaches were largely catered towards extending access to the internals of the Flow Server for the purpose of specific customization. For example, querying the Flow Jobs that have run on a day, creating a chart and showing it in an HTML page, by extending the page menu.
CGI and HTML to build the User Interface, invoking ec-perl command line scripts at runtime.
ElectricCommander java SDK (that includes GWT bindings) to build the User Interface, invoking perl scripts through ec-perl at runtime.
The following 3 approaches evolved as there was a need to integrate with third party software and hence required more intuitive and dynamic UIs (that are consistent with Flow UIs), apart from modularized plugin step code to address different use cases.
Build the User Interface using a declarative approach (form.xml) which in turn gets used by React, invoking modularized perl code through ec-perl at runtime.The salient metadata required for all Procedures is declared in a file called project.xml, which gets further exploded and applied as an RDBMS bulk upload during the install process.
Same as above except that the runtime uses ec-groovy bindings to interact with the Flow Server. In this approach, the project.xml is considerably simpler than the approach above and gets exploded and applied using Flow DSL during plugin promotion. Further the plugin source code layout is more intuitive than 3.
Same as above except the runtime is modularized perl that gets invoked using ec-perl.
Plugins developed using 4 and 5 are also referred to as PluginWizardBased plugins.
Limitations of each approach¶
- CGI Based Approach
Difficult to implement dynamic UI elements.
Developer is responsible for things like matching ElectricFlow “look-and-feel” (CSS).
- GWT Based Approach
By default, GWT/Java performs “processing logic” in the web browser.For data intensive tasks, a combination of GWT/Java + CGI/perl may be required to offload work to the web server.
Does not leverage React which is more robust, consistent with Flow UI and provides a declarative approach(form.xml).
Relatively longer development and debugging cycles.
- Pluginwizard
Provides a methodology to package and promote plugins. It is not a development framework.
DSL based promotion that the Pluginwizard introduces does not perform and increases linearly with the number of procedures added to a plugin.
Why do we need a Development Framework¶
- As the use case for creating plugins becomes diverse, there is a fundamental need to have a unified approach that:
Provides a consistent way to build a plugin starting from code layout all the way to its promotion.
Abstracts plugin based common interactions with Flow and Third Party Tools by providing reusable core libraries.
Provides inversion of control with tooling that goes hand in hand with the resusable libraries and aids development from start to finish.
Offers the possibility to expand the repertoire of core libraries, thus providing continuous innovation.
In a nutshell the goal of the Framework is to accelerate plugin development.
What constitutes the Development Framework¶
The Plugin Development Framework (aka flowpdf) is a combination of Tools, Specifications, APIs and libraries that work together with the overall goal of making plugin development easier and consistent.
Plugin Starter Spec refers to the file pluginspec.yaml which can be used to declare the procedure interface (including UI elements) for each procedure that is part of the plugin.
flowpdk refers to the CLI (Command Line Interface) which can read the pluginspec.yaml to create the Workspace of the plugin and procedure boilerplate code, creating the entire layout. It is also used to build the plugin.
flowpdf-perl refers to the Perl Library that is packaged automatically by flowpdk with the plugin, whose documented APIs make plugin development consistent and easy.
Refer to the Diagram below which provides the Developer steps to develop a plugin using the framework.

Current Limitations¶
This section is provided for transparency.
Full-fledged support (boiler plate code generation as well as framework libraries) from flowpdf is only available currently for the Perl language.
Perl Plugin dependencies (for example, Third Party Libraries used by the plugin) need to be compatible with Perl 5.8. flowpdf provides the ability to load perl library dependencies from memory, when the plugin step runs. No extra steps are required by the Developer to install third party dependencies for Perl on the agent.
For the Groovy language, flowpdf does not provide either boiler plate code generation or framework library support. However flowpdk can be used to create/manage a Plugin workspace as well as building/packaging a plugin written in Groovy. Developers can use ec-groovy (i.e., CloudBees Flow Groovy APIs which interact with Flow) to author their plugins.
Groovy Plugin Dependencies (for example Third Party Libraries required by a Plugin) need to be installed in the agent by the Developer, either manually or using the @Grab annotation in the plugin step code.
flowpdf is meant to be used to author new plugins. It does not provide any solution to migrate plugins developed with previous approaches to flowpdf.
Note: While the Pluginwizard approach mentioned in the section above provided a way to package third party libraries by using the Flow Repository Server to hold these and then retrieving these as artifacts in the plugin step code, flowpdf does not currently support this approach, since Flow Repository may not be setup by all customers.