Advanced Custom Tools

Developing advanced custom tools

Please read the Getting started with tools and data connectors article before attempting the more advanced concepts. This article will outline the creation of custom tools that consume sources and define some of the best practices of developing tools.

What are the benefits of custom tools?

Advanced custom tools allow Warewolf contributors to create tools using simple POCO classes on the server and simple XAML views on the client without any knowledge of the inner workings of Warewolf. It therefore is significantly faster to develop custom tools with deterministic behavior than it is to develop native tools. The base server side classes perform the following functions transparently

  • Handles debug output,
  • Manages server storage
  • Handles the evaluation of any Warewolf language elements.

What is a Source?

One of the primary aims of Warewolf is to encourage the reuse of logic and resources as much as possible. When designing the tools that talk to SQL Server, the original developers of Warewolf decided to create the concept of a source that would store connection information. Multiple stored procedures, for instance could use a single source and thus share connection information. The email tool is an example of a connector that has a source. Users are able to select or create email sources on the design surface, thus reducing development and maintenance time.

Formally, a source is defined as a Warewolf resource that stores shared data that will be consumed by other resources or connectors.

What are we trying to achieve with Custom Tools

A few years ago, it was envisaged most application development would eventually become the process of connecting self-contained pieces of external logic using a common form of communication. The original design of Java beans was an example of an attempt at this. It is only recently however, with the wide spread adaptation of cloud services and REST that this form of “component oriented development” has become possible. Warewolf was designed for this very purpose. It is entirely possible, with the right connector tool development, that a user could read a file from Dropbox, perform some calculations on Wolfram Alpha and then send the results off to a SQL Azure instance for someone else to use with only a few tools dragged onto a design surface. This is the main reason for our push towards developing more connector tools.

The rest of this article will focus on creating a source based connector tool.

Steps to creating a Dropbox tool

    • Create the server side logic class that extends DsfBaseActivity and define the Source as a Property of the class in the Dev2.Activities Project. Each tool input must be a property marked with the Input attribute. The input attribute defines the Debug output for the tool. Each property marked as an input will appear in the studio debug output window and display the values passed into the tool by the containing workflow. In the class defined below, an OAuth source is defined as a property. This source contains shared security information. Note that this development must be carried out according to the development ethos. It is important that multiple functions are wrapped inside a single tool if at all possible. The Warewolf Dropbox tool for example encapsulates the reading and writing of files into a single tool
 public class DsfDropBoxFileActivity : DsfBaseActivity
         public OauthSource SelectedSource { get; set; }
         [Inputs("Source File")]
         public string SourceFile { get; set; }
         [Inputs("Destination Path")]
         public string DestinationPath { get; set; }
         public string Operation { get; set; }
         #region Overrides of DsfBaseActivity
         public override string DisplayName { get; set; }
         protected override string PerformExecution(Dictionary evaluatedValues)
		// carry out dropbox logic here
  • Define the Unit tests for this class in the Dev2.Activities.Tests project. This class must cover at least 90% of the connector tool code.
  • Define the Studio UI designer components, including a dropdown for all the available sources. As with the basic tool, this involves defining XAML and bidnding to a viewmodel class.
  • Define the View Model that interrogates the resource repository for the available sources. The available OAuth sources for example can be retrieved with the following piece of code
  •  Add the new tool to the toolbox by editing the Toolbox user control and the ActivityDesignerHelper class as outlined in the getting started application.

Development Guidelines

Tool Icons must be stored in the Images folder of the Dev2.Activities project and must be in PNG format.

The UI XAML must contain the appropriate intellisense provider for each of the inputs and this must be done declaratively in the XAML.

Each tool must have at least 90% code coverage.

Styles must be consistent with other tools.

Use the correct icons and branding as defined by the application that you are integrating with.


Not what you were looking for? Ask our expert users in the Community Forum.


Rate This Article

(48 out of 135 people found this article helpful)