One of the easiest ways to extend Warewolf is through the use of a Dynamic-Link library, or DLL for short.
Warewolf can easily load a DLL by using the plugin connector. Warewolf can load DLLs from both the Global Assembly Cache or directly from a UNC path. It can consume all public methods in the DLLs that consume and return simple data types.
As the Warewolf Knowledge Base has a very informative article on Using DLLs as a plugin, I won’t cover the how-to detail in this article, but will rather focus on some of the technicalities of using DLLs within Warewolf Workflows.
Using DLLs in Warewolf
Serialized Data Only
Any public method inside a Namespace within a DLL can be accessed, but there are some obvious limitations. Warewolf only works with serialized data, so all of the limitations centre around what can be passed into the DLL methods, and what can be retrieved from them.
As a Warewolf user, you can essentially only pass in integers, Boolean, and string values, and the return types will be returned as string values. Both the input and output string variables can include formatted strings in the form of CSV, XML or JSON data, but no complex data types can be used, simply because they cannot be serialized.
This is not as limiting as it seems. For instance you can return complex document types, such as images, videos, or MS Office documents inside strings, and you could use these return values to perform file operations with.
Public Void methods can also be called
The public methods being called by Warewolf do not have to have a return type. You can also call public methods that are void of a return type. The only disadvantage of void methods is that, as a Warewolf developer, you cannot confirm if the void method was successful. As this is the nature of void methods, this may not concern you. From a monitoring perspective, if you have the option, it may be useful to at least return a Boolean value to determine if the method ran successfully, but it is not essential.
Using Linked DLLs
If you have a DLL that you want to use with Warewolf that relies on another DLL, all dependant DLLs must be located in the same folder. A good measure for this is that all of the DLLs that end up in your bin folder after you compile the DLL with Visual Studio need to be deployed to a single folder that Warewolf can access.
Deploying DLLs with Warewolf Workflows
It is worth bearing in mind that currently Warewolf does not have a mechanism to deploy DLLs consumed by the microservices. You will need to deploy the DLLs with an external process, which can either be a manual or an automated process. So if you are planning to use DLLs within your microservices across multiple servers, you will need to plan accordingly.
You will also need to add connectors to the DLLs manually, and ensure that the connectors are stored in identical locations on your Warewolf servers. This is a once-off task that you need to do for all connectors on your Warewolf servers anyway, and it is simple to set up.
Extending your older code-base lifespan with Warewolf:
Wrapping your pre-.Net DLLs for use within Warewolf
Wrapping your pre-.Net DLLs for use within Warewolf is easy. If you have DLLs developed using a language that does not use .Net, like C++, Visual Basic, or Delphi, you can wrap your older DLLs in a .Net wrapper, and then utilise them inside Warewolf without having to re-develop from scratch.
Disclaimer: this may not work with all DLLs, but we have had success with all the examples that we have tried to date.
Hans Dietrich has written a series of articles on Code Project, called Step by Step: Calling C++ DLLs from VC++ and VB that includes sample code, to get you started.
Leapfrog directly to a Microservices environment with Warewolf
The ability to simply wrap your older DLLs can offer you a tremendous advantage. If you have an extensive code-base in use that has been developed outside of the .Net space you are in luck. This functionality provides you with the opportunity to re-use your established code-base within modern microservice based enterprise architecture. Microservices provide many advantages within the enterprise stack. Couple microservices with Warewolf and you have an architecture that is simple to use and maintain, and highly scalable.
Conclusion
In conclusion, using DLL plugins within Warewolf can rapidly provide you with very powerful functionality, especially in scenarios where the DLL will provide you with possibly once-off or bespoke functionality. Tools are a great option in scenarios where you will get a lot of use out of them, but for limited use, rather save your development resources and simply use a DLL.
There are already countless pre-built DLLs that you can take advantage of by easily leveraging their functionality within Warewolf. I highly recommend you make use of this functionality.
Please feel free to comment below if you have any questions, or for a technical response, please use the Warewolf Community forum.
Leave A Comment?