0

I am attempting to create a SharePoint 2013 Online App that will process documents stored on the host site collection.

I'm able to use jQuery ajax to retrieve a file from the host site collection and the format I receive it in appears to be a byte stream (which jQuery appears to store as a string or at least, the data is being interpreted as a string by the browser I'm using to debug).

My conclusion is that I should be sending the received file to a WCF application in order to use C# to write the stream to a file (on the file system of the WCF service) and then extract the content of the resulting file. The resulting file, however, is corrupt. My assumption is that somewhere in the process (SharePoint host to jQuery on App or App to WCF application) the original data is corrupted.

My questions are:

  • Is this the simplest method of processing documents using an App or
    is there a simpler method of extracting the content of documents on
    host sites?
  • Assuming my current approach is the best approach, is there any way to prevent the file corruption I'm experiencing?

Any assistance would be greatly appreciated.

FourOFour
  • 3
  • 1

1 Answers1

1

OK, 'is this the simplest method' is a very subjective topic, one to avoid right now because it sounds like you're 90% towards where you want to be.

Your issue with the corrupted file is probably as simple as a base64 encoding issue, as the byte stream has been encoded to string. (or your byte stream is not the file you are expecting) If you post the code that you are using to decode the stream with the string itself we can quickly help.

In cases like this, where it appears to be a corruption, I use fiddler to capture the raw response and then decode it in linqpad or a unit test. Then you can be sure if it is a corruption or if you have the wrong file. By wrong file, I mean you may have the an html error page in your byte stream, and not the document that you are expecting.

Back to simplest method... Sounds like you want a workflow on the host list. If you have many sites that you want to do this for or a high volume of docs to process, then you might want to make a WCF service to handle this, that's an added maintenance and management overhead that you may not want though, for instance where will the service be hosted.

Again, very subjective because your 'processing' logic might be easier to express in different frameworks or languages. LightSwitch HTML Client apps might also be an interesting place for this, auto hosted apps give you the service backend and a method of hosting the apps so you can for instance use ajax on the client to send the document to the backend service and execute your logic in C#. I have actually deployed a solution very much like this, was very quick to deploy to production.

But investigate the workflow of list receiver options if you do not need a UI or only limited ui to identify what docs and when to process them

Chris Schaller
  • 13,704
  • 3
  • 43
  • 81
  • It turns out it was simply a badly constructed header on the HTTP request. Fiddler really helped make that clear. Thank you. I never did get to trying the workflow courtesy of the last 10% getting completed and their being no time to check other options. – FourOFour Apr 17 '15 at 09:45