After a couple of failed starts, I finally decided to start this project. The idea came to me when the first version of the Relay was launched in the Azure Service Bus, when it was still called “BizTalk Services”, but only now do I have the time to work on it.
The idea is the following: very often I have problems connecting to my company’s VPN and Intranet, either because of firewalls in the sites I’m working at or other connectivity problems, making me have to use email to ask people to send or upload documents. The Azure Service Bus offers a great way to work around this problem. The first concept was thus to develop some kind of Windows App that could connect to a SharePoint intranet behind a firewall via the Service Bus and browse its contents, but I decided to develop a command line client instead, supporting FTP-like commands.
This approach not only offers the potential for scripting, but allows for a convenient “structure-transparent” navigation: SharePoint has several hierarchy/structure concepts (web applications, site collections, sites & sub-sites, document libraries, folders within document libraries, document sets, to name some). I wanted the navigation in this space to be fully abstracted. For example, a command like “ls” would list all these structure elements as if being the same – a “folder”, and documents as… well, documents. In a command like “cd folderName”, folderName could also correspond to any of the above structural elements. Someone using the client tool would not have to worry about which.
The current architecture is the following:
- A command-line client that the user starts and uses just like FTP, supporting commands such as open (authenticate and connect to a SharPpoint), get (get a file), cd (change folder), ls/dir (list contents) and close (close connection).
- A windows service exposing a set of operations via the service bus. The operations map with each of the commands enumerated above. The option for a Windows Service was based on convenience: they can be easily installed and don’t depend on IIS [1]. On the other hand, the service can be running anywhere in a customer site, and it’ll work as long as it can reach SharePoint. It can even be running in a DMZ, with more controlled connectivity. The interaction with SharePoint will be done using ClientOM.
One important note regarding the above is that the service operations will be stateless (I will probably have to setup some kind of cache/pool on the service side for perf reasons), but the client will have to keep state, such as the current base site, credentials, and “folder”.
In terms of the technology stack, this is what I envision at the moment:
- .Net 4.5/x64/VS2012
- Windows Azure Service Bus
- WCF 4.5
- Irony for language parsing on the client app
- Wix Toolset for generating setups (install projects are missing from VS2012…)
- Log4net 1.2.11
As of today, and note this is all very early, the status is:
- Visual Studio project structure is created
- Wix installer project generates an msi installer for the windows server
- Logging is integrated and configured in the server
- Windows Service code includes draft contracts of the operations to support, and these are already exposed via HTTP [but not in the service bus yet]
- SharePoint Library Manager code contains some early sample code to authenticate with the product
- The client app is still empty, but the Spike.Irony project contains a first version of the grammar of commands and a command input loop, which I’ll migrate to the client when I’m happy with it
All this said, I’ll be posting relevant notes about AzureFtpForSharePoint here, and the code itself is publicly available on GitHub: https://github.com/lokijota/azureftp-for-sharepoint . I have also enlisted the collaboration of some colleagues to help out in the development (especially on the SharePoint side), but feel free to drop me a line or try it out if you are interested.
[1] Having experience of using the pre-BizTalk Server 2013 adapter for SharePoint, which requires an installation on the IIS of the SharePoint Servers, I know this can be a setup/configuration headache.
