Home › SharePoint › Application Development › SharePoint for Cisco Fanboys (and more developers) – Part 4

SharePoint for Cisco Fanboys (and more developers) – Part 4

Posted on Posted in Application Development, Cisco, Infrastructure, Networking, SDK, Security, SharePoint, Web Services 3 Comments

Welcome to part 4 of my series on demonstrating SharePoint’s usefulness for storing Cisco configuration backups. What a hard slog it’s been! The last article (part 3) of this series focused on how to modify an open source C# TFTP server to upload files into a SharePoint document library using the SharePoint SDK.

Here is the quick recap on what we have covered so far

  • Part 1 illustrated how it it possible to use SNMP to tell a Cisco IOS device to dump its configuration to TFTP. We talked about the version control feature of SharePoint and why it makes sense to TFTP your configs to a SharePoint document library. We covered the WEBDAV network provider supplied with XP and Win2003 and finished off with a basic example using the TFTP server TFTPD32.
  • Part 2 went into more detail about the issues you can face when using the WEBDAV network provider. It also went into more detail on 3 TFTP server products (WinAgents TFTP, SolarWinds TFTP Server and TFTPD32 and why TFTPD32 ended up being the best choice for this purpose.
  • Part 3 then looked at a wonderful open source TFTP server written in C# called TFTPUtil. We modified the source code of this TFTP server to use the SharePoint SDK and upload files to a SharePoint document library.

Now both the WEBDAV and SDK methods had some issues. The WEBDAV method was obviously easy to set up because pretty much any application (theoretically anyway) can be made to work with it. I, however, had reliability issues with this method as part 2 detailed. The SDK method was much more reliable, but had its own problems. Many people would be uncomfortable with having to perform custom modification of an existing open source TFTP server, but more importantly, there are security implications with this method too.

So we have one remaining method that we can explore. This method is still based around modifications to the TFTPUtil source code but instead of using the SharePoint SDK, we instead use the SharePoint web services.

SharePoint 2007 Web Services

SharePoint can be remotely interacted with via Web Services. Out of the box, a number of web services are provided and shown below (along with the URL of the service based around my sample SharePoint server used in this series).

So let’s go back to our TFTPutil project in Visual Studio and use Web Services instead of the SDK

Modification Example #2 Web Services

Initially I thought that I was going to have to write my own web service to upload a file to SharePoint, but like TFTPUtil, it didn’t take much googling to find that the hard work had already been done.

In this case, it was the excellent work by txs8311. He had written some articles on how to upload into SharePoint via methods provided by the out of the box web services. We will incorporate his work into TFTPUtil and see how it goes!

Out of respect for txs8311, I will not re-paste his code here, but I will show how I have incorporated it into TFTPUtil.

If you check his blog post, he has created a class called DocLibHelper. We will add this as a class to TFTPUtil and then call it from the TFTPServerProcess class that we modified in my last post.

So let’s go back to our TFTPUtil project in Visual Studio and add a new item to the project. Add a class and call it DocLibHelper.

image

image \

Once added, paste the content of the DocLibHelper class from txs8311’s site. Do not forget to add the references to the libraries used by the code.

using System;
using System.Collections;
using System.Collections.Generic;
using System.Text;
using System.Net;
using System.IO;
using System.Xml;

Finally, the code interacts with the Lists web service (lists.asmx) and we need to add a reference to a SharePoint web service so we can compile and test the code against the lists web service. From the “Project” menu, choose “Add Web Reference”. In the URL, connect to the lists service for your SharePoint server (in my case http://tidemo/_vti_bin/Lists.asmx)

image

You MUST name this Web Reference ListsService as txs8311’s code expects it to be this name.

image

That’s it for the webservice code! Now let’s modify the TFTPServerProcess class to use it! (I go into detail on modifying this class in the previous post).

State.Close();
if (IsSharePoint){    
    // Now we add this newly downloaded file to the document library
    try
    {        
        DocLibHelper docLibHelper = new DocLibHelper();
        Dictionary<string, object> properties = new Dictionary<string, object>();
        properties.Add("Title", State.Filename);
        string uploadURL = TempPath + @"/" + State.Filename;
        //Create or overwrite text file test.txt in 'Docs' document library creating folder 'Test Folder' as required.
        docLibHelper.Upload(uploadURL, System.Text.Encoding.ASCII.GetBytes(FullPath + @"/" + State.Filename), properties);
 
        // clean up temp file
        File.Delete(FullPath + @"/" + State.Filename);
    }
    catch (Exception ex)
    {
        AddMsg(Level.Verbose, "Problem opening SharePoint site" + TempPath);
        AddMsg(Level.Debug, "Exception: " + ex.Message + "\n" + ex.StackTrace);
    }
}
// This is the last block so go ahead and setup to delete stateStopListener(); 
StopListener();

So let’s have a closer look at this code. Now we are invoking an object based on txs8311’s the DocLibHelper class, rather than the SharePoint SDK classes. After creating an instance of DocLibHelper, we create a dictionary object to hold the properties of the file. We will write the name of the file to the “Title” column (the result of which you will see later).

We then call the Upload method, passing in the URL, a reference to the file to be uploaded and the properties dictionary.

One little gotcha!

One minor thing that I have to mention here, as I got caught by it. Web Services are case-sensitive! The invocation code on the console application was the following:

TFTPServer myTFTP = new TFTPServer();
myTFTP.AllowWRQ = true;
myTFTP.AllowWRQOverwrite = true;
myTFTP.Path = @"http://tidemo/tftp/backups";
myTFTP.StartListener();

But in SharePoint the document library is actually called “Backups”. See the problem? I kept getting exception errors telling me “List not found”, and it took me a while to twig to the fact that I had to fix up line 4 of the above code.

myTFTP.Path = @"http://tidemo/tftp/Backups";

Now that oughta do it! Let’s test!

Now we attempt an upload.

C:\>TFTP 192.168.134.129 put c:\myfile.txt
Transfer successful: 43552 bytes in 1 second, 43552 bytes/s

Sweet!

Let’s check the document library. First up view properties so we can see the title field. Very good.

image

Okay now let’s do a few more TFTP PUT’s.

C:\>TFTP 192.168.134.129 put c:\myfile.txt
Transfer successful: 43552 bytes in 1 second, 43552 bytes/s

[snip]

C:\>TFTP 192.168.134.129 put c:\myfile.txt
Transfer successful: 43552 bytes in 1 second, 43552 bytes/s

So let’s look at the version history. What do you see now? SharePoint will report changes to properties (column values) in the version history. Version 285 of myfile.txt was the version where I updated the title property.

image

This method works nicely. The only problem I encountered was a delay after the first running of the program. To connect to the lists webservice, authenticate and call the necessary methods a little while on the first attempt. But subsequent attempts were fine. Since I did this on a VM on a heavily loaded laptop, it may not be noticeable in a prod environment at all.

Modification Example #3, FrontPage Extensions and RPC

txs8311 also wrote a second part to his posts on uploading files into SharePoint. In this post he rewrote his DocLibHelper class to use FrontPage extensions and RPC. I did not try this, as I was satisfied with the modification Example #2. But all you should need to do, is replace the code in the DocLibHelper class with the code from his page.

If you are more keen than me, feel free to give it a shot and let me know how you go!

Summary of Upload Methods

So let’s recap on the three TFTP upload methods that we have used and summarise the advantages and disadvantages of each.

Method Advantages Disadvantages
WEBDAV Compatible (in theory) with most applications
Choice of TFTP Servers
TFTP Application does not need to run on the SharePoint server		 Stability/Reliability issues
Cannot update metadata/document library columns
SharePoint SDK No stability/reliability issues
Ability to update metadata/document library columns		 Applications need to explicitly support this method
Custom TFTP Server needed to be modified
Application must run on a SharePoint farm server
Application requires administrative privileges on the server it runs from, has to be a farm administrator and requires read/write access to the Sharepoint SQL databases
SharePoint Web Services No stability/reliability issues
Ability to update metadata/document library columns
TFTP Application does not need to run on the SharePoint server		 Applications need to explicitly support this method
Custom TFTP Server needed to be modified

CleverWorkArounds Rating: Rock on SharePoint Web Services!

Additional Coolness

Since we have modified this TFTP Server to our requirements, you are pretty much free to add SharePoint specific features to make integration even nicer. One feature that springs to mind is setting more metadata properties when the files are uploaded. Here is an example. Let’s assume that we have a list of Cisco IP addresses and the MODEL and TYPE of device on that address. E.g 6509 Switch, 3725 Router or Aironet 350 Wireless Access Point.

It would be pretty easy to modify our TFTP server to be able to examine this list when receiving a file and based on the IP of the sender of the file, write the type of device to a “Device Type” column in our configuration backups library.

Better still, it would then be very cool if that list of IP’s and device types already exist in SharePoint. Imagine this list exists in the form of an IP address register or better still, an IT device asset register (along with serial numbers, maintenance contract information and the like). It would be easy for staff to maintain this information and the list would have version control just like our “Backups” document library. But for me what would be really nice about this method is the organisational efficiency that would be gained.

That gain is this: The person that updates the asset register list isn’t necessarily the Cisco engineer that sets up the device. Critical device information is entered ONCE and leveraged from then on. The next post in this series will expand on these benefits.

Conclusion

Right! We are DONE with getting files into SharePoint and about damn time too!

The next posts in this series will move away from application development and infrastructure issues and move into some higher level governance issues. The aim here is to show Cisco and IT infrastructure people what you can do with SharePoint once you get the data into SharePoint. I hope if I do a decent job of writing it, that it will be easy to see just how this can be re-used for any IT infrastructure management.

But for now, I bid you adieu until then….

3 Comments on “SharePoint for Cisco Fanboys (and more developers) – Part 4”

  1. Another approach that involves much less coding since it uses existing Web Services is to
    1. Upload the File to a PictureLibrary
    2. Copy the File from there to a DocumentLibrary

    A HOWTO along with an complete example project is available here.

  2. hi, is there any way of accessing sharepoint web services
    through an ISA 2006 reverse proxy that is using Forms Based Authentication?

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.