In the past I have blogged about /n Software and their SFTP Adapter here and here. Hard to believe one of those posts goes back to 2007. One thing that /nSoftware continues to do is add new adapters to their suite. In this case it is the Powershell Adapter.
Can’t say that a Powershell Adapter previously was on my radar until a scenario was brought to me. We have a very specialized piece of software that does “analysis” (I will leave at that for now). This software is essentially a library that has been wrapped around an exe. This exe will receive a series of parameters including a path to a file that it will use to perform its analysis on.
A suggestion was brought up about calling this exe using Powershell. While I am sure we could call this from .Net the Powershell warranted some investigation. So sure enough in a web search, /nSoftware comes up with an offering and sure enough we had it installed in all of our environments.
Since BizTalk is going to deliver the flat file used as an input to this process, I decided to check out the Powershell Adapter and allow BizTalk to orchestrate the entire process. For the purpose of this blog post I will over-simplify the process and focus more on a POC than the original use case.
As part of the POC I am going to receive an xml file that represents our Parameter data. We will then send this same message out through a Send Port that is bound to the /nSoftware Powershell adapter.
In order to help illustrate this POC, I have a console application that will simply receive 3 parameters and then write the contents to a file in my c:temp folder. The reason why I am writing to a file is that when I call this exe from Powershell I don’t see the console window being displayed. Perhaps there is a way to do that but I didn’t look for a solution for that.
namespace PowerShellPOC
{
class Program
{
static void Main(string[] args)
{
string[] lines = { args[0], args[1], args[2] };
// WriteAllLines creates a file, writes a collection of strings to the file,
// and then closes the file.
string filename = DateTime.Now.ToString("ddMMyyyymmhhss") + ".txt";
System.IO.File.WriteAllLines(@"C:\temp\" + filename, lines);
}
}
}
In hindsight, I should have just built a send port subscription but here is my orchestration.
Using a standard FILE – receive location
On the Send things start to get a little more interesting. We will create a Static One-Way port and select the nSoftware.PowerShell.v4 Adapter.
Within our configuration we need to provide a Port Name (which can be anything) and our script.
If we click on the Script ellipses we can write our PowerShell script. In this case we are able to retrieve our message that is moving through our Send Port and pass it into our executable.
If we only wanted some data elements we can also use $param3 = $xml.arguments.ReturnType
In this case “arguments” is our root node of our BizTalk Message and “ReturnType” is a child node in our XML Document.
When we go to process a file we will find that our text file has been created and it contains our 3 parameters; 2 that are hard coded and our BizTalk Messsage Payload.
Conclusion
When I think of BizTalk, I don’t necessarily think of Powershell. But there will always be times when you need to perform some function that is a little bit off mainstream. What I do like about this approach that there was no additional custom dev required to support the solution and we can use the actual BizTalk message in our Powershell script.
I am still exploring the capabilities of the adapter but after a dialog with the /nSoftware team I understand that remote Powershell scripts can be run and we can also use Dynamic ports and Solicit Response ports if we want to return messages from our PowerShell script to BizTalk.
For more details please check out the /nSoftware website.
