Wizlink Plugins Manual
Activities available in Wizlink by default can perform most operations needed to automate a business process, but sometimes an unsupported action is required. For that reason Wizlink also contains a Plugin activity, which can run third-party .NET code.
Plugins suport adding multiple Methods (sometimes further grouped into Classes), accept Input Parameters and return Output Parameters.
Getting started with creating Wizlink® Plugins
Simplest way to create a plugin is to use the Wizlink Plugin project template for Visual Studio. Template is available for download in the form of a .vsix installer and currently supports VS 2019 and VS 2022 in community/pro/enterprise versions.
When a new project is created using this template it will contain two files, Plugin.cs and PluginBase.cs
PluginBase.cs contains a base class for all plugin classes to inherit from, which includes a mechanism for writing Wizlink logs, CancellationToken type and other useful attributes.
Plugin.cs file contains a sample plugin with 2 methods and comments explaining how different parameters will interact with Wizlink software.
Building the project will create a .dll file. The file extension will need to be manually changed to .wll to be used in Wizlink 2.x
Compatibility with Wizlink® Bot Control Center
To be uploaded to BCC, a plugin has to either be a single .wll file, or, in case of a more complex plugin, a .zip folder with exactly one main .wll plugin file and an unlimited numer of .dll dependencies and other required files.
Tips and best practices
Description and TupleDescription attributes
Methods and input parameters containing a Description attribute will have a description visible for end Wizlink user if they hover over their ‘information’ icon.
Similarly, TupleDescription attribute adds description visible to end Wizlink user for output paramenters, if they hover over the ‘information’ icons.
WizlinkVisible and Hide attributes
Public classes or methods with the Hide attribute will not be visible to end Wizlink user.
Only public classes with the WizlinkVisible attribute will appear on Plugin activity block.
Use the WizlinkVisible and Hide attributes to hide classes or methods that you do not intend to be used by Wizlink user.
Note: The WizlinkVisible attribute is only available from Wizlink version 2.5.2.7 onwards.
Asynchronous methods and the Cancellation mechanism
Asynchronous methods returning Task will not have any output parameters visible for end Wizlink user. Asynchronous methods returning Task<T>will only show T as output parameter.
Methods performing asynchronous operations should support a cancellation mechanism. Include an input argument of type CancellationToken and Wizlink will be able to use it, if a scenario is cancelled during that method’s execution.
An input parameter of that type will not be visible to end Wizlink user.
Plugin instances
First parameter of Plugin activity is an Instance Name. The instance created when the activity is executed will be preserved to the end of scenario execution.
Next call to Plugin activity with the same class and instance name will not create new instance of that class, but use the instance created before.
For example, if class WizlinkPlugin initializes internal counter to 0 in a constructor and increments counter by one during execution of DoAsync method, this counter will maintain its changed value and during next execution of Plugin activity will be incremented again by one, changing its value to 2.
Logging mechanism
In order for the plugin to log data in Wizlink, class needs to declare a LoggerHandler event with proper EventArgs. These can be inherited from class PluginBase generated by the template.
If you are not using the template, see code below for how to execute this.
Other recommendations and limitations
- plugin class has to declare a public, parameterless constructor. Only that constructor will be used by Wizlink to instantiate class.
- static methods cannot be used in a Plugin activity
- during the execution of a plugin, Wizlink’s working directory temporarily changes to the plugin’s location
- Wizlink plugins suport use of both Tuple and ValueTuple for output parameters, but ValueTuple is recommended
- only variable types from Microsoft Common Object Runtime Library (mscorlib) are supported as method parameters
Sample plugin files can be downloaded here: