UPDATE: Note this post has been updated see below.
There are some new features that are part of the nSoftware Adapter pack version 3.5.3477 that was recently released. I have
blogged about these adapters before and continue to use them at my ogranization so I figured I would post an update.
What adapters are included in this bundle?AS2 Adapter - eBusinessReady Certified AS2 (EDI-INT) Adapter.
FTPS Adapter - SSL-Enabled Secure FTP Adapter for BizTalk.
SFTP Adapter - Secure Shell (SSH) Enabled FTP Adapter for BizTalk.
OFTP Adapter - Odette File Transfer Adapter for BizTalk.
Credit Card Adapter - Credit card transaction processing Adapter.
RSS Adapter - RSS Client integration Adapter.
Secure Shell (SSH) Adapter - Secure Shell Remote Execution (SExec) Adapter.
Secure Email Adapters - Secure Email (SMTP/POP/IMAP) Adapter.
SMPP Adapter - Short Message Peer-to-Peer SMS messaging Adapter.
SNPP Adapter - Alphanumeric paging Adapter.
XMPP Adapter - Jabber / XMPP Instant Messaging Adapter.
S3 Adapter - Integration with Amazon Simple Storage Service (S3).
Zip Pipeline Component - PKZip/Winzip compatible Zip compression/decompression.
Gzip Pipeline Component - UNIX compatible (LZW/LZC) Gzip compression.
ACH Pipeline Component - Electronic Check (ACH) message processing.
PGP Pipeline Component - PGP Sign, Verify, Encrypt, and Decrypt.
What about BizTalk 2009?BizTalk 2009 is fully supported
64bit support?Yes, unlike the Microsoft out of box adapter you do not have to run this FTP adapter in a 32 bit host.
What is new with the adapters?Support for temporary folders now exists in the S/FTP adapter. In the previous versions of the adapter they supported a temporary file extension. They now support a temporary folder. This temporary folder is an important feature due to the reliability concerns involving FTP. The purpose of this folder is that you write the entire contents to this dirctory and once all contents have been delivered, a command is executed(under the hood) that will move the file from the temp folder to the destination folder. The tempory file extension had a similar purpose but if a down stream system is only looking at the first portion of the file name it won't relize that it has a temporary file extension until it is too late. The Microsoft FTP adapter also supports the notion of a temporary folder, however it is only available in Binary mode. This doesn't help out in heterogeneous environments (Win and Unix) where CRLF characters mean something different to each system.
All adapters now support Dynamic and Static modes. Believe it or not previous versions of the adapters never fully supported a dynamic mode. I previously blogged about how you could make a static port "dynamic like" by overriding certain context properties, but you still had to have a Static Send Port.
I ran into a couple gotchas while testing out this new dynamic ability so I figured that I would put together a post. Here I have a very simple solution that will receive a file via the File Adapter. I then copy this inbound message to an outbound message of the same type, update a few context properties, set the dynamic URI in an expression shape and then send the message out through a logical dynamic Send Port.
In order to access the nSoftware context properties in the message assignment shape, I needed to add a reference to my BizTalk project. You will find this Dll in the Adapter's install lib directory.
You can override pretty much any context property that you can think of:
I was only interested in setting a few properties to keep this post simple. I set the following properties:
- User (Username)
- Passsword
- SSLStartMode
- Override
The SSLStartMode property is important. Technically this adapter is an SFTP adapter and if you choose not to use SSL then it basically becomes a FTP adapter. The default is to have SSL enabled so I have decided to turn it off.
The next thing that I need to do is set the URI for this dynamic logical port. If you look closely you will notice that my URI contains the "ftp" protocal identifier. So how does BizTalk know to use the NSoftware adapter or the Microsoft adapter? No, you don't have to uninstall the Microsoft adapter.
A context property that was new to me is the
Microsoft.XLANGs.BaseTypes.TransportType property. This property must have shown up in BizTalk 2006 R2 with the introduction of the WCF adapter. A similar situation would otherwise happen since indicating "http" in your dynamic URI would be a cue for the HTTP adapter to send the message. If you go into the BizTalk admin console and down to Platform Settings -> Adapters you will see that the nSoftware adapter is referred to as
"nsoftware.FTP v3".
I initially ran this project against a Windows environment but then had some problems with connecting to a Unix server. I am not so sure that it is a Unix issue per say but perhaps the way we mount different disks to our Unix Servers? In any event I had to make a few changes to the context properties that I set in the Message Assignment Shape:
- I populated the Remote path with the full directory structure
- Set the RemoteFile property with the name of the file that I wanted to send
In the Expression shape where I populate the dynamic URI, I had to provide less information. I only need to be concerned with providing the server name as the folder and file name information has been populated in the context properties.
***UPDATE***
The "abnormal" situation that I encountered with the Unix environment has been fixed in version 3.5.3488. You can obtain this release from nSoftware support support@nsoftware.com
***************
So why the nSoftware adapter?
I think most people who have chosen the nSoftware adapters have done so primarily for their SFTP and FTPS adapters. Out of the box, Microsoft does not provide an FTP adapter that supports security. Meanwhile FTP remains a popular protocal when exchanging information with internal and external systems. When connecting with external systems, usually some sort of security is required. There is also a SFTP adapter on codeplex. I have never used it, but it has some pretty good reviews. I would not be able to introduce this adapter into my environment due to it being open source which leaves me to look at a 3rd party like nSoftware.
The ability to use a temporary folder or file extension may also be enough for some customers who have a mixture of environments that they communicate with. FTP is not all that reliable as it is so having these features provides you with a little more durability.
When I went back and ran the ssoconfig.exe -status command it still indicated that the SSO secret server was the phyiscal node and not the Clustered Resource group server name.
We also had to add a Network Name and IP Address as dependencies for this configuration to be set.
