Many developers new to SharePoint want to know how to get content into SharePoint from another application. This application is usually a remote application either running in a asp.net application or a desktop application. The developers may be familiar with the SharePoint object model and how to use it to put content into SharePoint. However, when it comes to doing this remotely there seems to be a lot of confusion. This confusion is brought on by the fact that there are numerous out of the box ways of doing this. You can put content into SharePoint by using web services, WebDav or frontpage remote procedure calls. The problem arises when developers chose a method and find out that certain methods don’t support certain functions that you would normally see either from the SharePoint UI or from the SharePoint object model. This article will give you a brief description of the methods available for remotely putting content into SharePoint and compare the methods based on certain factors you should be aware of as a SharePoint developer. These factors include complexity, folder creation, scalability and indexing. Complexity and scalability are rated on a scale of 1 through 10.
| Method | Complexity | Scalability | Indexing | Folder Creation |
| Copy.asmx | 5 | 4 | yes | yes* |
| WebDav | 2 | 5 | yes* | yes* |
| Rpc | 10 | 10 | yes | yes |
* must be used in conjunction with Lists.asmx web service
Copy Web Service
To create content remotely the copy web service is probably your best bet. The copy web service enables you to create new documents and send the metadata for indexing in one call. This makes the web service more scalable. Many times users want to create a new folder to store their documents. Unfortunately, the copy web service does not have a method for creating a folder. The following is a code snippet for creating new content in SharePoint via the copy webs service:
public static void CreateNewDocumentWithCopyService(string fileName)
{
copyservice.Copy c = new copyservice.Copy();
c.Url = "http://servername/sitename/_vti_bin/copy.asmx";
c.UseDefaultCredentials = true;
byte[] myBinary = File.ReadAllBytes(fileName);
string destination = http://servername/sitename/doclibrary/ + Path.GetFileName(fileName);
string[] destinationUrl = { destination };
copyservice.FieldInformation info1 = new copyservice.FieldInformation();
info1.DisplayName = "Title";
info1.InternalName = "Title";
info1.Type = copyservice.FieldType.Text;
info1.Value = "new title";
copyservice.FieldInformation info2 = new copyservice.FieldInformation();
info2.DisplayName = "Modified By";
info2.InternalName = "Editor";
info2.Type = copyservice.FieldType.User;
info2.Value = "-1;#servername\\testmoss";
copyservice.FieldInformation[] info = { info1, info2 };
copyservice.CopyResult resultTest = new copyservice.CopyResult();
copyservice.CopyResult[] result = { resultTest };
try
{
//When creating new content use the same URL in the SourceURI as in the Destination URL argument
c.CopyIntoItems(destination, destinationUrl, info, myBinary, out result);
}
catch (Exception ex)
{
}
}
The benefits of using the copy web service is that it is simple to code against. Most developers are familiar with the web service programming. Also the copy web service supports creating content and metadata in one call thus not creating multiple versions. Unfortunately, this method suffers from one problem and that is the use of byte arrays. If you plan on uploading large files lets say in excess of 2mb, then chances are you will receive sporadic “out of memory” errors. It may not happen on your development server but may happen on your production server. This is because the windows OS needs to allocate byte arrays with contiguous memory. If the server’s memory is fragmented (has a lot of available memory but not much contiguous memory) then you will receive this error. Thus, the copy web service is not very scalable. Finally, web services tend to be verbose given their soap protocol and the marshalling from string to native types makes them slower than other methods.
WebDav
Most developers are familiar with WebDav because it is used to display document libraries in Windows Explorer. Here the familiar dragging and dropping of files into SharePoint can be accomplished. You can accomplish the same thing by using the System.Net.WebClient class as follows:
public static void UploadFile(string fileName, string destination)
{
WebClient wc = new WebClient();
wc.UseDefaultCredentials = true;
byte[] response = wc.UploadFile(destination + Path.GetFileName(fileName) , "PUT", fileName);
}
Ok this seems simple enough. As you can see it is not as complex as using the Copy web service. However, it does not support sending any metadata long with the file content. This can be a major problem if the document library has multiple content types, so the new file will be put into the document library with the default content type. Another big issue is if the default content type has required fields. The file will remain checked out until the fields are populated. This prevents other users from seeing the document or from being returned in any searches. It is a great solution if you are just bulk migrating data from an external data store to SharePoint. You more than likely will have to do extra work afterwards. Adding metadata after uploading will also cause the creation of extra versions of the document being created unnecessarily. The fact that it does not use the soap protocol but straight http makes it more scalable than the copy web service. Unfortunately, it still suffers from the fact that it uses a byte array to upload the file. So sooner or later you will run into “out of memory “ exceptions. So how can I create a folder before using WebDav? You can use the lists web service to accomplish this:
public static XmlNode UpdateListItemCreateFolder(string docLibraryName, string folderName)
{
listservice.Lists listProxy = new listservice.Lists();
string xmlFolder = "<Batch OnError='Continue'><Method ID='1' Cmd='New'><Field Name='ID'>New</Field><Field Name='FSObjType'>1</Field><Field Name='BaseName'>” + folderName + “</Field></Method></Batch>";
XmlDocument doc = new XmlDocument();
doc.LoadXml(xmlFolder);
XmlNode batchNode = doc.SelectSingleNode("//Batch");
listProxy.Url = "http://servername/sitename/_vti_bin/lists.asmx";
listProxy.UseDefaultCredentials = true;
XmlNode resultNode = listProxy.UpdateListItems(docLibraryName, batchNode);
return resultNode;
}
FrontPage RPC (Remote Procedure Calls)
Most developers are not familiar with RPC and what it can do. The complexity of coding RPC is high due to the fact that construction of commands and the interpreting of responses can be tedious and error prone. However this method proves to be the most scalable and the fastest. It also supports sending both the content and the metadata in one call. RPC has numerous commands including one for creating folders and it supports the use of streams rather than a byte array. Below is sample code to create a new document in SharePoint using RPC with a stream.
public static void CreateDocumentRPC(string name, string docLib, string title, bool overWrite, Stream fileBinary)
{
string method = "put document: 12.0.0.4518";
string serviceName = "http://servername/sitename/_vti_bin/_vti_aut/author.dll";
string document = docLib + "/" + name;
string metaInfo = string.Empty;
string putOption = overWrite ? "overwrite" : "edit";
string keepCheckedOutOption = "false";
string comment = string.Empty;
string returnStr = string.Empty;
byte[] data;
string returnError = string.Empty;
string fpRPCCallStr = "method={0}&service_name={1}&document=[document_name={2};meta_info=[{3}]]&put_option={4}&comment={5}&keep_checked_out={6}";
method = HttpUtility.UrlEncode(method);
putOption = HttpUtility.UrlEncode(putOption);
metaInfo = "vti_title;SW|" + title;
fpRPCCallStr = String.Format(fpRPCCallStr, method, serviceName, document, metaInfo, putOption, comment, keepCheckedOutOption);
try
{
//add line feed character to delimit end of command
byte[] fpRPCCall = System.Text.Encoding.UTF8.GetBytes(fpRPCCallStr + "\n");
data = new byte[fpRPCCall.Length];
fpRPCCall.CopyTo(data, 0);
HttpWebRequest wReq = WebRequest.Create(serviceName) as HttpWebRequest;
wReq.Credentials = System.Net.CredentialCache.DefaultCredentials;
wReq.Method = "POST";
wReq.ContentType = "application/x-vermeer-urlencoded";
wReq.Headers.Add("X-Vermeer-Content-Type", "application/x-vermeer-urlencoded");
wReq.ContentLength = fpRPCCall.Length + fileBinary.Length;
using (Stream requestStream = wReq.GetRequestStream())
{
requestStream.Write(fpRPCCall, 0, fpRPCCall.Length);
byte[] tmpData = null;
int bytesRead = 0;
int chunkSize = 2097152;
int tailSize;
int chunkNum = Math.DivRem((int)fileBinary.Length, chunkSize, out tailSize);
//chunk the binary directly from the stream to buffer.
for (int i = 0; i < chunkNum; i++)
{
data = new byte[chunkSize];
bytesRead = fileBinary.Read(tmpData, 0, chunkSize);
requestStream.Write(data, 0, chunkSize);
}
//send the remainde if any.
if (tailSize > 0)
{
data = new byte[tailSize];
bytesRead = fileBinary.Read(data, 0, tailSize);
requestStream.Write(data, 0, tailSize);
}
//Now get the response from the server
WebResponse response = wReq.GetResponse();
int num2,num3;
long contentLength = response.ContentLength;
bool noLength = false;
if (contentLength == -1)
{
noLength = true;
contentLength = chunkSize;
}
byte[] returnBuffer = new byte[(int) contentLength];
using (Stream responseStream = response.GetResponseStream())
{
num3 = 0;
do
{
num2 = responseStream.Read(returnBuffer, num3, ((int) contentLength) - num3);
num3 += num2;
if (noLength && (num3 == contentLength))
{
contentLength += chunkSize;
byte[] buffer2 = new byte[(int) contentLength];
Buffer.BlockCopy(returnBuffer, 0, buffer2, 0, num3);
returnBuffer = buffer2;
}
}
while (num2 != 0);
}
if (noLength)
{
byte[] buffer3 = new byte[num3];
Buffer.BlockCopy(returnBuffer, 0, buffer3, 0, num3);
returnBuffer = buffer3;
}
returnStr = Encoding.UTF8.GetString(returnBuffer);
}
}
catch (Exception ex)
{
//error handling
}
}
As you can see the complexity of coding against rpc can be daunting. You can refactor this code into something much more reusable. Parsing of the return response can be a bit strange also. Below is an example of a successful document creation response from the SharePoint server:
<html><head><title>vermeer RPC packet</title></head>
<body>
<p>method=put document:12.0.0.4518
<p>message=successfully put document 'tester2/crpc.png' as 'tester2/crpc.png'
<p>document=
<ul>
<li>document_name=tester2/crpc.png
<li>meta_info=
<ul>
<li>vti_rtag
<li>SW|rt:61935CFA-736B-4311-97AA-E745777CC94A@00000000001
<li>vti_etag
<li>SW|"{61935CFA-736B-4311-97AA-E745777CC94A},1"
<li>vti_filesize
<li>IR|1295
<li>vti_parserversion
<li>SR|12.0.0.6318
<li>vti_modifiedby
<li>SR|BASESMCDEV2\test.moss
<li>vti_timecreated
<li>TR|19 May 2009 17:28:35 -0000
<li>vti_title
<li>SW|wackout
<li>vti_lastheight
<li>IX|78
<li>ContentTypeId
<li>SW|0x010100B1C4E676904AB94BA76515774B23E02D
<li>vti_timelastmodified
<li>TR|19 May 2009 17:28:35 -0000
<li>vti_lastwidth
<li>IX|411
<li>vti_author
<li>SR|BASESMCDEV2\test.moss
<li>vti_sourcecontrolversion
<li>SR|V1.0
<li>vti_sourcecontrolcookie
<li>SR|fp_internal
</ul>
</ul>
</body>
</html>
If there is not substring of “osstatus” or “Windows SharePoint Services Error” then it is a success.
I hope this helps in your evaluation of different ways you can upload data to SharePoint. There are many things to consider when selecting which method to use. High on your priority list should be speed, scalability and the ability to send metadata. Sometimes the method that looks the hardest can be the best choice and it is up to you as a developer to abstract away the complexity.
