Ole Lensmar, CTO of SmartBear Software, explains how to develop your own plugins for SoapUI Pro, the world's most popular API testing tool. #SoapUIPlugins
3. Plugin Scenarios
Integrate with other tools, platforms or
technologies
Tailor functionality for specific APIs
Add new functionality for existing protocols
Add new protocols
4. Business Scenario
Target SoapUI Pros 40000+ paying customers
Plugin authors can charge for plugins in any way they
want
SmartBear is planning a plugin “Marketplace” to help
promoting and monetizing
Plugins can be promoted to all existing SoapUI and
SoapUI Pro users (> 1 million) from within the tool
Join the ranks of Mulesoft, Swagger, Apiary, etc.
5. How are plugins distributed?
Via SmartBears Plugin Repository
– Available from inside SoapUI Pro
– One-click download and install
Commercialization and Licensing up to the
plugin author
Can be distributed as standalone files also
6. How to Submit Your Plug-in Idea
• Build Your Plug-in
• Email Your Extension to soapuiplugins@smartbear.com
with the following:
• Plugin Name
• Description
• Creator
• URL to read more
• IMPORTANT: remember to change the extension first!
We’ll change it back to .jar for you.
• First 50 submissions will receive a T-shirt
8. What is a plugin technically?
A single JAR file that contains
– Plugin functionality
– 3rd party libraries
Plugins are easiest written in Java or Groovy
Building and packaging easiest with Maven
Plugins are distribute either via the integrated
repository or as standalone files
9. A plugin can contain
Actions - that users invoke via menus/toolbars
Listeners - that are triggered for specific events
happening in SoapUI Pro
Factories : that add
– UI objects (editors, inspectors)
– Testing objects (TestSteps, Assertions)
– Miscellaneous behavior
Any combination of the above
10. Plugin Annotations
Plugin classes are “marked” with
corresponding Java annotations
When SoapUI Pro loads a plugin it looks for
these annotated classes and configures them
accordingly
Annotations exist for each possible extension
point (Actions, Listeners, Factories, etc)
11. The @PluginInfo annotation
Provides plugin metadata
All plugins need to have one @PluginInfo
annotated class
@PluginConfiguration(
groupId = "com.smartbear.plugins",
name = "testplugin SoapUI Action",
version = "0.1”,
autoDetect = true,
description = "testplugin SoapUI Action”,
infoUrl = "" )
public class PluginConfig extends PluginAdapter {}
13. Tools
Java Editor or IDE (like Eclipse or IntelliJ IDEA)
Maven build tool
SoapUI Pro (trial will work fine)
14. Creating an empty plugin project
Generate: mvn archetype:generate
-DarchetypeGroupId=com.smartbear.maven.archetypes
-DarchetypeArtifactId=soapui-plugin-archetype
-
DarchetypeCatalog=http://www.eviware.com/repository/maven2
Prompts for name, package, version, language and type
(lots more on that later)
(Read more:
https://github.com/olensmar/maven-soapui-plugin-archetype)
15. Build and install
The archetype creates a working plugin
skeleton
Build the plugin with
mvn clean:install
The .jar file in the target folder is your plugin!
16. Packaging 3rd party libraries
Need to be added to the created jar in a “libs” folder
Automate this with the maven assembly plugin
Have look at the sample plugins on GitHub
Build with
mvn assembly:single
SoapUI Pro will automatically unpack and add jars to
plugins classpath
17. PLUGIN TYPES
I know this is tedious – but I want to show you all the possibilities
18. Plugin types – Actions
Action: creates an Action, by default at the Project level
@ActionConfiguration annotation specifies;
– actionGroup: which popup menu (see ActionGroups class added by archetype)
– toolbarPosition: which toolbar to show in
– beforeAction/afterAction: position in menu/toolbar
– iconPath / toolbarIcon: icons to show
– keyStroke: keyboard shortcut
– description: (used for tooltip)
– separatorBefore/separatorAfter: adds surrounding separators
Annotated class must implement “SoapUIAction” interface
– The “perform” method is called with the selected object when invoked
Use to add any kind of user-driven functionality
19. Plugin types – Discovery
Discovery: creates a custom REST Discovery method
@PluginDiscoveryMethod – no annotation properties
Annotated class must implement “DiscoveryMethod”
interface
APIs can be discovered asynchronously
Invoked from “New Project “ dialog
20. Plugin types – Import
Import: creates a custom Project Importer
@PluginImportMethod – no annotation properties
Annotated class must implement “SoapUIAction” interface
For new ways of importing APIs – for example an external API file
format
Invoked from “New Project” dialog
21. Plugin types – PanelBuilder
PanelBuilder: creates a PanelBuilder for a SoapUI object
@PluginPanelBuilder
– targetModelItem property; the object class for which panels can be built
Annotated class must implement “PluginBuilder”
Used for building Desktop and Overview panels (main and bottom left)
Main use case: Create panels for custom TestSteps
– Secondary: Overriding existing panels
22. Plugin types – Prefs
Prefs: creates a custom tab in the global Preferences
@PluginPrefs annotation – no properties
Annotated class must implement “Prefs” interface
Shows up as a tab in the Global Settings dialog
Use it for managing global settings related to your plugin
– Project-specific settings are better managed via a custom Project action
23. Plugin types – Editors Views
RequestEditor/ResponseEditor: create a custom Editor view
@PluginRequestEditorView / @PluginResponseEditorView
annotations
– viewId property; name of the View
Annotated class must implement “EditorView” interface
Adds custom editor tabs to request/response message editors
For new message formats, specific APIs, etc.
24. Plugin types – Editor Inspectors
RequestInspector/ResponseInspector: create a custom Inspector
tabs
@PluginRequestInspector, @PluginResponseInspector annotations
– inspectorId property; name of the inspector
Annotated class must implement “EditorInspector” interface
Adds inspector tab to request/response message editors
For editing custom aspects of a request, for example together with a
custom RequestFilter or RequestTransport
25. Plugin types - TestSteps
TestStep: creates a custom TestStep
@PluginTestStep annotation, properties:
– typeName : internal id to uniquely identify this type of TestStep
– name: a verbal name of the type of TestStep
– description: description of what it does
– iconPath: an icon to show in the toolbar (optional, but recommended)
Annotated class must implement TestStep interface (usually extends
WsdlTestStepWithProperties)
Adds a new TestStep to be used with functional tests
Usually combined with a @PluginPanelBuilder for providing views
26. Plugin types – Assertion
Assertion: creates a custom assertion
@PluginTestAssertion annotations, properties;
– id: unique identifier for this type of Assertion
– name: name for the type of assertion
– description: a description of the assertion
– category: which category the assertion belongs to
• Available categories defined in AssertionCategoryMapping
Implementing class needs to extend WsdlMessageAssertion and
implement RequestAssertion or ResponseAssertion (or both)
Adds a new Assertion for asserting request or response messages
during functional and load tests (and soon MockServices as well)
27. Plugin types - RequestFilter
RequestFilter: creates a custom Request filter
@PluginRequestFilter annotation
– protocol property defines which URL protocol to apply to
Annotated class must implement “RequestFilter” interface
For modifying incoming/outgoing messages, for example;
– Add tokens/content
– Apply transformations
– Validations
28. Plugin types - ValueProvider
ValueProvider: creates a custom property-expansion
ValueProvider
@PluginValueProvider annotation
– valueName property – the text that triggers the provider
Annotated class must implement
“DynamicPropertyResolver.ValueProvider” interface
For inserting dynamic content into messages and property values,
for example tokens, external data, etc.
29. Plugin types – Listeners
Listener: creates an event listener
@ListenerConfiguration annotation – no properties
Annotated class must implement one of the supported SoapUI
listener interfaces
Powerful way to react to SoapUI events, for example you could;
– If a TestCase fails – automatically report a bug in issuetracker
– When a load-test finishes, automatically write results to database
– When a project is added – prompt user if they want to do X
– Etc…
31. Object-modification related listeners
WorkspaceListener
– Notifies when projects get added/removed/opened/closed
– Notifies when workspaces are switched
ProjectListener
– Notifies when Interfaces, TestSuites, MockServices and Environments get
added/removed
– Notifies when projects are loaded / saved
InterfaceListener
– Notifies when Operations and Requests are added/removed
TestSuiteListener
– Notifies when TestCases, TestSteps, LoadTests and SecurityTests are
added/removed
Most objects also support standard Java propertyListeners for
observing changes
33. The SoapUI Object Model
Defined in com.eviware.soapui.model.* packages
Workspace
– Project
• Interface->Operation->(Action)->Request
• TestSuites->TestCase->
TestStep/LoadTest/SecurityTest
• MockServices->MockOperation->MockResponse
Common methods for navigating;
– getXXXCount(), getXXXAt( index ), getXXXList()
– getXXXs – gets a Map<String, XXX.class>
– getYYY for getting parents
34. The SoapUI Pro API
Javadoc available at
http://www.soapui.org/apidocs/
Code completion is your friend
Useful classes include
SoapUI (soon to be deprecated)
SimpleDialog
UISupport
35. UISupport
Very useful class for interacting with the
SoapUI Pro GUI
UISupport.showInfoMessage(String)
UISupport.confirm(String, String)
UISupport.selectAndShow(ModelItem)
… and much more ..
36. How to get help!
Have a look at existing open-source plugins
– RAML plugin: https://github.com/olensmar/soapui-raml-plugin
– Swagger plugin: https://github.com/olensmar/soapui-swagger-plugin
– API-Blueprint plugin: https://github.com/olensmar/soapui-blueprint-
plugin
SoapUI open-source codebase is the foundation of
SoapUI Pro
Don’t be afraid of asking on the forum, on twitter, etc