BizTalk: Configuring /n Software’s SFTP Adapter for Public/Private Key Security

I was recently involved in a project that required secure FTP connectivity between my organization and a partner organization.  We continue to leverage /n Software’s SFTP adapter as we are still running BizTalk 2009 in production and we also find that our partners tend to leverage Secure FTP using SSH (SFTP) as opposed to FTP over SSL (FTPS).  BizTalk 2010 now includes an FTP adapter that supports SSL so we are likely to continue to use the /n Software adapter based upon SSH requirements even once we upgrade to BizTalk 2010.

I am very far from being a Security/Certificate expert so I did learn a few things being involved in this project.  Hopefully if you have Secure FTP requirements that you will find this post helpful.

 

Generating Public and Private Keys

In my scenario, our trading partner required us to provide them with our Public key.  They wanted us to generate Private and Public keys.  They would then take our public key and install it in their SFTP server.  To generate these keys I simply used GlobalScape’s CuteFTP 8.3 Professional.

Note: Your mileage may vary here.  There are some requirements that were enforced by our Trading partner including the Key type and the number of bits required for encryption.

1. Click on Tools -> Global Options

2. Click on Create identity file

3. Use DSA

4. Provide a Passphrase

5. Enter a location for files to be generated and ensure the key length is set to 1024

Configuring BizTalk Receive Location

Since the Receive Location configuration is a little lengthy I am going to break it down into the various sections.

SFTP

Pretty basic settings here dealing with when we want to Delete, what file masks we want to look for and the folder on the remote SFTP server that we want to navigate to once we have successfully established connectivity.

SSH

The first area to focus on in the SSH section is the SSH Accept Server Host Key.  When you set the Accept Any  to Yes the SSH Accept Server Host Key property will revert to Any.  I equate this action with when you try to connect to an SFTP server using a client like CuteFTP.  You will get prompted with a dialog asking if you would like to accept the public key being pushed from the SFTP server.  The way I understand how this works is that this public key will get validated against your private key.  Should everything match up you should be able to establish a connection.

The next property to focus on is the SSH AuthMode.  We want to set this value to be Public Key.  There are a few different options when it comes to setting the Authentication mode.  One includes setting a password but for this particular partner they wanted to use Public Key authentication.  When we set this value we then need to provide the location of our private key which happens to be called Identity (without a file extension).

To provide our Private key we need to click on the ellipse button.

 

We will now be prompted with a dialog that allows us to select our Private key from a variety of sources.  In my scenario I wanted to select my key from the file system.  In order to do so I needed to select the PEM tab and then browse to my key.  Since I have enabled my key to use a password I need to provide a password and then I can click the Open button.  Once I did this my private key would appear in the TextArea box and I can click Ok.

The rest of the configuration deals with some connectivity details including the name of the FICTICOUS Host and a SSH User (a tribute to Steve Jobs who has recently stepped down from being Apple’s CEO) .  The SSH Port is using the default port of 22  and even though it appears as if I have provided a password that is the default mask provided by the adapter.

 

Conclusion

So as much as people love to talk about the cloud these days and using the Service Bus and WCF bindings, the bottom line is that companies continue to rely upon “legacy” technologies such as SFTP.  In my scenario, this trading partner is a very large institution so it is not as if they are a little “Mom and Pop” shop. 

BizTalk 2009 – Be careful when setting Service Windows on Send Ports

 

Note: This blog posts pertains to BizTalk 2009.  It has not been tested against other versions although I suspect the behavior is the same.

We recently had a situation where a downstream system was having issues processing certain types of messages.  We were asked to “queue” messages received from the source system until the issue was resolved.  In order to do this we simply stopped the Send Port but left it enlisted.  Since the Send Port is still enlisted, a subscription still exists within the MessageBox database.  Any messages received while the Send Port is in this state are essentially “queued”.

When you send a message into BizTalk and have the port Stopped(but enlisted) you can expect a Suspended message that has an error description of “Service instance was suspended because the corresponding service (orchestration, sendport, ...) was in the stopped state. Instance can be resumed after corresponding service is started.”

Even with this Send Port stopped, we can still right mouse click on the suspended instance and resume it without issues.

 

We knew that we had to have this send port stopped for a few days while the issue was resolved.  Since we have multiple people working within our Middleware team and also have automated processes to ensure our applications are online, we decided to set a Service Window on the Send Port in addition to having these messages queued as a precautionary measure.

 

 

The intent of this Service Window of 1 second allows us to log into the server before 9am to ensure the Send Port is not started.  Then we would disable the service window and use a time that is before the current time.  The current time, for the purpose of this blog post, is 10:06 am.

If we send in another message with this Service Window we will see a screen much like we saw without the schedule in place.

 

If we check our BizTalkServerApplicationQ table within our MessageBox database we will discover that no records exist:

If we check our BizTalkServerApplicationQ_Suspended table we will discover that metadata exists for our message that we just received.

So what are these tables?  These tables make up BizTalk’s work queues for our BizTalk Server Application Host.  Stay tuned and note which tables have records as you will soon see a discrepancy.

With our message “queued” and our Service Window still set for 9:00:00 am to 9:00:01 am I am going to resume this message and it will be delivered successfully even though the Send Port is stopped. 

Great! So what is the point of this post?  Change your window to be 1 minute instead of 1 second and you will get an entirely different behavior.

With the Service Window set to be 1 minute and with the current time set to 10:21 am, I will now submit another message to BizTalk.  Once again I will get a suspended message.

If we take a look at the BizTalkServerApplicationQ_Suspended table we will discover that our message is in there but is not in the BizTalkServerApplicationQ table

 

When resuming the message this time, it will not get delivered to the end point.  Instead it gets into a “Retrying and idle” state.

If we further investigate this message we will determine that the Message Status is set to “Queued (scheduled for later delivery)”

If we check out the status of our tables in the MessageBox we will determine that the message is no longer in the “Suspended” table.

We can now find the message in the “Q” table.  Also note the Start and End Windows.

So what can we do if we want to resume this message since the Downstream system is now available and they want the 1800 messages that have been queuing up over the past 3 days? 

• Maybe we should remove the Service Window from the Send Port? (hint – it doesn’t help)

• Maybe we should start the app? (hint – it doesn’t help)

• Maybe we should restart the host instance? (hint – it doesn’t help)
• Since the message is in a “dehydrated” state maybe we need to wait 5/10/20 minutes for BizTalk to wake up? (hint – it doesn’t help)

 

There are really two solutions in my mind:

• Wait for the actual service window, with application online and Service Window checkbox removed,  and these messages will get processed – promise.
• Update the service window in the “Q” table so that BizTalk will send these messages when this window is met.  To demonstrate this I will update the table with a timestamp that is in the near future.   It is currently 10:46 am and I will update the timestamp for the window to start at 10:50 am.

Without any intervention the outstanding message(s) will get processed/delivered at 10:50 am.

Key Takeaways

• Be aware that Service Windows are “attached” to the messages as they are being processed.  There is no way to modify this except through the database.
• Changing the Service Window of a Send port where messages already have a Service Window has no effect. (It is too late)
• Setting a Service Window of 1 second has no impact.

BizTalk: HTTP Adapter and preventing Cached Responses

A while back I blogged about a service that would go fetch Natural Gas Prices, the price of Oil and Stock Quotes from Yahoo.    The information that is returned from BizTalk is surfaced in an Xcelsius dashboard along with a lot of other business critical data from SAP.  Our executive team accesses this information from a web part in SharePoint site.  As people launch their browsers, they see the Stock Quotes and other commodity prices get updated.  Since this is a dashboard, people will view the data for a few minutes and then close their browser.  This type of user behavior never uncovered a flaw in the application.  It is not like someone sat on the dashboard all day long waiting for the stock price to change.

A request came in to turn this Dashboard into a Windows 7 widget.  Once this widget was in place, we uncovered that the stock quotes were not being updated.   The Widget simply acts as a container for the dashboard.  So we dug out Fiddler and could determine that the BizTalk service was not being called on a regular interval.  The reason?  Caching.  There was no cache command or expiration date sent on the HTTP header going back to the dashboard so it would not be called on a regular basis.  Since this Widget does not get restarted like a Web Browser does, the stock quotes would remain static for the duration of a user’s desktop session.

To avoid this situation, I needed to provide an explicit command in a Message Assignment Shape to prevent my responses from being cached:

msgStockQuoteResponse(HTTP.UserHttpHeaders) ="Cache-Control: no-cache";

Since the client was instructed not to cache the response, it would now go ahead and call the service when it goes to refresh the rest of its data.

 

 

There are many options that you can set within the HTTP Header.  For example,  if you wanted to expire content every 2 minutes, you could set your header to  Cache-Control: max-age=120.  If you are interested in what other features can be set in an HTTP Header, I recommend checking out this site.

BizTalk 2009 + SharePoint/WSS 3.0 integration first look

The organization that I work for is leveraging SharePoint heavily due to its nature of it being a collaboration platform. Much like we leverage BizTalk to minimize the amount of custom work to integrate, we leverage SharePoint to reduce the amount custom work to collaborate.

We currently run MOSS 2007 and were running BizTalk 2006 so we haven't had many opportunities to attempt this integration since BizTalk 2006 only supports Windows SharePoint Services 2.0. The way I understand it, MOSS 2007 is built upon WSS 3.0 so BizTalk 2009 is capable of communicating with either WSS 3.0 or MOSS 2007. A difference between the two is that WSS 3.0 is free where as MOSS 2007 requires licenses. I am not going to further differentiate the two but will leave you with this link instead.

If you are already familiar with BizTalk and SharePoint integration then you may want to move on (you probably won't learn much from this post). The idea behind this post is to help out the new comers to this integration scenario. I recall having several questions when starting out so I figured putting together some answers to these questions may save some people some digging.

The very first thing that you need to do before cracking open any tools or downloading any install packages is watch Mick Badran's Web cast on SharePoint integration. For those of you who don't know Mick he is a BizTalk MVP and if Microsoft allowed it he could probably be a SharePoint MVP as well. This web cast help me out tremendously!

Reducing the confusion

1. While the Windows SharePoint Services Adapter shows up in your list of adapters in BizTalk Admin, it doesn't mean that it is ready to be used. The BizTalk - SharePoint Services Adapter is not able to work all on its own. In order for you to use this adapter, you need to install the BizTalk - SharePoint Services Adapter Web Service. Confused yet? This adapter web service knows how to intelligently call the SharePoint API. While you could call these SharePoint Web Services directly, the BizTalk Adapter abstracts this complexity away from you. You will not require any Web Service Proxies in your solutions which is a big plus.
   Once installed, a virtual directory will appear in your SharePoint Site.


2. Update - You only need WSS installed on your BizTalk servers if you plan to host WSS sites on your BizTalk servers. If you plan to connect to remote WSS or MOSS servers you do NOT need WSS installed on your BizTalk Servers.
   
3. Follow the BizTalk install guide! This should be a given but don't try to 'assume' your way through the install and configuration of WSS. There are some decisions like ensuring that your WSS install is part of a Server Farm even if you are running it on one BizTalk Server. Here is the link.


4. There are some 32 bit/64bit considerations - read the fine print carefully.


5. In distributed environments, create your AD groups/accounts ahead of time.


6. Leverage any SharePoint resources you have available to you. I have used SharePoint, as a user, for quite some time but there is still some terminology that I am not too familiar with (Lists, Document Libraries, Workspaces, BDC etc). I had a SharePoint colleague give me a 10 minute walk through of creating Document Libraries, Custom Views etc and it went a long way.

All in all I am pretty pleased with the experience. Within a couple hours I had WSS 3.0 installed, the Adapter Web service installed and configured and am pushing/pulling documents into/from WSS 3.0 via Send Port Subscriptions.

Expect a few more posts on this subject as I plan on taking this topic a few steps further by integrating with InfoPath and LOB systems.

BizTalk 2009/Windows 2008 - Clustering SSO issue

During the clustering and configuration of the Enterprise Single Sign on service we ran into the following issue when trying to restore the master secret.

C:\Program Files\Common Files\Enterprise Single Sign-On>ssoconfig -restoresecret
C:\mastersecret\SSOD04F.bak
Password reminder : *Reminder*
Password : ********
ERROR: 0xC0002A0F : Could not contact the SSO server '*PhysicalNode*'. Check that SSO
is configured and that the SSO service is running on that server.
(RPC: 0x800706D9: There are no more endpoints available from the endpoint mappe
r.)

I thought it was odd that the *PhysicalNode* was showing up in this error message since I was expecting the virtual server name to show up.

Upon checking the status of SSO I was provided the following information:

C:\Program Files\Common Files\Enterprise Single Sign-On>ssoconfig.exe -status

Using SSO server on this computer

SSO server : *PhysicalNode*
SQL Server : *SqlClusterName*\*SQLClusterInstance*
SSO Database : SSODB
Service Account : domain\*SSOUser*
Cluster Name : *ClusterName*
Node Name : *PhysicalNode*
Event Counts (Info/Warning/Error... : 9/11/0
Version : 6.0.245.0
Password Sync Age (in hours) : 0
Audit Levels (Positive/Negative) : 0/1

Server status : Online
Secret server running : Yes
Password Sync loaded : No
Password Sync from PCNS running : No
Password Sync from MIIS running : No
Password Sync from adapters runn... : No
Allow password changes from PCNS : No
Allow password changes from MIIS : No
Clustered server : Yes
64 bit server : Yes
Using SSL for SQL connection : No
Case sensitive : No
Allow remote lookup : No
Local administrator : No

Having the Physical node being displayed as the SSO Server is a problem. I would have expected that the Cluster Resource group Server name should have been populated in the SSO server field.

Even though we already ran the ssomanage -updatedb XMLFile command I figured that I would run it again. (What is the definition of insanity, running a task over and over again but expecting a different result?) So when we ran this command and included our Cluster Resource group server name in the file, it still did not have an effect even though the command was "successful".
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.

After hunting through the online documentation, I ran into the following:

If you do not click to select the Use Network Name for computer name check box, SSO client computers will generate an error similar to the following when they try to contact this clustered instance of the Enterprise SSO service:
Failed to retrieve master secrets.
Verify that the master secret server name is correct and that it is available. Secret Server Name: ENTSSO Error Code: 0x800706D9, there are no more endpoints available from the endpoint mapper.

The error messages are different, but it did seem applicable to our situation. I then went into the Failover Cluster Managment MMC and found that the "Use Network Name for computer name had not been checked off".

We also had to add a Network Name and IP Address as dependencies for this configuration to be set.

Upon bouncing the ESSO service and running the ssomanage -updatedb XMLFile and ssoconfig.exe -status commands the proper SSO Secret Server name was being populated. After performing these steps, we were able to restore the Master Secret server on all nodes without issue.

BizTalk 2009: Unable to configure BAMArchive

When trying to configure the BAMArchive database on a fresh BizTalk 2009 64 bit install, I encountered the following error:
Microsoft SQL Server 2008 Data Transformation Services (DTS) for BAM Archiving is not installed on the local machine. Please install Microsoft SQL Server 2008 Integration Services.
...
Could not load file or assembly 'Microsoft.SqlServer.ManagedDTS, Version=10.0.0.0,

This error makes it sound like you need to install SQL Server Integration Services (SSIS) which is a little misleading.

The documentation on MSDN indicates the following:

What 64-bit SQL Server components are required to configure BAM tools?
The configuration wizard is a 32-bit process; therefore it requires certain components which allow it to communicate with 64-bit SQL Server. You must install the following SQL Server client components to enable configuration of BAM tools:
Connectivity Components
Management Tools
Legacy Components

http://msdn.microsoft.com/en-us/library/aa560166(BTS.10).aspx

In order for me to complete my installation, I installed the following components from the SQL Server 2008 media(I don't see the Legacy Components option).

BizTalk 2009 64bit: Missing sapBinding in BizTalk admin and VS .Net 2008

I have been running BizTalk 2009 for quite some time now including the Beta version. Up until now, all of the work that I have been doing was on a 32bit platform. Now that we are moving to a 64bit platform, I am starting to run into some more challenges related to 64bit.

I installed the 64bit version of the WCF SDK SP2. I then went and installed the 64bit version of the BizTalk Adapter Pack 2.0. I opened a project that I had previously built on a 32 bit machine and successfully deployed the application to my 64bit laptop. When I attempted to import the binding file that had been previously used on the 32 bit solution, I got the following error:

At this point I tried to create a new send port that uses the Custom WCF Adapter. I clicked on the "Binding" tab and then on the pull down to see just what bindings had been registered. Here is what I found:

As you can see the sapBinding is no where to be found. I was curious to see what Visual Studio was seeing when I called upon the Consume Adapter Service. The error message that I received was "No valid adapters are installed on this machine"

After some digging, I was able to find the following link on TechNet which discusses the SQL Adapter, however the behaviour applies to the SAP Adapter as well.

Cause
The SQL adapter is a WCF custom binding, which is registered under System.ServiceModel in the machine.config file. A 64-bit platform has two machine.config files, one used by the 32-bit applications and the other used by the 64-bit applications. So, when you install the 64-bit version of the BizTalk Adapter Pack, the setup wizard registers the bindings in the 64-bit version of the machine.config file. However, Visual Studio runs as a 32-bit process and hence when you launch the Consume Adapter Service Add-in from Visual Studio, the plug-in checks for the bindings in the 32-bit version of the machine.config file and fails giving an error.

Resolution
Install both the 32-bit and 64-bit versions of the BizTalk Adapter Pack on a 64-bit WCF LOB Adapter SDK installation.

The document also stresses that you should only install the 64bit version of the WCF SDK SP2 as you cannot run this SDK side by side (32 & 64 bit)

So this explanation deals with Visual Studio, but what about the BizTalk Admin Console? Well, it runs as a 32 bit process as well which explains why the Adapter is not visible inside the console. After installing the 32bit BizTalk Adapter Pack 2.0, the sapBinding will now appear.

Suddenly, I am not as excited about the 64bit platform as I was previously.

BizTalk 2009 - Silent/Unattended Install

I am currently involved in a BizTalk 2009 upgrade. We are lucky enough to get some new hardware that screams and we are now running 64bit. We are taking this opportunity to try to streamline our server deployments. This includes Rapid Deployment images at the OS level and scripting as many installs as possible based on server naming convention.

When I was asked whether BizTalk could be silently installed I assumed it could be but had to do some investigation. This is when I stumbled across this page: http://support.microsoft.com/kb/971655

Initially we thought about silently installing all components and then just configuring the features that we needed (No EDI). This was a good idea until we got an error message indicating that the install could not continue because we didn't have VS 2008 SP1 installed. The purpose of these scripted deployments were to target our Test/Prod BizTalk and SQL farms. Since these servers would be used in Test and Prod we did not want VS 2008 installed.

The next option was using the /S switch which allows you to provide a configuration file that would include all of the features you want to install. The problem is that the document is not real explicit about where you would find this configuration file or the format that the file needs to be in.

/S Performs a silent installation of features found in the specified configuration file. Note To install all features, specify ALL for the parameter of the configuration XML file.

After some pointers from Matt Milner, Alan Smith and Bill Chesnut I was able to get this working.

Here are the steps that you need to follow in the event that you have a farm where you want installations to be consistent across the farm:

1. Download Pre-requisite Cab files. (Thiago has the links on his blog)


2. Mount Media


3. Install BizTalk on initial node


4. Configure BizTalk on initial node


5. Export configuration file based on initial configuration


6. When you open the file, you will find a lot of information but the key information that you need are in the "InstalledFeature" tags.
   
   
7. Now that you have this file, you can use it as in input to your silent install command. Here is the command that I used:

x:\Setup.exe /CABPATH "x:\temp\BTSRedistW2K8EN64.cab" /S x:\ScriptedInstallDir\ExportedConfigurationFile.xml /L c:\temp\BizTalkInstall.log /FORCERESTART /INSTALLDIR "x:\program files\Microsoft BizTalk Server 2009"

Note: I initially tried the install using the the /QUIET switch but was then prompted with an error indicating that I could not provide a configuration file and use the "Quiet" switch. This wasn't the end of the world for me as an interface is displayed but it does not require any action - no buttons or prompts to click through.

So if you have a farm you will probably want to take advantage of this features since it will save you a little time and will ensure that you have a consistent install across the farm. It doesn't help you much with your initial installs though.

BizTalk 2009: NSoftware Adapters 3.5.3477

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.